Welche Microsoft-DHCP-Server-Fehlermeldung bedeutet was – und welche Komponente ist verantwortlich?

Interne Arbeitsweise des Microsoft-DHCP-Servers: Broadcasts, Relay, Lease-Lifecycle, Datenbank und Abhängigkeiten zu AD/DNS

DORA und das Broadcast-Prinzip: Warum DHCP in Segmenten „steckenbleiben“ kann

Microsoft DHCP basiert im Kern auf dem klassischen DORA-Ablauf: Der Client sendet DHCPDISCOVER, der Server antwortet mit DHCPOFFER, der Client fordert mit DHCPREQUEST an, und der Server bestätigt per DHCPACK. In IPv4 erfolgt die erste Phase typischerweise als Broadcast, weil der Client zu Beginn keine gültige IP-Konfiguration besitzt. Das Verhalten ist damit eng an Layer‑2‑Broadcast-Domänen gebunden: Ohne Weiterleitung erreicht ein Discover nur DHCP-Server im gleichen Subnetz/VLAN.

Viele „DHCP-Fehler“ entstehen deshalb indirekt durch Netzsegmentierung, Filterregeln oder eine fehlerhafte Gateway-Konfiguration. Wird Broadcast-Traffic unterdrückt oder in ein falsches Segment gespiegelt, sind die Symptome nicht zwingend DHCP-spezifisch: Clients melden „eingeschränkte Konnektivität“, domänenbasierte Anmeldungen scheitern zeitweise, und Gruppenrichtlinien wirken „sporadisch“, weil DNS- und AD-Konnektivität erst nach manueller oder späterer Adressierung funktioniert. In der Ereignisprotokollierung lässt sich dann häufig eher ein Folgeproblem (z. B. DNS-Zeitüberschreitungen) als die Ursache (fehlender DHCP-Pfad) ablesen.

DHCP-Relay (IP-Helper): Übersetzer zwischen Subnetzen und Fehlerquelle mit Nebenwirkungen

Sobald Clients und DHCP-Server in unterschiedlichen Subnetzen liegen, übernimmt ein Relay (z. B. Router/SVI mit IP-Helper) die Weiterleitung der Broadcast-Anfrage als Unicast zum Server. Dabei wird das Feld giaddr (Gateway IP Address) gesetzt, sodass der DHCP-Server den passenden Bereich (Scope) deterministisch zuordnen kann. Aus Serversicht ist der Relay damit nicht nur Transportweg, sondern Bestandteil der Entscheidungslogik: Ein falsches giaddr führt unmittelbar zu falscher Bereichsauswahl oder zur Rückweisung mangels passendem Scope.

In Microsoft DHCP greifen zusätzlich Richtlinien, Filter und Superscope-/Multiscope-Konstrukte in diese Zuordnung ein. Komplex wird es bei überlappenden Netzen, mehreren Relay-Interfaces oder wenn ein Relay DHCP-Optionen modifiziert (z. B. Option 82 / Relay Agent Information, sofern vom Netzwerkgerät eingefügt). Eine inkonsistente Relay-Konfiguration erzeugt dann Fehlerbilder, die als „Adresspool leer“ oder „Server antwortet nicht“ erscheinen, obwohl der Server grundsätzlich arbeitet.

• Wesentliche Ports und Richtung: UDP/67 (Server) und UDP/68 (Client); Relay leitet Client-Broadcasts als Unicast an UDP/67 weiter und transportiert Antworten zurück ins Quellsegment.
• Scope-Zuordnung über giaddr: Der Server wählt den Bereich anhand der Relay-Interface-IP (giaddr); stimmt sie nicht mit einem konfigurierten Subnetz überein, bleibt nur eine falsche Zuweisung oder ein Verwerfen der Anfrage.
• Option-82-Einfluss (falls aktiv): Relay kann Option 82 einfügen; je nach Server-/Policy-Konfiguration entscheidet der Inhalt über Zuweisungen oder führt zu Ablehnung, wenn unerwartete Suboptionen eintreffen.
• Mehrere Relays, asymmetrische Pfade: Antworten können über einen anderen Rückweg laufen; Statefulness ist nicht garantiert. ACLs/Firewalls müssen beide Richtungen für UDP/67-68 konsistent zulassen.

