Prove Windows DHCP failover before the primary server is unavailable

Source facts: Windows DHCP failover is a two-server DHCPv4 design

Microsoft’s DHCP failover overview says two Windows DHCP servers share IPv4 scope information, active leases, and availability state so either can serve clients under the configured relationship. A relationship is always between two DHCP servers, although one server can participate in multiple relationships with different partners.

Windows supports load-balance mode, in which the partners divide client lease work, and hot-standby mode, in which an active server normally responds while a standby reserves capacity. DHCP failover applies to DHCPv4 scopes; Microsoft does not support it for DHCPv6 scopes. Clients must be able to reach both partners directly or through relay configuration. When the servers are on remote networks, relay devices therefore need a path to each service endpoint.

Initial configuration replicates scopes and leases, but later scope-setting changes are not automatically synchronized in every case. Microsoft says administrators must manually replicate changed scope settings and warns that replication overwrites the partner with the settings from the server where replication is initiated. With partners on different Windows Server versions, Microsoft directs administrators to make the change and initiate replication from the newer operating-system version.

The partners use TCP port 647 for failover communication. They maintain separate synchronized lease databases and monitor each other’s state. If DHCP performs DNS dynamic updates for clients, both partners must use the same DNS credentials. Microsoft documents Admin and Operational event channels, audit logs, and performance counters for relationship state, communication, binding updates, queue conditions, and transitions.

DSE recommendation: run a controlled client-centered exercise

Start with a written relationship map: partner names and addresses, mode, scopes, maximum client lead time, standby reserve or load split, state-switch settings, DHCP relay addresses, DNS update credentials, monitoring, owners, and representative test VLANs. Export the configuration and current leases before the exercise.

1. Establish normal state. Confirm both partners report the expected relationship state, scope settings match, binding-update queues are stable, time is synchronized, and event logs show no unexplained communication or replication error.
2. Test both network paths. Verify a client broadcast reaches both partners through the actual relay path. Do not infer relay redundancy from successful traffic to only the primary server.
3. Use controlled clients. On an approved test segment, record existing leases, then test renewal of a current lease and allocation to a new or cleared test client. Confirm address, mask, gateway, DNS servers, suffixes, lease duration, reservations, policies, and any vendor-specific option needed by that segment.
4. Exercise partner loss. Through an approved method, make one partner unavailable or isolate the relevant service path. Observe the state transition, client renewal, new lease behavior, monitoring alert, log entries, and time required. Repeat in the opposite direction during a separate controlled step.
5. Verify DNS behavior. Where DHCP updates DNS, confirm forward and reverse records are created, refreshed, and cleaned through each partner with the intended ownership behavior.
6. Recover deliberately. Restore communication, watch the relationship return through its recovery states, reconcile lease databases and queues, and confirm normal allocation resumes without duplicate addresses.

Avoid using uncontrolled production client churn as the test mechanism. Choose a scope and time with enough free addresses and an approved rollback path. Do not manually declare a partner down or alter state timers without understanding the lease implications and Microsoft’s failover behavior. Record every action and observable transition.

Retain the before-and-after exports, test-client identifiers, lease timestamps, server states, event records, relay configuration, DNS results, monitor notifications, observed recovery time, and unresolved exceptions. Repeat after DHCP server replacement, relay or routing changes, major scope restructuring, DNS credential changes, operating-system upgrades, or a material failover incident.

The acceptance criterion is not merely “relationship: normal.” It is that real clients can renew and obtain the correct configuration through either partner, operations can see the transition, and the pair can return to a synchronized normal state.

Official references

• Microsoft Learn, DHCP failover in Windows Server, March 11, 2025.
• Microsoft Learn, DHCP failover events in Windows Server, April 25, 2025.