How to Set Up Active Directory Certificate Auto-Enrollment on Windows Server 2022

Introduction to DHCP Failover on Windows Server 2022

A single DHCP server is a single point of failure. If that server goes offline — whether for planned maintenance or an unexpected outage — clients whose leases expire cannot obtain new IP configurations, which causes network connectivity failures. DHCP failover, introduced in Windows Server 2012 and refined in subsequent releases, allows two DHCP servers to share responsibility for a scope, ensuring uninterrupted IP address assignment even if one server is unavailable. Windows Server 2022 supports two failover modes: Hot Standby and Load Balance. This guide covers both modes, configuration steps, synchronization management, monitoring, and the limitations of DHCPv6 failover along with alternative approaches.

DHCP Failover Concepts

DHCP failover works by dividing the address pool of a scope between two partner DHCP servers. The servers communicate with each other to synchronize lease state information, ensuring that a lease issued by one server is known to the other.

Hot Standby mode: One server (the active server) handles all client requests under normal conditions. The second server (the standby server) only responds to client requests when the active server is unreachable or in a partner-down state. A percentage of the address pool (typically 5%) is reserved exclusively for the standby server to use during a failover event.

Load Balance mode: Both servers actively respond to DHCP requests simultaneously. The address pool is split between the two servers according to a configurable ratio (default 50/50). Each server handles its share of clients, and if one fails, the other takes over the entire pool using the addresses freed up from the failed server.

Key failover parameters:

Maximum Client Lead Time (MCLT): The maximum time that one DHCP server can extend a client’s lease without synchronizing with its partner. This value bounds how out-of-sync the two servers can be regarding lease duration. Typical values are 1 hour. During normal operation, MCLT is used to calculate the safe renewal time sent to clients.

Auto State Switchover Interval: How long a server waits in the “communication interrupted” state before automatically transitioning to “partner down” state and assuming full control of the address pool. Setting this too short risks both servers assuming partner-down simultaneously (causing duplicate leases); too long means slower recovery during genuine failures.

Replication Interval: How frequently the two servers synchronize lease state. Lower values mean more current synchronization but more network/CPU overhead.

Prerequisites and Network Requirements

Before configuring DHCP failover, ensure both DHCP servers meet these requirements:

Both servers must be running Windows Server 2012 or later (both should ideally be Windows Server 2022 for full feature parity). Both servers must be authorized in Active Directory. Both servers must have the DHCP Server role installed. The partner server does not need to have the scope pre-created; the failover configuration wizard replicates scope configuration to the partner automatically.

Verify both servers are authorized:

Get-DhcpServerInDC

Both servers should have static IP addresses and be reachable from each other on TCP port 647 (the DHCP failover communication port):

Test-NetConnection -ComputerName "dhcp02.corp.example.com" -Port 647

Configuring DHCP Failover — Load Balance Mode

Load Balance mode is recommended for most environments where both DHCP servers are on the same subnet or site, as it provides better utilization of both servers during normal operations.

Run the following on the primary DHCP server (dhcp01):

Add-DhcpServerv4Failover `
    -Name "HQ-LAN-Failover" `
    -PartnerServer "dhcp02.corp.example.com" `
    -ScopeId "192.168.10.0" `
    -Mode "LoadBalance" `
    -LoadBalancePercent 50 `
    -MaxClientLeadTime "01:00:00" `
    -AutoStateTransition $true `
    -StateSwitchInterval "01:00:00" `
    -SharedSecret "YourSecureSharedSecret2022!" `
    -Force `
    -PassThru

Parameters explained:

-Name: A unique name for this failover relationship. You can use the same relationship name for multiple scopes if they share the same partner.

-LoadBalancePercent: Percentage of the address pool assigned to this server. The partner gets the remaining percentage (50% here). Valid range is 0–100.

-MaxClientLeadTime: The MCLT value in HH:MM:SS format. A value of 1 hour means clients can receive lease extensions up to 1 hour beyond what the partner knows about.

-AutoStateTransition $true: Enables automatic transition to partner-down state after the switch interval.

-StateSwitchInterval: How long to wait before auto-transitioning to partner-down (1 hour here). Set to $null to disable auto-transition and require manual intervention.

-SharedSecret: A password used to authenticate communication between the two DHCP servers. Must be the same on both servers.

Configuring DHCP Failover — Hot Standby Mode

Hot Standby mode is recommended when the two DHCP servers are in different sites (active-passive across a WAN link) or when you want a clear primary/backup relationship.

Add-DhcpServerv4Failover `
    -Name "Branch-Failover" `
    -PartnerServer "dhcp02.corp.example.com" `
    -ScopeId "10.10.0.0" `
    -Mode "HotStandby" `
    -ReservePercent 10 `
    -MaxClientLeadTime "01:00:00" `
    -AutoStateTransition $true `
    -StateSwitchInterval "02:00:00" `
    -SharedSecret "YourSecureSharedSecret2022!" `
    -Force `
    -PassThru