Lease-Lifecycle und Konflikterkennung: Von Offer bis Decline

Der DHCP-Server verwaltet Adressen als zeitlich begrenzte Leases. Beim ACK schreibt der Dienst den Lease-Eintrag in seine Datenbank und reserviert die Adresse für die Lease-Dauer; bei Ablauf oder Freigabe wird sie wieder verfügbar. Windows-Clients erneuern typischerweise zur Hälfte der Lease-Zeit (T1) per Unicast beim zuletzt verwendeten Server; gelingt das nicht, erfolgt später (T2) ein Rebind per Broadcast, der auch andere Server erreichen kann. Daraus entstehen Situationen, in denen ein Client „plötzlich“ einen anderen Server akzeptiert, etwa wenn der ursprüngliche Server nicht erreichbar ist.

Adresskonflikte sind in der Praxis weniger eine DHCP-Funktion als ein Zusammenspiel aus ARP, Client-Verhalten, Reservierungen und Störquellen. Ein Client kann eine angebotene Adresse per DHCPDECLINE zurückweisen, wenn er bereits belegte IPs erkennt (häufig via ARP). Der Server markiert die Adresse dann als „bad address“ (je nach Implementierungsdetails und Konfiguration) und nimmt sie temporär aus der Vergabe. Wird parallel mit statischen IPs, überlappenden Scopes oder inkonsistenten Reservierungen gearbeitet, entstehen Lease-/Reservierungs-Kollisionen, die sich wiederum als Client-seitige Ausfälle von DNS-Registrierung, Domänenlogon oder Applikationszugriff zeigen.

Reservierungen sind im Microsoft-DHCP logisch Vorrangregeln auf Basis der Client-ID bzw. MAC-Adresse. Sie sind keine „Sperre“ für eine IP im Sinne einer Firewall, sondern eine Zusage, welche IP ein bestimmter Client erhalten soll. Wenn die Client-Kennung wechselt (z. B. durch NIC-Tausch, Hypervisor-Clone, geänderte Client-ID), fällt der Client aus der Reservierungslogik und kann eine andere Adresse erhalten; der ursprüngliche Reservierungseintrag bleibt bestehen und kann so „unerklärliche“ Konflikte bei Wiederinbetriebnahme auslösen.

Lease-Datenbank, Protokollierung und Recovery: Persistenz als Fehlerverstärker

Microsoft DHCP persistiert Leases, Reservierungen, Bereichsdefinitionen und Statusinformationen in einer Datenbank, die vom Dienst verwaltet wird. Diese Persistenz ist Voraussetzung für konsistentes Verhalten über Neustarts hinweg, kann bei Störungen aber auch zur Fehlerverstärkung führen: Ein beschädigter Datenbestand, unplausible Zeitstempel oder eine inkonsistente Failover-Replikation spiegeln sich nicht nur in der Vergabe, sondern auch in Statusmeldungen des Dienstes. Typisch ist dabei, dass der Dienst zwar startet, aber in Teilfunktionen (z. B. dynamische DNS-Updates oder Failover-State-Machine) Fehler produziert, die zunächst nicht als „DHCP down“ sichtbar werden.

Die operative Diagnose stützt sich auf mehrere Ebenen: Ereignisanzeige (DHCP-Serverprotokolle), DHCP-Audit-Logs und die Datenbanksicht über die Verwaltungskonsole bzw. PowerShell. Audit-Logging ist dabei besonders wertvoll, weil es die semantische Abfolge von Vergaben, Erneuerungen, Releases und Konflikten als Serverentscheidung dokumentiert und sich so von Netzwerk-Mitschnitten abgrenzt. In Umgebungen mit Relay und Failover ist die zeitliche Korrelation (Zeitsynchronisation) entscheidend, weil scheinbar widersprüchliche Zustände häufig aus asynchronen Ereignisreihen entstehen.

