How to Configure DHCP Failover on Windows Server 2025

How to Configure DHCP Failover on Windows Server 2025

DHCP Failover is a high-availability feature introduced in Windows Server 2012 and significantly matured in Windows Server 2025. It allows two DHCP servers to share responsibility for a single scope, eliminating the single point of failure that a standalone DHCP server represents. If one server becomes unavailable, the other continues assigning and renewing leases without any client disruption. DHCP Failover supports two modes: Load Balance, where both servers actively serve clients simultaneously, and Hot Standby, where one server handles all traffic and the other sits ready to take over. This guide walks through prerequisites, configuring the failover relationship, monitoring its health, testing resilience, and cleanly removing the relationship when needed.

Prerequisites

• Two Windows Server 2025 servers with the DHCP Server role installed on each
• Both DHCP servers must be authorized in Active Directory
• The scope you intend to replicate must exist on the primary server (it does not need to pre-exist on the partner)
• Both servers must be able to reach each other over TCP port 647 (DHCP Failover protocol)
• System clocks on both servers must be synchronized (NTP or AD time hierarchy) — clock skew over one minute can prevent failover from functioning
• Domain Admin or DHCP Admin privileges on both servers

Step 1: Verify DHCP Scope Exists on the Primary Server

Before creating a failover relationship, confirm the scope is properly configured and active on the primary server. The partner server will receive a copy of the scope configuration and lease database during the initial synchronization.

# Run this on the PRIMARY DHCP server (DHCPSRV01)
# Verify the scope exists and is active
Get-DhcpServerv4Scope | Select-Object ScopeId, Name, StartRange, EndRange, State

# Confirm the partner server is reachable and authorized in AD
Get-DhcpServerInDC

# Test TCP connectivity to the partner on the DHCP failover port
Test-NetConnection -ComputerName "DHCPSRV02" -Port 647

# Verify both servers' clocks are in sync (difference should be under 60 seconds)
$time1 = (Get-Date)
$time2 = Invoke-Command -ComputerName "DHCPSRV02" { Get-Date }
[Math]::Abs(($time1 - $time2).TotalSeconds)

Step 2: Configure DHCP Failover in Load Balance Mode

Load Balance mode is recommended for deployments where both servers are in the same physical location or connected by a high-speed, reliable link. Both servers actively respond to client requests, with the workload split according to the LoadBalancePercent parameter. The default split is 50/50, but you can adjust this if one server has greater capacity.