-ReservePercent 10: In Hot Standby mode, 10% of the address pool is reserved exclusively for the standby server (dhcp02) to use when the primary (dhcp01) is unavailable. The primary handles 90% of the pool during normal operation.

A larger -StateSwitchInterval of 2 hours is used here because a WAN link flapping should not immediately trigger a full partner-down transition.

Adding Multiple Scopes to a Failover Relationship

If you have multiple DHCP scopes that should share the same failover relationship (same partner, same settings), you can add them all at once or add additional scopes later:

# Add multiple scopes to a new failover relationship at creation
Add-DhcpServerv4Failover `
    -Name "AllScopes-Failover" `
    -PartnerServer "dhcp02.corp.example.com" `
    -ScopeId "192.168.10.0","192.168.20.0","192.168.30.0" `
    -Mode "LoadBalance" `
    -LoadBalancePercent 50 `
    -MaxClientLeadTime "01:00:00" `
    -AutoStateTransition $true `
    -StateSwitchInterval "01:00:00" `
    -SharedSecret "YourSecureSharedSecret2022!" `
    -Force -PassThru

Add a new scope to an existing failover relationship:

Add-DhcpServerv4FailoverScope -Name "AllScopes-Failover" -ScopeId "192.168.40.0" -PassThru

Synchronizing Scope Configuration Between Partners

When you change scope options, reservations, or exclusions on the primary server, these changes are not automatically pushed to the partner. You must trigger a replication to keep both servers in sync.

Synchronize a specific scope to the partner:

Invoke-DhcpServerv4FailoverReplication -ScopeId "192.168.10.0" -Force -PassThru

Synchronize all scopes in a failover relationship:

Invoke-DhcpServerv4FailoverReplication -Name "HQ-LAN-Failover" -Force -PassThru

Synchronize all failover relationships on the server:

Get-DhcpServerv4Failover | ForEach-Object {
    Invoke-DhcpServerv4FailoverReplication -Name $_.Name -Force -PassThru
}

Best practice: After making any scope configuration change on the primary DHCP server, always run replication immediately to ensure the partner has current data before any potential failover event.

Monitoring Failover State

DHCP failover has several operational states. Understanding these states is essential for monitoring and troubleshooting.

Get-DhcpServerv4Failover | Format-List Name, PartnerServer, Mode, State, PartnerState, ReplicationInterval, AutoStateTransition

Key state values:

Normal: Both servers are communicating and operating correctly. This is the desired state.

CommunicationInterrupted: The servers cannot reach each other but neither has yet transitioned to partner-down. Lease assignment continues based on previously known lease data.

PartnerDown: One server has declared the other unavailable and is operating with full access to the address pool. In load balance mode, the surviving server uses all addresses. In hot standby mode, the active server now uses the reserved standby pool as well.

Recovering: The failed server has come back online and is synchronizing lease state with the active server before resuming normal operation.

PotentialConflict: Both servers independently entered partner-down state (split-brain). This is a serious state requiring administrator intervention to resolve potential duplicate lease assignments.

Monitor from both partner servers to get a full picture:

Get-DhcpServerv4Failover -ComputerName "dhcp01.corp.example.com"
Get-DhcpServerv4Failover -ComputerName "dhcp02.corp.example.com"

Manually Triggering and Recovering from Partner Down