• DHCP-Serverstatus und Scope-Überblick: Get-DhcpServerv4Scope
Get-DhcpServerv4ScopeStatistics -ScopeId 192.0.2.0
• Leases und Reservierungen prüfen: Get-DhcpServerv4Lease -ScopeId 192.0.2.0
Get-DhcpServerv4Reservation -ScopeId 192.0.2.0
• Audit-Log-Pfad (Standard): %SystemRoot%\System32\Dhcp (Dateien wie DhcpSrvLog-*.log, sofern Audit aktiviert ist).

Abhängigkeiten zu Active Directory und DNS: Autorisierung, sichere Updates und Ketteneffekte

In AD-domänenintegrierten Netzen ist DHCP nicht isoliert, sondern durch Autorisierung und Identität an das Active Directory gebunden. Ein Microsoft-DHCP-Server, der in AD nicht autorisiert ist, soll in der Regel keine Adressen vergeben; dadurch wird „Rogue DHCP“ in verwalteten Umgebungen reduziert. Diese Sicherheitslogik sitzt nicht im Client, sondern im Serverdienst und wirkt wie ein Hard-Stop, obwohl Netzwerk und Scope-Konfiguration korrekt erscheinen können. Zusätzlich können Gruppenrichtlinien oder lokale Sicherheitsrichtlinien die Dienstrechte so beeinflussen, dass der Dienst zwar startet, aber beim Zugriff auf AD- oder DNS-Funktionen scheitert.

DNS ist die zweite kritische Kopplung. Viele Windows-Umgebungen verlassen sich auf dynamische DNS-Registrierung aus DHCP heraus, insbesondere wenn Clients ihre A-/PTR-Records nicht selbst registrieren sollen oder wenn Nicht-Windows-Clients eingebunden werden. Der DHCP-Server benötigt dafür passende DNS-Update-Einstellungen, korrekte Zonenberechtigungen und häufig spezifische Anmeldeinformationen (Credential), wenn Updates „secure only“ in AD-integrierten Zonen erfolgen. Fehler in diesem Bereich wirken wie DHCP-Störungen, obwohl die Adressvergabe korrekt läuft: Anwendungen erreichen Hosts nicht per Name, Domänencontroller werden nicht gefunden, Kerberos bricht wegen Namensauflösung oder Zeitversatz ab.

Meldungen zu Dienstzuständen und Infrastrukturanbindung: Start-/Abbruchfehler, AD-Autorisierung, Berechtigungen, RPC/Firewall, Datenbank- und Replikationsbezug

Meldungen zu Dienstzuständen wirken oft wie reine Serverlokalprobleme, sind beim Microsoft-DHCP-Server jedoch regelmäßig Folge oder Auslöser von Infrastrukturbrüchen: fehlende AD-Autorisierung, blockierte RPC-Kommunikation, unzureichende Rechte, inkonsistente Datenbankdateien oder Korrelationen mit DNS- und Replikationszuständen. Viele dieser Zustände erscheinen als Service-Control-Manager-Ereignisse, DHCP-Server-Events oder als Fehler in Verwaltungswerkzeugen, obwohl die Ursache in Active Directory, der lokalen Sicherheitskonfiguration oder der Netzsegmentierung liegt.

Dienststart, Dienstabbruch und Service-Control-Manager-Bezug

Der DHCP-Dienst (DHCPServer) startet nicht „isoliert“, sondern hängt von lokalen Treibern (Netzwerk), dem RPC-Subsystem, der Erreichbarkeit zentraler Verzeichnisdienste (bei Domänenrollen) sowie von der Integrität der Lease-Datenbank ab. Der Service Control Manager (SCM) protokolliert Start- und Abbruchfehler häufig generisch; die präzise Ursache steht dann in einem korrespondierenden DHCP-Server-Event oder in einem System-Event zur Datei-/Rechteproblematik. Typische Muster sind Zeitüberschreitungen beim Start, ein sofortiger Dienstabbruch nach kurzer Laufzeit oder ein wiederholtes Crash-Recovery der Datenbank.

