Intermediate 4 min read Updated: Sep 10, 2026

Windows Server DHCP Failover: Load Balance vs Hot Standby Modes

Master Windows Server DHCP high availability: Load Balance vs Hot Standby modes, Maximum Client Lead Time (MCLT), partner communication states, and DHCPv4 scope replication.

In enterprise local area networks, Dynamic Host Configuration Protocol (DHCP) is a mission-critical infrastructure dependency: if DHCP servers become unreachable, endpoints cannot renew IP addresses, lose default gateway routing, fail to resolve DNS names, and drop off corporate networks entirely. Historically, administrators achieved redundancy through "split-scope" designs (e.g., Server A handles 80% of the pool, Server B handles 20%) or complex clustered storage instances.

Modern enterprise IP resiliency on Windows platforms relies on native Windows Server DHCP Failover (RFC 3074). Built directly into the DHCP Server role on Windows Server, DHCP Failover enables two standalone DHCP servers to share a common subnet scope, synchronize lease states in real-time, and provide seamless, zero-downtime failover without requiring shared SAN storage or failover clustering.

Failover Modes: Load Balance vs Hot Standby

When configuring a failover relationship between two Windows Server DHCP partners, administrators must select between two distinct architectural modes:

Operational Dimension Load Balance Mode (Active-Active) Hot Standby Mode (Active-Passive)
Primary Deployment Topology Single physical site where both DHCP servers reside on high-speed low-latency corporate subnets. Hub-and-spoke or multi-site topology where the Active server is local and the Standby partner is located in a central data center.
Traffic Handling Active-Active: Both partner servers actively respond to client DHCPDISCOVER and DHCPREQUEST messages simultaneously. Active-Passive: The Primary server serves 100% of client leases under normal conditions. The Secondary server remains passive.
Load Distribution Determined by a deterministic hash of the client's MAC address (RFC 3074). Default split is 50% / 50% (configurable, e.g., 70/30). Primary serves all traffic; Standby maintains a configurable Reserve Pool (default 5% of scope) for temporary leases during an outage.
WAN Sensitivity Requires low latency (< 10 ms) between partners for synchronized hashing. Resilient across higher-latency WAN connections between branch offices and data centers.

The Failover State Machine & Maximum Client Lead Time (MCLT)

DHCP Failover partners communicate continuously over TCP port 647 to synchronize lease database modifications. The resiliency of the relationship is governed by the Maximum Client Lead Time (MCLT) parameter (default: 1 hour):

  1. Normal State: Both partners communicate over TCP 647. Whenever Server A grants or renews an IP lease, it sends a binding update (BNDUPD) to Server B, which acknowledges the update (BNDACK). Both lease tables remain synchronized.
  2. Communication-Interrupted State: If Server A loses network connectivity to Server B, Server B transitions to COMMUNICATION-INTERRUPTED. Server B does not know if Server A has crashed or if a temporary network partition occurred. To prevent granting duplicate IP addresses, Server B issues new leases and renewals strictly for the duration of the MCLT (e.g., 1 hour), rather than the full scope lease time (e.g., 8 days).
  3. Partner-Down State: If an administrator or automated script confirms that Server A has physically crashed and will not return, Server B is transitioned into PARTNER-DOWN. Server B waits for the MCLT timer to expire (ensuring all existing client leases expire or renew), and then takes over 100% of the entire scope pool, serving full-duration leases.

Critical Scope Limitation: IPv4 Only: Windows Server DHCP Failover is supported exclusively for DHCPv4 scopes. Microsoft DHCP Server does not support failover relationships for DHCPv6 scopes. For IPv6 environments, high availability is achieved natively via router advertisements (SLAAC) or deploying independent stateless DHCPv6 servers.

Configuring Windows Server DHCP Failover via PowerShell

Systems administrators configure, replicate, and manage DHCP failover relationships using the native DhcpServer module:

# 1. Create a Load Balance failover relationship between DC1 and DC2 for subnet 10.10.10.0
Add-DhcpServerv4Failover -ComputerName "DC1.corp.contoso.com" `
    -Name "DC1-DC2-Failover" `
    -PartnerServer "DC2.corp.contoso.com" `
    -ScopeId 10.10.10.0 `
    -Mode LoadBalance `
    -LoadPercent 50 `
    -MaxClientLeadTime 01:00:00 `
    -SharedSecret "ComplexClusterSecretP@ss2026" `
    -AutoStateTransition $True `
    -StateSwitchInterval 00:30:00

# 2. Alternatively, create a Hot Standby relationship for branch site 10.20.10.0
# DC1 is Active Primary; DC2 is Standby holding 10% reserve capacity
Add-DhcpServerv4Failover -ComputerName "DC1.corp.contoso.com" `
    -Name "DC1-DC2-BranchStandby" `
    -PartnerServer "DC2.corp.contoso.com" `
    -ScopeId 10.20.10.0 `
    -Mode HotStandby `
    -ServerRole Active `
    -ReservePercent 10 `
    -MaxClientLeadTime 01:00:00 `
    -SharedSecret "ComplexClusterSecretP@ss2026"

# 3. Manually replicate scope configuration updates from Primary to Partner
Invoke-DhcpServerv4FailoverReplication -ComputerName "DC1.corp.contoso.com"

Auditing and Monitoring Failover Health

To inspect active partnership health and verify that lease synchronization is operational:

# Query active failover relationship operational states
Get-DhcpServerv4Failover -ComputerName "DC1.corp.contoso.com" | Format-List Name, Mode, ServerRole, State, PartnerState

# Inspect active lease counts and scope allocation across both failover partners
Get-DhcpServerv4ScopeStatistics -ComputerName "DC1.corp.contoso.com" -ScopeId 10.10.10.0

Verify that both State and PartnerState report Normal, and ensure that TCP port 647 is permitted through local host firewalls on both Domain Controllers.

Code copied to clipboard!