Implement DHCP High Availability

Overview

In modern network environments, ensuring the availability of critical services like DHCP is paramount. A single DHCP server represents a single point of failure – if it goes offline, devices cannot obtain or renew IP addresses, causing new clients to lose connectivity and existing clients to fail at lease renewal time. DHCP failover in Windows Server eliminates this risk by enabling two DHCP servers to share responsibility for a single scope, ensuring uninterrupted IP address allocation even when one server becomes unavailable.

This guide covers the two DHCP failover modes (Load Balance and Hot Standby), preparing the secondary server, configuring the failover relationship through the wizard, verifying synchronization, testing failover behavior, and managing the relationship after deployment.

DHCP Failover Modes

Windows Server supports two distinct failover configurations, each suited to different availability requirements:

• Load Balance Mode – Both servers share the address pool simultaneously, each responding to a configured percentage of DHCP requests (default is 50/50). This mode improves performance under normal operation while maintaining redundancy – if one server fails, the other assumes full responsibility for all requests. Load balance is the preferred mode when both servers are on the same network segment and performance is a priority
• Hot Standby Mode – One server acts as the primary, handling all DHCP requests. The secondary server remains passive, monitoring the primary and ready to take over only if the primary fails. A small percentage of addresses (typically 5%) is reserved on the standby server to handle new client requests during the switchover period. Hot standby is better suited for remote sites where the standby server is on a different network segment from the primary

Both modes synchronize lease information between servers, meaning the secondary always has an up-to-date copy of all active leases and can service renewals without disruption if the primary fails.

Step 1 – Prepare the Secondary DHCP Server

Before configuring failover, ensure the secondary server has the DHCP Server role installed and authorized in Active Directory. Open Server Manager on the secondary server (in this example, NYC-DC-One), navigate to Manage → Add Roles and Features, and install the DHCP Server role. After installation, complete the DHCP Post-Installation Configuration Wizard to authorize the server and create the DHCP Administrators and DHCP Users security groups.

Verify network connectivity between the two DHCP servers – they must be able to communicate with each other to synchronize lease data. Use ping or Test-NetConnection to confirm bidirectional connectivity before proceeding.

Step 2 – Configure Failover on the Primary Server

On the primary DHCP server (NYC-Server-One), open the DHCP Management Console from Server Manager → Tools → DHCP. Expand the server node and the IPv4 node to see all configured scopes. Right-click the scope (or superscope) you want to include in the failover relationship and select Configure Failover. The Failover Configuration Wizard opens, displaying the selected scope. Click Next to proceed to partner server selection.

Step 3 – Add the Partner Server

On the partner server screen, click Add Server to select the secondary DHCP server. You can browse the list of domain-joined servers or type the IP address or hostname manually – useful if the secondary server’s address has recently changed. After selecting the partner, click Next.

Step 4 – Configure Failover Settings

The failover settings page controls the behavior of the relationship:

• Relationship Name – A descriptive identifier for the failover relationship. The wizard generates a default name; you can customize it to reflect the scope or server pair (for example, “NYC-Building-One-Failover”)
• Maximum Client Lead Time (MCLT) – The amount of time the partner server waits before assuming the primary is down and taking over. The default is 1 hour. During this interval, the partner continues serving its portion of the address pool but waits before fully taking over lease renewals that belonged to the failed server
• Failover Mode – Select Load Balance (shared, active-active) or Hot Standby (active-passive). For load balance, configure the percentage split (default 50%). For hot standby, specify the reserve address percentage on the standby server
• State Switchover Interval – An optional timer (under Advanced Options) that enables automatic failover detection without manual administrator intervention. When the primary is unreachable for the configured duration, the secondary automatically switches to a Partner Down state and takes full control
• Message Authentication and Shared Secret – Enable this option to require both servers to authenticate with a shared password before exchanging lease data, preventing unauthorized servers from injecting into the failover relationship

Step 5 – Complete the Wizard and Verify

Review the failover configuration summary and click Finish. The wizard creates the failover relationship and immediately begins replicating scope data and lease information to the secondary server. After the wizard completes, open the DHCP console on the secondary server (NYC-DC-One) and verify that the scope appears under IPv4 with a Synchronizing or Normal status, confirming that lease replication is active.

Step 6 – Test and Manage the Failover Relationship

To validate that failover works as intended, disable the DHCP service on the primary server and observe whether clients can continue obtaining and renewing addresses from the secondary. Verify that the secondary’s DHCP console shows the scope transitioning from Synchronizing to Partner Down and then to full Active status as it assumes control.

For ongoing management, two replication operations are available by right-clicking the scope on the primary:

• Replicate Scope – Pushes the current scope configuration and lease data for the selected scope to the partner server immediately. Use this after making scope changes (new exclusions, option changes) to ensure the secondary is current before the next automatic sync cycle
• Replicate Relationship – Pushes all scopes that are part of the failover relationship simultaneously. Use this when multiple scopes have been modified or after extended periods where the secondary may be behind on synchronization

Firewall Considerations

DHCP failover uses TCP port 647 for server-to-server communication. Windows Server automatically creates the required inbound firewall rules in Windows Defender Firewall with Advanced Security when the DHCP Server role is installed. Verify these rules are enabled on both servers under Inbound Rules – look for rules named “DHCP Failover” or similar.

For environments using third-party firewalls or network security appliances, ensure that TCP port 647 is permitted bidirectionally between the two DHCP server IP addresses. Blocking this port will prevent lease synchronization and cause the failover relationship to report a communication failure, ultimately resulting in both servers operating independently without shared lease state.

Best Practices

• Use Load Balance for Same-Site Deployments – When both servers are on the same physical network, load balance distributes the work and provides better throughput. Hot standby wastes capacity on the passive server
• Use Hot Standby for Remote Sites – When the secondary server serves a remote branch over a WAN link, hot standby avoids split-brain scenarios where WAN latency could cause both servers to serve conflicting address ranges
• Configure State Switchover Interval – Enable automatic state switchover rather than relying on manual administrator intervention. Set the interval to match your acceptable failover window – typically 60 minutes for most environments
• Enable Message Authentication – Always configure a shared secret for failover communication. This prevents unauthorized DHCP servers from joining the failover relationship and corrupting lease state
• Test Failover Regularly – Perform simulated failover tests during maintenance windows to verify that the secondary takes over correctly and clients continue operating. An untested failover relationship may fail when needed most
• Monitor Synchronization Status – Check the DHCP console on both servers regularly. A persistent “Synchronizing” status rather than “Normal” indicates a communication problem that should be investigated before a real failure occurs