Startfehler sind besonders häufig, wenn die Datenbankdateien (%SystemRoot%\System32\dhcp\dhcp.mdb plus Log/Checkpoint) beschädigt sind oder wenn Antimalware/EDR die Transaktionslogs sperrt. Ebenfalls relevant sind fehlende Schreibrechte des Dienstkontos auf das DHCP-Verzeichnis oder ein inkonsistenter Zustand nach Wiederherstellung aus Backups. In Cluster-/Failover-Umgebungen kommen zusätzliche Abhängigkeiten hinzu, die zwar in Failover-Meldungen sichtbar werden, aber als Dienststartproblem erscheinen können.

• SCM-Fehler 1053: „Der Dienst antwortete nicht rechtzeitig auf die Start- oder Steuerungsanforderung.“ Typisch bei blockierten Abhängigkeiten (RPC/DC-Erreichbarkeit) oder bei Datenbank-Recovery, das länger als die Service-Timeout-Phase dauert; Korrelation über Eventvwr.msc → Systemprotokoll und DHCP-Serverprotokoll.
• SCM-Fehler 1067: „Der Prozess wurde unerwartet beendet.“ Häufiger Oberfehler bei DB-Korruption, fehlenden Dateirechten oder Drittsoftware, die %SystemRoot%\System32\dhcp sperrt; Abgleich mit DHCP-Server-Events und ggf. Windows Error Reporting.
• SCM-Fehler 1075/1083: Hinweise auf fehlerhafte Abhängigkeiten bzw. falsche Dienstkonfiguration; Prüfung der Dienstparameter über sc.exe qc dhcpserver und Status über Get-Service -Name DHCPServer.
• SCM-Fehler 7024/7031: „Der Dienst wurde mit dem dienstspezifischen Fehler … beendet“ bzw. „unerwartet beendet“; die dienstspezifische Fehlernummer muss mit DHCP-Server-Events zusammengeführt werden, da der SCM selbst keine DHCP-semantische Einordnung liefert.

AD-Autorisierung: Zustände, Fehlermeldungen und Zuordnung zur Komponente

In Active-Directory-Umgebungen darf ein Windows-DHCP-Server nur arbeiten, wenn er autorisiert ist. Die Autorisierung ist ein Schutzmechanismus gegen „Rogue DHCP“ und wird gegen das Verzeichnis geprüft. Ist die Autorisierung fehlend, fehlerhaft oder kann sie wegen Replikations-/Erreichbarkeitsproblemen nicht validiert werden, stoppt der Dienst typischerweise kurz nach dem Start oder verweigert das Verteilen von Leases. Diese Meldungen sind nicht nur „DHCP-intern“, sondern verweisen auf AD DS, DNS-Namensauflösung (DC-Lokalisierung) und Replikation.

Die Autorisierung erfolgt logisch über das DHCP-Objekt im Verzeichnis. Praktisch scheitert die Prüfung oft indirekt: Der Server findet keinen erreichbaren Domänencontroller, kann per DNS keinen DC ermitteln, RPC/LDAP wird gefiltert oder die Computerkontoberechtigungen reichen nicht aus, um die Autorisierung zu lesen. In solchen Fällen wirkt der DHCP-Dienstzustand wie ein lokales Startproblem, obwohl die Ursache im Site/Subnet-Design, in Firewall-Regeln oder in der AD-Replikation liegt.

• Konsole/Netsh (typisch): „Der DHCP-Server ist im Active Directory nicht autorisiert.“ Zuordnung: AD DS-Autorisierung; Prüfung/Änderung über dhcpmgmt.msc (Autorisieren/Unautorisieren) oder netsh dhcp add server <NameOderIP>.
• Konsole (typisch): „Zugriff verweigert“ beim Autorisieren. Zuordnung: Berechtigungen in AD DS; erforderlich sind i. d. R. Domänen-Admin-Rechte oder delegierte Rechte auf DHCP-Autorisierungsobjekte; technische Prüfung über dsac.exe bzw. AD-ACLs und Gruppenmitgliedschaften.
• Indirekter Autorisierungsfehler: Autorisierung vorhanden, Dienst verweigert dennoch Leases, wenn DC-Lokalisierung fehlschlägt (DNS/SRV) oder Replikation inkonsistent ist; Diagnosepfad über nltest /dsgetdc:<domain>
dcdiag /test:dns
repadmin /replsummary.
• Mehrfachautorisierung/Altserver: autorisierte, aber außer Betrieb genommene Server bleiben eingetragen und erzeugen Verwirrung bei Audits; Bereinigung per DHCP-Konsole oder netsh dhcp delete server <NameOderIP>.