If the partner server is going offline for planned maintenance and you want the surviving server to immediately assume full control:

Set-DhcpServerv4FailoverState -Name "HQ-LAN-Failover" -State "PartnerDown" -PassThru

After the partner server is back online, recover the failover relationship to restore normal operation:

Invoke-DhcpServerv4FailoverReplication -Name "HQ-LAN-Failover" -Force
Set-DhcpServerv4FailoverState -Name "HQ-LAN-Failover" -State "Normal" -PassThru

Removing and Modifying Failover Relationships

To remove a scope from a failover relationship (making it a standalone scope again):

Remove-DhcpServerv4FailoverScope -Name "HQ-LAN-Failover" -ScopeId "192.168.20.0" -PassThru

To delete the entire failover relationship:

Remove-DhcpServerv4Failover -Name "HQ-LAN-Failover" -Force -PassThru

To modify failover settings (such as changing the load balance percentage):

Set-DhcpServerv4Failover -Name "HQ-LAN-Failover" -LoadBalancePercent 60 -PassThru

DHCPv6 Failover Limitations

Windows Server 2022 does not support native DHCP failover for IPv6 (DHCPv6) scopes. The Add-DhcpServerv4Failover cmdlet only works with IPv4 scopes. There is no equivalent Add-DhcpServerv6Failover cmdlet.

For IPv6, alternative approaches are:

Router Advertisement (RA) with SLAAC: Stateless Address Autoconfiguration allows clients to self-assign IPv6 addresses based on the network prefix advertised by routers. This requires no DHCP server and provides inherent redundancy if multiple routers advertise.

Multiple DHCPv6 servers with split scopes: Configure two DHCPv6 servers each with non-overlapping ranges from the same prefix. If one fails, clients may receive addresses from the other. This is not true failover but provides partial redundancy.

Clustered DHCP: Windows Failover Clustering can be used for both DHCPv4 and DHCPv6 as an alternative to the native DHCP failover feature. In a cluster, the DHCP service runs as a clustered role, with one node active and others on standby. Check the cluster status:

Get-ClusterGroup -Name "DHCP Server"
Get-ClusterResource -Name "DHCP Server"

Split Scope as a Simple Alternative

The split scope approach predates native DHCP failover and is simpler but less effective. In a split scope configuration, you create the same scope on two DHCP servers, but each server has exclusion ranges preventing it from assigning addresses in the other server’s range. A common split is 80/20 — the primary server handles 80% of the range, and the secondary handles 20%.

On the primary DHCP server (handles .100–.210):

Add-DhcpServerv4Scope -Name "HQ-Primary" -StartRange "192.168.10.100" -EndRange "192.168.10.249" -SubnetMask "255.255.255.0" -State Active
Add-DhcpServerv4ExclusionRange -ScopeId "192.168.10.0" -StartRange "192.168.10.211" -EndRange "192.168.10.249"

On the secondary DHCP server (handles .211–.249):

Add-DhcpServerv4Scope -Name "HQ-Secondary" -StartRange "192.168.10.100" -EndRange "192.168.10.249" -SubnetMask "255.255.255.0" -State Active
Add-DhcpServerv4ExclusionRange -ScopeId "192.168.10.0" -StartRange "192.168.10.100" -EndRange "192.168.10.210"

If the primary fails, clients receive addresses from the secondary’s 20% pool. The drawback is that the two servers do not share lease state, so in a failover scenario the surviving server may assign addresses that were previously leased by the failed server, causing IP conflicts until the original leases expire.

For new deployments on Windows Server 2022, the native failover feature is strongly preferred over split scopes because of its proper lease state synchronization.

Conclusion

DHCP failover on Windows Server 2022 provides robust IP address continuity with minimal administrative overhead. By choosing the appropriate mode — Load Balance for high-availability active-active environments, or Hot Standby for active-passive disaster recovery scenarios — and correctly configuring MCLT, auto-state switchover intervals, and regular replication, administrators can eliminate DHCP as a single point of failure. Regular monitoring of failover state via Get-DhcpServerv4Failover and proactive replication after configuration changes ensures both partners remain synchronized and ready to take over seamlessly when needed.