Windows Server 2025 / IP-, DNS- und DHCP-Probleme beheben
Prüfen Sie bei Netzwerkproblemen unter Windows Server 2025 die IP-Konfiguration, den Netzwerkpfad, die DNS-Namensauflösung und den gewünschten Dienst getrennt. Notieren Sie zuerst die aktuellen Werte von CLIENT1, vergleichen Sie denselben Test mit einem funktionierenden Client im gleichen Netz und ändern Sie jeweils nur eine wahrscheinliche Ursache. Eine Ping-Antwort, ein DNS-Ergebnis und ein erreichbarer TCP-Port bestätigen unterschiedliche Dinge.
Fehler und letzte Änderungen eingrenzen
Grenzen Sie den Fehler ein: Sind alle Clients oder nur einer betroffen? Scheitern Namen und IP-Adressen oder nur Namen? Funktioniert nur ein bestimmter Dienst nicht? Notieren Sie Ziel, Zeitpunkt, Fehlermeldung sowie letzte Neustarts und Änderungen an Adaptern, virtuellen Switches oder DHCP-Optionen. IP steht für Internet Protocol, DNS für Domain Name System und DHCP für Dynamic Host Configuration Protocol. Vergleichen Sie Clients im selben Segment mit derselben Prüfung. Gleichzeitige Änderungen an DNS und Firewall machen die Ursache schwer erkennbar.
| Symptom | Erster Prüfbereich |
|---|---|
| Name und IP funktionieren nicht | Verbindung, Adressierung, Dienst und Firewallregeln getrennt prüfen. |
| Nur Namen funktionieren nicht | DNS-Server, Einträge, Suffix und Cache prüfen. |
| Ein Client hat eine falsche Adresse | Manuelle Werte, Leases und konkurrierende DHCP-Server vergleichen. |
| Lokales Subnetz funktioniert, externe Ziele nicht | Gateway, Routen, NAT und ausgehende Regeln im Kontext des Netzdesigns prüfen. |
Ein Zugriff per IP kann ein Namensproblem eingrenzen, ist aber nicht immer gleichwertig mit dem Zugriff über den Dienstnamen. Zertifikatsprüfung und das Authentifizierungsprotokoll Kerberos können andere Voraussetzungen haben. Standardmäßig versucht Windows bei einem als IP angegebenen Ziel keine Kerberos-Anmeldung; das erläutert die Dokumentation zu Kerberos bei IP-Zielen. Verwenden Sie einen Diagnosetest nicht ungeprüft als dauerhafte Verbindungsmethode und umgehen Sie keine Zertifikatswarnung.
Tatsächliche Clientkonfiguration lesen
ipconfig /all
Get-NetIPConfiguration
Get-NetAdapter
Get-NetRoute -AddressFamily IPv4
Führen Sie diesen Block an der Konsole von CLIENT1 in Windows PowerShell aus. Bestimmen Sie den Laboradapter und notieren Sie IP, Maske, DNS, DHCP-Server, Suffix und automatische oder manuelle Konfiguration. Nach der DHCP-Übung werden 172.24.50.100–172.24.50.150 mit 255.255.255.0 und DNS 172.24.50.10 erwartet. Get-NetAdapter hilft beim Prüfen des Adapterzustands; Get-NetRoute zeigt Präfixe und nächste Hops, einschließlich 0.0.0.0/0 für eine vorhandene Standardroute. Ein isoliertes Netz ohne Router benötigt für Kommunikation im eigenen Subnetz kein Gateway; fehlender Internetzugriff ist dort erwartbar. Fehlt eine Schnittstelle bei Get-NetIPConfiguration, prüfen Sie -All oder wählen Sie den tatsächlichen Schnittstellenindex, wie in der Referenz zur IP-Konfiguration beschrieben.
Eine Adresse 169.254.x.x deutet darauf hin, dass keine verwendbare DHCP-Lease bezogen wurde, beweist aber keinen defekten DHCP-Server. Prüfen Sie zuerst, ob die virtuelle Maschine läuft, der Adapter aktiviert und mit dem richtigen Switch verbunden ist und gegebenenfalls automatisch eine IP bezieht. Vergleichen Sie den tatsächlich gemeldeten DHCP-Server mit DC1. Die DHCP-Client-Fehlerbehebung verweist auf die Operational- und Admin-Ereignisprotokolle des DHCP-Clients unter Anwendungs- und Dienstprotokolle in der Ereignisanzeige. Ordnen Sie die Ereignisse dem Zeitpunkt und Adapter des Fehlers zu.
Erreichbarkeit und Dienstzugriff unterscheiden
ping 172.24.50.10
Test-NetConnection -ComputerName 172.24.50.20 -Port 445
Führen Sie beide Tests auf CLIENT1 aus. Ping prüft Antworten des Internet Control Message Protocol (ICMP); blockierte Antworten belegen nicht, dass jeder Dienst ausgefallen ist. Test-NetConnection mit -Port prüft eine TCP-Verbindung (Transmission Control Protocol). Beachten Sie TcpTestSucceeded für genau dieses Ziel und diesen Port, wie die Dokumentation zur Verbindungsdiagnose erklärt. TCP 445 gehört zu Dateifreigaben über Server Message Block (SMB). Erwarten Sie nur dann Erfolg, wenn FS1 den Dienst unter .20 bereits anbietet; in dieser Kursphase muss das noch nicht der Fall sein. True bestätigt weder Anmeldung noch Freigabeberechtigungen oder das Lesen einer Datei.
Bei Fehlern im selben Subnetz kontrollieren Sie laufende virtuelle Maschinen, Switchzuordnung, doppelte IP-Adressen und Masken. Bei ausschließlich externen Fehlern prüfen Sie reales Gateway, Routen, Netzwerkadressübersetzung (NAT, Network Address Translation) und ausgehende Regeln; erfinden Sie keinen Router für das isolierte Netz. Bevor Sie einen anderen Port testen, klären Sie, ob dort überhaupt ein Dienst lauschen soll. Prüfen Sie Profil, erlaubte Quelladressen und Ziel der zuständigen Firewallregel, statt die Firewall insgesamt auszuschalten.
Gezielte DNS-Abfrage mit Standardauflösung vergleichen
Resolve-DnsName 'fs1.lab.example.test' -Type A -Server 172.24.50.10
nslookup fs1.lab.example.test 172.24.50.10
Resolve-DnsName 'fs1.lab.example.test' -Type A
Die ersten beiden Abfragen auf CLIENT1 richten sich an DC1 unter 172.24.50.10, die letzte verwendet die konfigurierte Namensauflösung des Clients. Ist der A-Eintrag für fs1.lab.example.test eingerichtet, erwarten Sie 172.24.50.20 als aufgelöste Adresse; verwechseln Sie diese nicht mit der angezeigten DNS-Serveradresse. Nslookup verwendet nicht den DNS-Clientcache. Funktioniert die gezielte Abfrage und die Standardabfrage nicht, prüfen Sie DNS-Einstellungen, Adapter, Richtlinien und Cache; das ist ein Hinweis, noch kein bewiesener Einzelgrund. Funktioniert der vollständige Domänenname (FQDN, Fully Qualified Domain Name), aber nicht der Kurzname, untersuchen Sie Suffix und Suchliste.
Unterscheiden Sie NXDOMAIN für einen nicht vorhandenen Namen von einer Zeitüberschreitung ohne Antwort; außerdem kann ein Name vorhanden sein, aber der angefragte Eintragstyp fehlen. Verbinden Sie die DNS-Clientprüfungen mit der Prüfung von Zonen und Weiterleitungen auf dem Server. Clear-DnsClientCache leert den lokalen Clientcache, Clear-DnsServerCache den Cache des DNS-Serverdiensts. Auch DC1 hat getrennte Client- und Serverrollen. Klären Sie den betroffenen Cache und sichern Sie die Beobachtung vor dem Leeren; ein falscher Eintrag in einer autoritativen Zone wird dadurch nicht repariert. Bei ausschließlich externer Namensauflösung prüfen Sie Weiterleitungen und den Ausgangspfad, statt den internen DNS durch einen öffentlichen zu ersetzen.
DHCP prüfen und denselben Test wiederholen
Öffnen Sie auf DC1 Windows PowerShell als Administrator und fragen Sie mit dem nächsten Block den lokalen Server ab. Prüfen Sie DHCPServer als Running, den aktiven Bereich 172.24.50.0, freie Kapazität und die zum tatsächlichen Client passende Lease. Kontrollieren Sie zusätzlich die Bindung an die Laborschnittstelle und nur in einer bestehenden Domäne die Autorisierung in Active Directory. Die allgemeine DHCP-Fehlerbehebung beschreibt diese Punkte. Clients in einem anderen Subnetz können einen DHCP-Relay-Agent benötigen; für ein Problem im Labor mit einem einzigen Switch fügen Sie keinen zusätzlichen Relay-Agent hinzu.
Get-Service DHCPServer
Get-DhcpServerv4Scope
Get-DhcpServerv4ScopeStatistics -ScopeId 172.24.50.0
Get-DhcpServerv4Lease -ScopeId 172.24.50.0
Erneuern Sie eine Lease bei Bedarf an der Konsole von CLIENT1 und beschränken Sie die Aktion auf den vorgesehenen Adapter. Wiederholen Sie nach einer Änderung denselben fehlgeschlagenen Namen, dieselbe IP oder denselben Port und kontrollieren Sie auch zuvor funktionierende Aufgaben. Hilft die Änderung nicht, stellen Sie nur den geänderten Wert wieder her und behalten Sie Befehl, Ziel, Zeitpunkt und Fehler für die weitere Diagnose. Globale Firewallabschaltung, wahlloses Cacheleeren und gleichzeitiges Neuerstellen des Bereichs vernichten Hinweise und erschweren die Rücknahme.
Ein bedingtes Beispiel: Die gezielte Abfrage an .10 liefert die richtige Antwort, die Standardabfrage scheitert, und auf CLIENT1 ist ein falscher DNS-Server manuell eingetragen. Notieren Sie den Ausgangswert und öffnen Sie ncpa.cpl → Eigenschaften des isolierten Adapters → Internetprotokoll, Version 4 (TCP/IPv4) → Eigenschaften. Korrigieren Sie nur den falschen DNS-Wert auf 172.24.50.10, belassen Sie IP, Maske und Gateway und wiederholen Sie beide Abfragen. Wird DNS per DHCP geliefert, prüfen Sie stattdessen Bereichsoption 006 und erneuern Sie den Client, statt den Fehler mit einer manuellen Ausnahme zu verdecken. Die Einrichtung des DHCP-Bereichs und seiner Optionen erklärt die Prüfung.