Berechtigungen lokal: Dienstkonto, Dateisystem, Registrierung und Verwaltungszugriff

Der DHCP-Serverdienst läuft standardmäßig unter Local System und benötigt lokale Rechte auf das DHCP-Verzeichnis, auf relevante Registrierungsschlüssel sowie auf Netzwerkfunktionen. Lokale Hardening-Maßnahmen, restriktive ACLs oder Security-Baselines können den Dienststart verhindern oder die Verwaltung blockieren, obwohl der Dienst läuft. Zusätzlich hängt die Remoteverwaltung vom DCOM/RPC-Stack und von der lokalen Firewallkonfiguration ab; fehlende Verwaltungsrechte äußern sich dann als scheinbare „Server nicht erreichbar“-Meldungen.

Typische Fehlbilder entstehen, wenn das DHCP-Verzeichnis nur lesbar ist, wenn die Protokoll- oder Backup-Pfade umgebogen wurden und nicht existieren oder wenn das Konto, unter dem administrative Tools ausgeführt werden, nicht in der lokalen Gruppe DHCP Administrators bzw. DHCP Users ist. Diese Fälle betreffen nicht die Paketverarbeitung selbst, sondern verhindern Konfiguration, Lease-Display, Scope-Aktivierung oder das Schreiben von Audit-Logs.

• Verwaltung scheitert mit „Zugriff verweigert“: Zuordnung: lokale/gruppierte Rechte; Prüfung der Gruppen DHCP Administrators und DHCP Users über lusrmgr.msc bzw. Get-LocalGroupMember -Group "DHCP Administrators".
• Datei-/Pfadprobleme bei Audit/DB: Zuordnung: NTFS-ACLs und Pfadexistenz; relevante Pfade %SystemRoot%\System32\dhcp, Audit typischerweise unter %SystemRoot%\System32\dhcp; Kontrolle über icacls "%SystemRoot%\System32\dhcp".
• Remoteverwaltung schlägt fehl, Dienst läuft: Zuordnung: DCOM/RPC/Firewall; Test der Erreichbarkeit über Test-NetConnection -ComputerName <server> -Port 135 und Überprüfung der Regelgruppe Remote Service Management sowie DHCP-spezifischer Firewallregeln via Get-NetFirewallRule.

RPC/Firewall und Namensauflösung: Wenn „Server nicht erreichbar“ keine DHCP-Ursache ist

Mehrere DHCP-Verwaltungs- und Statusmeldungen beruhen auf RPC. Wenn die Konsole den Server nicht verbinden kann, liegt das häufig nicht am DHCP-Protokoll (UDP 67/68), sondern an blockiertem RPC Endpoint Mapper (TCP 135) oder an dynamischen RPC-Ports. Ebenso häufig ist fehlerhafte Namensauflösung: Der Servername zeigt auf eine falsche Adresse, ein DNS-A-Record ist veraltet, oder es existieren widersprüchliche PTR-Einträge. In diesen Fällen wirkt die Meldung wie ein DHCP-Dienstproblem, obwohl der Dienst korrekt Leases vergibt.

Die saubere Trennung erfolgt durch parallele Tests: DHCP-Paketfluss (Client erhält Lease) versus Verwaltungszugriff (MMC/RPC). Ein laufender Dienst mit funktionierender Leasevergabe kann bei strikter Host-Firewall vollständig „unsichtbar“ für Verwaltung und Remote-Events sein. Umgekehrt kann eine offene Verwaltung bei gleichzeitig blockiertem DHCP-UDP im Segment den Eindruck erwecken, DHCP sei funktionsfähig, obwohl Clients keine Adressen erhalten.