# Create a Load Balance failover relationship for a specific scope
# Run this on the PRIMARY DHCP server (DHCPSRV01)
Add-DhcpServerv4Failover `
    -Name "DHCP-Failover-Corp-LAN" `
    -PartnerServer "DHCPSRV02.corp.example.com" `
    -ScopeId "192.168.10.0" `
    -Mode "LoadBalance" `
    -LoadBalancePercent 50 `
    -MaxClientLeadTime "01:00:00" `
    -AutoStateTransition $true `
    -StateSwitchInterval "00:15:00" `
    -SharedSecret "Str0ngSh@redSecr3t!2025" `
    -Force `
    -PassThru

# Verify the failover relationship was created
Get-DhcpServerv4Failover -Name "DHCP-Failover-Corp-LAN"

# Apply the same failover relationship to additional scopes
Add-DhcpServerv4FailoverScope `
    -Name "DHCP-Failover-Corp-LAN" `
    -ScopeId "192.168.20.0", "192.168.30.0"

The SharedSecret parameter configures a pre-shared key used to authenticate the two servers to each other over the failover channel. Use a strong, random secret and store it securely — both servers must use the same value.

Step 3: Configure DHCP Failover in Hot Standby Mode

Hot Standby mode is suited for scenarios where the two DHCP servers are in different physical locations (such as primary and disaster-recovery sites) connected by a WAN link. One server is designated the Active server and serves all client requests; the Standby server only activates if it cannot communicate with the Active server for longer than the configured StateSwitchInterval.

# Create a Hot Standby failover relationship
Add-DhcpServerv4Failover `
    -Name "DHCP-Failover-HotStandby" `
    -PartnerServer "DHCPSRV-DR.corp.example.com" `
    -ScopeId "192.168.10.0" `
    -Mode "HotStandby" `
    -ServerRole "Active" `
    -ReservePercent 5 `
    -MaxClientLeadTime "02:00:00" `
    -AutoStateTransition $true `
    -StateSwitchInterval "01:00:00" `
    -SharedSecret "Str0ngSh@redSecr3t!2025" `
    -Force `
    -PassThru

# On the Standby server, verify it received the scope configuration
Invoke-Command -ComputerName "DHCPSRV-DR" {
    Get-DhcpServerv4Scope | Select-Object ScopeId, Name, State
}

The ReservePercent parameter (Hot Standby only) controls what percentage of the address pool is reserved exclusively for the Standby server to use when it activates. The remaining addresses are served by the Active server during normal operation.

Step 4: Understanding Key Failover Parameters

Several parameters control exactly how the failover relationship behaves under failure conditions. Understanding these allows you to tune the behavior for your network’s specific tolerance for address exhaustion versus disruption.

• MaxClientLeadTime: The maximum time a server will extend a lease beyond its normal expiry when in the partner-down state. This prevents address exhaustion if the partner is down for an extended period.
• AutoStateTransition: When set to $true, the server automatically transitions to the Partner Down state after the StateSwitchInterval elapses without hearing from the partner.
• StateSwitchInterval: How long a server waits without contact from its partner before transitioning to Partner Down state and taking over the full address pool.
• ReplicationDelay: The delay (in seconds) before lease updates are replicated to the partner. Lower values reduce data loss on failure but increase network traffic.

# View all current failover configuration details
Get-DhcpServerv4Failover | Format-List *

# Modify failover settings on an existing relationship
Set-DhcpServerv4Failover `
    -Name "DHCP-Failover-Corp-LAN" `
    -MaxClientLeadTime "02:00:00" `
    -StateSwitchInterval "00:30:00" `
    -AutoStateTransition $true `
    -PassThru

