Windows Server DHCP Failover 2026

01.11.2026 · IT-Wissen

Windows Server DHCP Failover 2026 – praxisnaher Leitfaden für hochverfügbare Netzwerkdienste.

Wenn DHCP nicht verfügbar ist, merken es Anwender oft erst nach einer Neuanmeldung, einem Gerätewechsel oder dem Ablauf einer IP-Lease. Neue PCs erhalten keine gültige Adresse, Drucker verschwinden aus dem Netz und Telefonie oder WLAN können gestört sein. Windows Server bietet mit DHCP Failover eine integrierte Möglichkeit, IPv4-Scopes über zwei Server hochverfügbar zu betreiben. Damit entstehen jedoch neue Abhängigkeiten: Der Partnerschaftsstatus, dynamische DNS-Updates und die Erreichbarkeit des zweiten Servers müssen stimmen. Der Leitfaden Windows Server DHCP Failover 2026 erklärt Hot Standby und Load Balance, typische Konfigurationsfehler, Monitoring und sichere Ausfalltests für mittelständische IT-Infrastrukturen.

Autor: Salman Dolatpanah Gortlar · GORTNET IT-Dienstleistungen · 1. November 2026

Praxisziel: Zwei DHCP-Server sollen bei Ausfall eines Partners weiterhin gültige IPv4-Leases und korrekte Netzwerkinformationen liefern.

Warum DHCP-Ausfälle mehr betreffen als die IP-Adresse

DHCP verteilt neben einer IPv4-Adresse häufig auch Subnetzmaske, Standardgateway, DNS-Server und weitere Optionen. Diese Werte steuern, ob Clients interne Anwendungen erreichen, Domain Controller finden oder über eine bestimmte Route mit dem Internet kommunizieren. Ein Ausfall kann zunächst unbemerkt bleiben, solange Geräte ihre gültige Lease weiterverwenden. Erst neue Verbindungen, Geräte oder ablaufende Leases machen den Fehler offensichtlich.

Eine hochverfügbare DHCP-Architektur muss deshalb mehr leisten als einen zweiten Windows-Dienst zu starten. Sie muss die Scope-Daten konsistent halten, aus verschiedenen VLANs erreichbar sein und mit dem bestehenden DNS- und Active-Directory-Design zusammenarbeiten. Definieren Sie, welche Bürostandorte und Netzsegmente bei einem Ausfall weiter bedient werden müssen. Ein isolierter Test auf dem Server selbst beweist nicht, dass Client-Broadcasts den zweiten DHCP-Server wirklich erreichen.

Windows Server DHCP Failover 2026: Technische Grundlagen

Microsoft unterstützt DHCP Failover in Windows Server 2016, 2019, 2022 und 2025 für IPv4-Scopes. Zwei autorisierte Windows-DHCP-Server bilden dabei eine Partnerschaft und tauschen Informationen über aktive Leases und die zugehörigen Einstellungen aus. Für eine konkrete Failover-Beziehung sind genau zwei Partner vorgesehen. Zusätzliche Server erfordern eine separat entworfene Architektur, statt einen dritten Partner einfach in die bestehende Beziehung einzutragen.

Wichtig ist eine häufige Fehlannahme: Das integrierte DHCP-Failoververfahren wird für DHCPv6-Scopes nicht unterstützt. IPv6 hat andere Adressierungs- und Verfügbarkeitsmodelle, etwa SLAAC und gegebenenfalls getrennte DHCPv6-Server. Wer von „vollständigem DHCP-Failover für alle IP-Adressen“ spricht, sollte daher IPv4 und IPv6 ausdrücklich trennen. Prüfen Sie das tatsächliche Clientverhalten je Netzsegment und nicht nur den im Server-Manager angezeigten Partnerschaftsstatus.

Load Balance versus Hot Standby auswählen

Im Load-Balance-Modus übernehmen beide Partner im Normalbetrieb Anfragen. Standardmäßig ist das Verhältnis 50:50, kann aber im unterstützten Rahmen angepasst werden. Dieses Modell passt gut, wenn zwei Rechenzentrumsserver mit vergleichbarer Kapazität und guter Netzverbindung aktive DHCP-Last teilen sollen. Die Lastverteilung basiert auf einem deterministischen Verfahren für Anfragen, sodass nicht beide Server willkürlich dieselbe Adresse anbieten.

Im Hot-Standby-Modus beantwortet dagegen üblicherweise der aktive Partner Anfragen, während der zweite für einen Ausfall bereitsteht. Das eignet sich besonders für Niederlassungen, bei denen ein lokaler Server bevorzugt und eine zentrale Instanz als Reserve verwendet wird. Der richtige Modus hängt von Standortverbindung, Erreichbarkeit über DHCP-Relay, tolerierter Reaktionszeit und organisatorischem Betrieb ab. Ein Modus ist nicht automatisch „sicherer“ als der andere.