Datenbank-, Backup- und Replikationsbezug: dhcp.mdb als Startbremse und Fehlerverstärker

Die DHCP-Lease- und Konfigurationsdaten werden im JET-Format gespeichert (dhcp.mdb) und durch Transaktionslogs abgesichert. Beim Start muss der Dienst Logs nachziehen und einen konsistenten Zustand herstellen. Scheitert dies, resultieren dienstspezifische Abbrüche oder Folgefehler wie ausbleibende Leases, fehlende Scope-Anzeigen oder nicht aktualisierte Statistiken. Unvollständige Datenträger, Dateisystemfehler oder unerwartete Neustarts erhöhen das Risiko, dass Recovery-Prozesse beim Start dominieren.

Im AD-Kontext verstärken Replikationsprobleme die Diagnosekomplexität: Der DHCP-Dienst kann lokal starten, aber Autorisierungs- oder Richtlinieninformationen wirken inkonsistent, wenn Domänencontroller unterschiedliche Sichtstände liefern. Bei failoverfähigen Bereitstellungen kommt hinzu, dass der Partnerstatus im DHCP-Subsystem zwar eine Replikationslogik besitzt, diese jedoch nicht die AD-Replikation ersetzt. Ein sauberer Fehlerabgleich verlangt daher getrennte Ebenen: lokale JET-Integrität, OS-/Storage-Zustand und AD-Replikation.

• Online-Status und DB-Prüfung: Dienstzustand und Basisdiagnose über Get-Service DHCPServer
Get-DhcpServerSetting -ComputerName <server> (sofern Remoteverwaltung funktioniert).
• DB-/Storage-Indikatoren: Zuordnung: Dateisystem/Datenträger; Prüfung von freien Kapazitäten und Fehlern über Get-Volume sowie Ereignisse im Systemlog (NTFS/Storage). Bei wiederholten DB-bezogenen Abbrüchen Fokus auf %SystemRoot%\System32\dhcp und dessen Schreibbarkeit.
• AD-Replikationsquercheck: Zuordnung: AD DS; schnelle Lagebeurteilung über repadmin /replsummary und DC-Diagnostik über dcdiag, um Autorisierungs- und „wechselnde“ Zustände nicht fälschlich als DHCP-DB-Fehler zu interpretieren.

Bereichs-, Lease- und Netzsegmentprobleme präzise zuordnen: Scope/Superscope, Reservierungen, Adresskonflikte, Relay-Agent, Failover-Status und typische indirekte Client-Symptome

Scope/Superscope: Wenn der „richtige“ Bereich nicht antwortet

Der Microsoft-DHCP-Server entscheidet nicht „global“, sondern pro logischer Grenze: Eine Adresse kann nur aus einem aktivierten Bereich (Scope) vergeben werden, der zum anfragenden Subnetz passt. Diese Zuordnung entsteht entweder implizit (Server direkt im Client-Netz, Broadcast erreicht den Server) oder über einen Relay-Agent (DHCP/BOOTP-Relay), der das Gateway-Interface als giaddr in die Anfrage schreibt. Sobald diese Netzlogik nicht mehr konsistent ist, erscheinen Fehler oft als Scope- oder Superscope-Phänomen, obwohl die Ursache in Routing, VLAN-Tagging oder Relay-Konfiguration liegt.

Superscopes fassen mehrere Bereiche auf einem Server zusammen, um z. B. mehrere logische Netze auf einem physischen Segment oder eine Migration abzubilden. In der Praxis entstehen dadurch zwei typische Fallstricke: ein falscher oder fehlender Relay-Eintrag führt zur Auswahl des falschen Scopes, und mehrere aktive Scopes konkurrieren im gleichen Segment, ohne dass Filterung (z. B. über Relay-Policies oder Switch-ACLs) die Client-Population sauber trennt. Auffällig ist dann, dass Clients „plausible“ Adressen erhalten, jedoch im falschen Netz landen und anschließend DNS, Domänenanmeldung oder Gruppenrichtlinien scheitern.