# Trigger immediate replication of lease data to the partner
Invoke-DhcpServerv4FailoverReplication `
    -Name "DHCP-Failover-Corp-LAN" `
    -Force `
    -PassThru

Step 5: Monitor Failover State and Statistics

The Get-DhcpServerv4FailoverStatistics cmdlet provides real-time visibility into the health and operation of the failover relationship. The State property shows the current operational state of the relationship, which should normally be Normal. Other states indicate communication problems or deliberate administrative actions.

# Get failover statistics for all relationships
Get-DhcpServerv4FailoverStatistics | Format-Table -AutoSize

# Get statistics for a specific failover relationship
Get-DhcpServerv4FailoverStatistics -Name "DHCP-Failover-Corp-LAN" |
    Select-Object Name, State, PartnerState,
        TotalAddresses, AddressesInUse, AddressesFree,
        PercentageAddressesInUse

# Continuously monitor failover state (refreshes every 30 seconds)
while ($true) {
    Clear-Host
    Get-DhcpServerv4FailoverStatistics |
        Select-Object Name, State, PartnerState, AddressesInUse, AddressesFree
    Write-Host "Last updated: $(Get-Date)" -ForegroundColor Cyan
    Start-Sleep -Seconds 30
}

The possible failover state values are: Normal, CommunicationInterrupted, PartnerDown, RecoverWait, Recover, PotentialConflict, and Conflict. Any state other than Normal warrants investigation.

Step 6: Test Failover by Stopping the DHCP Service on the Primary

Before relying on failover in production, validate it works as expected in a controlled test. Stop the DHCP service on the primary server and verify that the partner begins serving client requests. Watch the partner transition through CommunicationInterrupted to PartnerDown (after the StateSwitchInterval), at which point it takes over the full address pool.

# On the PRIMARY server — stop DHCP service to simulate failure
Stop-Service -Name DHCPServer -Force

# On the PARTNER server — monitor state transition
$relationship = "DHCP-Failover-Corp-LAN"
$states = @()
for ($i = 0; $i -lt 20; $i++) {
    $stat = Get-DhcpServerv4FailoverStatistics -Name $relationship
    $states += [PSCustomObject]@{
        Time        = Get-Date -Format "HH:mm:ss"
        State       = $stat.State
        PartnerState = $stat.PartnerState
        AddressesFree = $stat.AddressesFree
    }
    Write-Host "$(Get-Date -Format 'HH:mm:ss') - State: $($stat.State), Partner: $($stat.PartnerState)"
    Start-Sleep -Seconds 30
}
$states | Format-Table -AutoSize

# After confirming partner took over, restore the primary
Start-Service -Name DHCPServer

# After primary reconnects, trigger reconciliation to merge lease databases
Invoke-DhcpServerv4FailoverReplication -Name $relationship -Force

Step 7: Reconcile Lease Databases After Recovery

When the primary DHCP server comes back online after a failover event, there may be discrepancies between the lease databases on the two servers — the standby continued issuing leases while the primary was offline. The reconciliation process synchronizes the databases and resolves any conflicts.

# Check for inconsistencies between the two servers' lease databases
$scopeId = "192.168.10.0"
$primaryLeases = Get-DhcpServerv4Lease -ScopeId $scopeId |
    Select-Object IPAddress, ClientId, LeaseExpiryTime

$partnerLeases = Invoke-Command -ComputerName "DHCPSRV02" {
    Get-DhcpServerv4Lease -ScopeId "192.168.10.0" |
        Select-Object IPAddress, ClientId, LeaseExpiryTime
}

# Find leases that exist on partner but not on primary
Compare-Object $primaryLeases $partnerLeases -Property IPAddress

# Invoke scope reconciliation to fix database inconsistencies
Invoke-DhcpServerv4ScopeStatistics -ScopeId $scopeId
Repair-DhcpServerv4IPRecord -ScopeId $scopeId -Force

Step 8: Remove a DHCP Failover Relationship

Removing a failover relationship is a planned operation — for example, when decommissioning a secondary DHCP server or switching from Load Balance to Hot Standby mode. The Remove-DhcpServerv4Failover cmdlet removes the relationship, after which the primary server resumes full ownership of the scope. The scope on the partner server must be manually deleted if it is no longer needed.

# Remove a specific failover relationship (run on either server)
Remove-DhcpServerv4Failover `
    -Name "DHCP-Failover-Corp-LAN" `
    -Force

# Verify the relationship is removed on the primary
Get-DhcpServerv4Failover

# Verify the relationship is removed on the partner
Invoke-Command -ComputerName "DHCPSRV02" {
    Get-DhcpServerv4Failover
}

# On the partner, delete the now-orphaned scope copy if no longer needed
Invoke-Command -ComputerName "DHCPSRV02" {
    Remove-DhcpServerv4Scope -ScopeId "192.168.10.0" -Force
}

# Confirm the primary has full control of the scope
Get-DhcpServerv4Scope -ScopeId "192.168.10.0" |
    Select-Object ScopeId, Name, State

Conclusion

DHCP Failover transforms what is typically a critical single point of failure into a resilient, highly available service on Windows Server 2025. Whether you choose Load Balance mode for active-active operation at a single site or Hot Standby mode for geographic redundancy across data centers, the failover mechanism ensures clients continue receiving IP addresses and network configuration even when one server fails. The keys to a successful deployment are proper prerequisites — synchronized clocks, network connectivity on port 647, and both servers authorized in Active Directory — combined with thorough testing before you rely on the failover in production. Monitor the relationship state regularly using Get-DhcpServerv4FailoverStatistics and practice controlled failover tests to build confidence that your network’s DHCP service will survive any infrastructure outage.