DHCP-Relay und Routing vor dem Aufbau prüfen

Ein DHCP-Server in einem anderen IP-Subnetz empfängt die Broadcast-Anfragen lokaler Clients nicht automatisch. Deshalb müssen Router oder Layer-3-Switches als DHCP-Relay beziehungsweise IP-Helper konfiguriert sein. Bei hochverfügbaren DHCP-Diensten sollten die erforderlichen Relay-Ziele beide Partner berücksichtigen, soweit dies zum gewählten Netzwerkdesign passt. Prüfen Sie Firewall-Regeln, Routing und VLAN-Zuordnung aus Sicht des tatsächlichen Clientnetzes.

Ein häufiges Problem tritt beim Failover auf, wenn zwar die beiden Server miteinander kommunizieren, der zweite aber aus einem Standort nicht erreichbar ist. Die Partnerschaft wird dann im Dashboard als eingerichtet angezeigt, doch neue Clients erhalten bei Ausfall des ersten Servers keine Lease. Ein Pilot sollte deshalb für jedes kritische VLAN eine kontrollierte Neuerneuerung einer Testlease enthalten. Dokumentieren Sie, welcher Relay die Anfrage vermittelt hat und welcher Partner geantwortet hat.

TCP 647 und weitere Kommunikationswege

Die DHCP-Failover-Kommunikation zwischen Windows-DHCP-Partnern verwendet laut Microsoft TCP-Port 647. Für die eigentliche IPv4-DHCP-Kommunikation sind die bekannten UDP-Ports 67 und 68 relevant. Daraus folgt keine Empfehlung, alle diese Ports in jede Netzrichtung zu öffnen. Planen Sie Regeln ausdrücklich anhand von Quellserver, Zielserver, Clientsegment und Netzwerkdesign.

Prüfen Sie die Kommunikationsstrecke vor der Einrichtung und überwachen Sie sie danach. Ein erfolgreicher TCP-Test auf Port 647 beweist, dass der Transportpfad erreichbar ist, nicht automatisch, dass die Partnerschaft, die Lease-Replikation oder der DHCP-Dienst korrekt funktionieren. Bei domänengebundenen Servern benötigen Verwaltung, Autorisierung und gegebenenfalls DNS-Aktualisierung weitere gezielt freizugebende Dienste. Eine dokumentierte Verkehrsflussmatrix ist sicherer als eine pauschale Firewallausnahme.

DHCP-Scopes und Reservierungen konsistent halten

Ein DHCP-Scope definiert den nutzbaren Adressbereich, Leasezeiten, Ausschlüsse und weitere Optionen. In einer Failover-Beziehung werden die unterstützten Scope-Informationen zwischen den Partnern ausgetauscht. Prüfen Sie dennoch nach der Einrichtung und nach größeren Änderungen, ob Reservierungen und wichtige Optionen korrekt abgebildet sind. Besonders relevant sind fest zugewiesene Adressen für Drucker, Spezialgeräte oder Applikationskomponenten.

Nehmen Sie Scope-Änderungen über einen festgelegten administrativen Prozess vor, statt zwei Server unabhängig voneinander zu bearbeiten. Kontrollieren Sie überlappende DHCP-Bereiche und unautorisierte weitere DHCP-Dienste im selben Segment. Ein zusätzlicher Heimrouter oder eine falsch angeschlossene Appliance kann trotz einer korrekt funktionierenden Failover-Beziehung falsche IP-Informationen ausliefern. Die DHCP-Architektur benötigt deshalb auch eine Netzwerksicherheits- und Erkennungsperspektive.

Dynamisches DNS: Gleiche Update-Credentials verwenden

Microsoft weist ausdrücklich darauf hin, dass beide DHCP-Failoverpartner dieselben DNS-Anmeldeinformationen verwenden müssen, wenn sie dynamische DNS-Updates im Auftrag von Clients ausführen. Andernfalls kann der zweite Server bestehende DNS-Datensätze nicht verändern, weil der erste Server diese unter einem anderen Sicherheitskontext angelegt hat. Das führt zu veralteten A- oder PTR-Einträgen und kann später Anmeldungen, Namensauflösung oder Administrationsskripte beeinträchtigen.

Verwenden Sie dafür ein geeignetes, minimal berechtigtes Dienstkonto und dokumentieren Sie Passwortwechsel beziehungsweise die unterstützte Credential-Verwaltung. Prüfen Sie Forward- und Reverse-Lookups nach einem kontrollierten Partnerwechsel. Lassen Sie die Änderung von einem dafür vorgesehenen Testgerät auslösen und kontrollieren Sie den DNS-Recordbesitzer, falls ein Update fehlschlägt. Eine gültige DHCP-Lease ist noch kein Nachweis für einen korrekt aktualisierten DNS-Eintrag.