Im Ereignisprotokoll des DHCP-Servers (Quelle Dhcp-Server) sind Zuordnungsprobleme häufig indirekt erkennbar: Der Server verarbeitet DISCOVER/REQUEST, findet aber keinen passenden aktiven Bereich oder kann keine freie Adresse anbieten. Der Client zeigt statt einer klaren DHCP-Fehlermeldung oft nur APIPA (169.254.0.0/16) oder „Eingeschränkte Konnektivität“. Auf Serverseite ist dann entscheidend, ob ein Scope deaktiviert ist, der Adresspool erschöpft wurde oder die Anfrage über einen Relay mit falschem giaddr ankommt.

Lease- und Reservierungskonflikte: Datenbankzustand, Duplikate und „stille“ Abweichungen

Leases werden in der DHCP-Datenbank als Zustand (aktiv, abgelaufen, reserviert, angeboten) geführt. Konflikte entstehen, wenn dieselbe IP logisch mehrfach beansprucht wird: durch Reservierung plus dynamische Vergabe, durch Import/Restore der Datenbank ohne konsistente Replikation in Failover-Szenarien oder durch parallele DHCP-Instanzen im gleichen Broadcast-Domain. Auch MAC-Adresswechsel (z. B. durch Dockingstations, Hyper-V/VM-Templates oder NIC-Teaming) führt dazu, dass Clients „ihre“ alte Lease-Adresse nicht mehr bestätigt bekommen und in schnelle Erneuerungszyklen fallen.

Charakteristisch sind dabei Client-Symptome, die nicht nach DHCP aussehen: sporadische Namensauflösungsfehler, wechselnde IP-Konfiguration innerhalb kurzer Zeit, Kerberos-Fehler wegen Zeit-/DNS-Abweichungen, oder GPO-Verarbeitungsfehler, weil der DC kurzfristig nicht erreichbar ist. Solche Effekte treten besonders dann auf, wenn Reservierungen falsch gepflegt wurden (z. B. Tippfehler in der MAC-Adresse) oder wenn mehrere Reservierungen auf dieselbe IP zeigen. Der DHCP-Server protokolliert diese Fälle nicht immer als „harter“ Fehler, weil die Anfrage formal gültig ist, der resultierende Adresszustand aber betrieblich inkonsistent wird.

• Scope-Belegung prüfen: Get-DhcpServerv4Scope -ComputerName <Server> | Select-Object ScopeId,State
Get-DhcpServerv4ScopeStatistics -ComputerName <Server> -ScopeId <ScopeId>
• Aktive Leases und Reservierungen abgleichen: Get-DhcpServerv4Lease -ComputerName <Server> -ScopeId <ScopeId>
Get-DhcpServerv4Reservation -ComputerName <Server> -ScopeId <ScopeId>
• Serverseitige Konflikterkennung einordnen: Get-DhcpServerv4Scope -ComputerName <Server> -ScopeId <ScopeId> | Select-Object ScopeId,ConflictDetectionAttempts
• DHCP-Clientstatus auf Windows-Clients prüfen: ipconfig /all
ipconfig /renew
Get-NetIPConfiguration

Adresskonflikte und Duplicate Address Detection: Meldungen richtig gewichten

Adresskonflikte haben zwei Quellen: serverseitige Konflikterkennung (Ping vor Angebot) und clientseitige Duplicate Address Detection (ARP-Prüfung nach Zuweisung). Die serverseitige Methode reduziert Konflikte in Segmenten mit vielen statischen IPs, verursacht aber Verzögerungen im DORA-Prozess und ist in gerouteten oder stark gefilterten Netzen nicht zuverlässig, weil ICMP/ARP nicht in allen Pfaden erwartungsgemäß funktioniert. Die clientseitige Erkennung kann wiederum dazu führen, dass ein Client ein gültiges Lease verwirft, wenn ein anderes Gerät die Adresse bereits nutzt oder ARP-Responses durch Sicherheitsfunktionen (z. B. Dynamic ARP Inspection) verfälscht werden.