MCLT, Communication Interrupted und Partner Down

Eine DHCP-Failover-Beziehung besitzt Zustände, die Administratoren verstehen müssen. Ein kurzer Kommunikationsverlust zwischen den Partnern darf nicht automatisch zu widersprüchlichen Leases führen. Microsoft beschreibt dafür Mechanismen wie Maximum Client Lead Time (MCLT) sowie Zustände wie Communication Interrupted und Partner Down. Diese steuern, wie Leases bei Kommunikationsproblemen behandelt werden und wann ein Partner zusätzliche Verantwortung übernehmen kann.

Der Wechsel in Partner Down darf nicht unüberlegt manuell erzwungen werden. Wenn beide Server weiterlaufen, aber nur ihre gegenseitige Verbindung unterbrochen ist, kann eine falsche Entscheidung zu problematischer Adressvergabe führen. Dokumentieren Sie, wie der tatsächliche Ausfall des anderen Partners zweifelsfrei verifiziert wird und wer eine manuelle Zustandsänderung freigeben darf. Nutzen Sie die Herstellerdokumentation und testen Sie solche Situationen zuerst in einer isolierten Umgebung.

DHCP Failover und Active Directory Autorisierung

Windows-DHCP-Server in einer AD-Domänenumgebung werden über die vorgesehenen Mechanismen autorisiert, damit nicht beliebige Domänenserver IP-Adressen verteilen. Prüfen Sie für beide Partner ihre AD-Autorisierung und die Erreichbarkeit der benötigten Verzeichnisdienste. Die Failover-Beziehung allein ersetzt diesen Schritt nicht. Auch ein funktionsfähiger DHCP-Dienst kann bei fehlerhafter AD- oder DNS-Konfiguration Störungen verursachen.

Gleichzeitig sollten Administratoren die DHCP-Verwaltung auf geeignete Gruppen beschränken und Änderungen protokollieren. Ein versehentlich veränderter DNS-Server in Option 006 kann Hunderte Clients betreffen, ohne dass der DHCP-Dienst selbst ausfällt. Setzen Sie auf Rollen, getrennte Administration und regelmäßige Konfigurationssicherungen. Kritische Änderungsfenster benötigen eine nachvollziehbare Abnahme durch Netzwerk- und gegebenenfalls Anwendungsteams.

Monitoring und Windows-Eventlogs für Failover

Windows Server stellt spezielle Ereignisprotokolle und Performance Counter für DHCP Failover bereit. Die relevanten Kanäle finden sich unter den DHCP-Server-Logs in Event Viewer. Überwachen Sie Partnerschaftszustand, ausbleibende Kommunikation, verfügbare Adressen, fehlgeschlagene dynamische DNS-Updates und Dienstverfügbarkeit. Eine reine Ping-Prüfung der Server ist unzureichend, weil ein erreichbares Betriebssystem trotzdem keine neuen Leases ausliefern kann.

Führen Sie wichtige Metriken bei Bedarf in Zabbix oder einer vergleichbaren Plattform zusammen. Warnungen sollten der geschäftlichen Auswirkung entsprechen: Eine kritisch knapp werdende Scope-Kapazität kann ebenso dringlich sein wie ein ausgefallener Partner. Testen Sie die Alarmierung über einen kontrollierten Zustand und prüfen Sie, ob die zuständigen Mitarbeitenden erreicht werden. Historische Logs müssen für die Analyse unerwarteter Client-Probleme verfügbar bleiben.

Regelmäßiger Failover-Test ohne Produktionsausfall

Eine echte Hochverfügbarkeitsprüfung bestätigt die Funktion aus Sicht eines Clients. Nutzen Sie hierfür ein dediziertes Test-VLAN oder eine abgestimmte Testgruppe, statt wahllos sämtliche produktiven DHCP-Dienste abzuschalten. Dokumentieren Sie den Ausgangszustand, simulieren Sie die Nichtverfügbarkeit eines Partners und fordern Sie von einem Testclient eine gültige Adresse an. Prüfen Sie Gateway, DNS-Server, DNS-Updates und die Erreichbarkeit geschäftskritischer Anwendungen.

Nach Wiederherstellung des Partners werden Synchronisierung und Normalzustand geprüft. Notieren Sie die tatsächliche Dauer der Einschränkung und die aufgetretenen Logmeldungen. Ein erfolgreiches Umschalten allein reicht nicht, wenn anschließend Reservierungen fehlen oder DNS-Records veraltet bleiben. Prüfen Sie außerdem das Verhalten nach Windows-Updates und größeren Router-/Relay-Änderungen, weil diese einen funktionierenden DHCP-Failoverpfad unbemerkt beeinträchtigen können.

Backup und Rückfallplan für DHCP-Konfiguration

DHCP Failover erhöht Verfügbarkeit, ersetzt aber keine geschützte Konfigurationssicherung. Eine unbeabsichtigte Scope-Änderung kann auf beide Partner übertragen werden. Sichern Sie daher die DHCP-Konfiguration über die unterstützten Windows-Tools und halten Sie wichtige Netzsegment- und Relay-Informationen zusätzlich dokumentiert. Für die Wiederherstellung muss klar sein, ob eine Konfiguration zunächst auf einem einzelnen Server oder in einer neu aufzubauenden Partnerschaft wiederhergestellt werden soll.

Vermeiden Sie ungetestete Importe in den laufenden Produktionsbetrieb. Ein Recovery-Test sollte in einer isolierten Umgebung stattfinden, damit keine konkurrierenden DHCP-Antworten an echte Clients gelangen. Berücksichtigen Sie Administrationsberechtigungen, DNS-Credentials und mögliche Änderungen von Servernamen oder IP-Adressen. Das Ziel ist die nachvollziehbare Wiederherstellung einer korrekten Adressvergabe, nicht nur die Installation eines neuen DHCP-Rollendienstes.

30-Tage-Rollout für zwei DHCP-Server

Woche eins: IPv4-Scopes, Reservierungen, Leasezeiten, DNS-Optionen und DHCP-Relay-Netze inventarisieren. Woche zwei: Zweiten autorisierten DHCP-Server vorbereiten, TCP-647-Kommunikation prüfen und passende Hot-Standby- oder Load-Balance-Beziehung einrichten. Woche drei: DNS-Credentials und kritische Clientnetze testen, Monitoring und Alarmregeln ergänzen. Woche vier: Einen kontrollierten Ausfall simulieren und den Betrieb schriftlich abnehmen lassen.

Der wichtigste KPI ist nicht die Anzahl installierter DHCP-Server, sondern die erfolgreiche Adressvergabe auch bei einem geplanten Partnerausfall. Ergänzen Sie aktuelle Failoverzustände, ungeklärte DNS-Updatefehler und fehlende Relay-Redundanzen. Mit diesem Nachweis wird DHCP-Failover zu einem verlässlich betriebenen Service statt einer einmalig angelegten Konfiguration.

FAQ zu Windows Server DHCP Failover 2026

Funktioniert Windows DHCP Failover für IPv6?

Nein. Die integrierte DHCP-Failoverfunktion wird für IPv4-Scopes unterstützt; IPv6 benötigt eine gesondert geplante Verfügbarkeitslösung.

Welcher Port wird zwischen DHCP-Failoverpartnern benötigt?

Die Failoverkommunikation verwendet TCP 647. Die DHCP-Clientkommunikation verwendet im IPv4-Fall UDP 67 und 68.

Ist Hot Standby immer besser als Load Balance?

Nein. Die Wahl hängt von Standortdesign, Kapazität, Verfügbarkeit und Netzwerkanbindung ab.

Müssen beide DHCP-Server dieselben DNS-Zugangsdaten nutzen?

Ja, wenn sie dynamische DNS-Updates im Namen der Clients durchführen sollen; unterschiedliche Credentials können zu Berechtigungsfehlern führen.

Fazit: Verfügbarkeit muss aus Sicht der Clients bewiesen werden

Windows Server DHCP Failover 2026 verbindet zwei Server, deren tatsächliche Hochverfügbarkeit jedoch von Routing, DHCP-Relay, korrekten DNS-Credentials und sauberem Monitoring abhängt. Ein dokumentierter Ausfalltest ist deshalb wichtiger als der grüne Partnerschaftsstatus. Führen Sie Änderungen kontrolliert durch und überwachen Sie die relevanten Netzsegmente regelmäßig.

Über den Autor

Salman Dolatpanah Gortlar schreibt für GORTNET über Windows Server, Active Directory, Netzwerkarchitektur und die verlässliche Administration von Unternehmensdiensten.

Passende GORTNET-Beiträge

Für die Planung oder Überprüfung von DHCP und Netzwerkredundanz GORTNET kontaktieren.

Offizielle Microsoft-Quellen

Stand 1. November 2026. Alle beschriebenen Änderungen vor dem Produktiveinsatz am eigenen Windows-Server-Stand und der Netzwerkarchitektur testen.

Windows Server DHCP Failover 2026: Hot Standby und DNS richtig planen