Im DHCP-Server-Log zeigt sich ein echter Konflikt typischerweise als Eintrag, dass eine IP als „bad address“ markiert wurde. Damit verschwindet sie aus dem frei verfügbaren Pool, bis sie manuell oder per Bereinigung wieder freigegeben wird. Gleichzeitig kann der Eindruck entstehen, der Scope sei „plötzlich“ erschöpft, obwohl die nominale Adressanzahl ausreichen müsste. Der Kern ist dann weniger DHCP als Layer-2-Disziplin: doppelte statische Konfigurationen, falsch geklonte VM-Images oder Schatten-DHCP-Server im Segment.

Relay-Agent-Fehler: UDP-Weiterleitung, giaddr und Option-Handling

Relay-Agent-Probleme sind besonders tückisch, weil der DHCP-Server die Anfrage korrekt verarbeitet, der Client jedoch nie ein Offer oder Ack erhält. Ursache ist dann häufig nicht die DHCP-Rolle, sondern die Zwischenkomponente: fehlende ip helper-address-Äquivalente, falsche VRF-Zuordnung, asymmetrisches Routing oder Firewall-Regeln, die Rückpakete blockieren. Technisch entscheidend ist, dass Relay-Broadcasts in Unicast umsetzt und dabei die Subnetzzuordnung über giaddr bereitstellt. Ein falsches giaddr führt zu Angeboten aus dem falschen Scope oder zu „kein passender Bereich“, obwohl der korrekte Scope existiert.

Zusätzliche Fehlerbilder entstehen durch Option-Handling am Relay (Option 82, Circuit-ID/Remote-ID). Wird Option 82 eingefügt, aber der DHCP-Server oder eine Richtlinie erwartet andere Werte, kann das zu scheinbar willkürlichen Zuweisungen oder kompletten Ablehnungen führen. Auch Switches, die DHCP Snooping erzwingen, können Replies vom legitimen Server verwerfen, wenn Uplink-Ports nicht als „trusted“ konfiguriert sind. In Logs erscheint dann oft nur ein Mangel an erfolgreichen Acks, während der Client im Wechsel zwischen DISCOVER und Timeout hängt.

Failover-Status und Split-Brain-Effekte: Zustände, die wie Scope-Probleme aussehen

DHCP-Failover arbeitet zustandsbasiert (z. B. Normal, Communication Interrupted, Partner Down). In Übergangsphasen kann ein Bereich formal aktiv sein, aber faktisch keine Adressen liefern, weil die Lease-Zuständigkeit und die MCLT/Partner-Down-Logik die Vergabe einschränkt. Das äußert sich häufig als „Adresspool erschöpft“ oder als unerwartete Ablehnung von Requests, obwohl freie Adressen sichtbar sind. Besonders kritisch sind Inkonsistenzen nach unkoordiniertem Restore der DHCP-Datenbank, nach Snapshot-Rollbacks von virtuellen DHCP-Servern oder bei Zeitabweichungen, die Zustandswechsel verzögern.

Für die Zuordnung ist die Kombination aus Failover-State, Scope-Statistiken und Lease-Owner entscheidend. Ein Client kann wiederholt dieselbe Adresse anfragen, erhält aber kein Ack, weil der Partner als zuständig gilt oder weil der Server im Partner-Down-Modus nur einen begrenzten Anteil des Pools nutzen darf. Solche Effekte werden in segmentierten Umgebungen häufig fälschlich als Relay- oder VLAN-Problem interpretiert, da der Netzwerkpfad „manchmal“ funktioniert.

• Failover-Beziehung und State prüfen: Get-DhcpServerv4Failover -ComputerName <Server> | Select-Object Name,Mode,State,PartnerServer,ScopeId
• Failover je Scope validieren: Get-DhcpServerv4Failover -ComputerName <Server> -Name <FailoverName> | Select-Object -ExpandProperty ScopeId
Get-DhcpServerv4ScopeStatistics -ComputerName <Server> -ScopeId <ScopeId>
• Indirekte Client-Indikatoren korrelieren: Eventvwr.msc (Client: Microsoft-Windows-Dhcp-Client)
  Get-WinEvent -LogName "Microsoft-Windows-Dhcp-Client/Admin" -MaxEvents 50