DHCP Failover on Windows Server: Setup and Real-World Gotchas

DHCP is the service nobody thinks about until it stops, at which point the whole building notices within about four hours. Failover has been built into Windows Server since 2012 and takes roughly ten minutes to configure, which makes it one of the best returns on effort available in a Windows estate.

The setup is easy. What is less obvious is which mode to choose, what the timers actually do, and what happens in the awkward middle state where one server is down but the other has not yet decided it is allowed to take over. That is where this guide spends most of its time.

Before you start

Both servers need the DHCP role installed and authorised in Active Directory. They should be in the same site with reliable connectivity, running the same Windows Server version where possible, and time-synchronised. Failover is sensitive to clock drift because the whole model depends on both partners agreeing what time it is.

Crucially, only configure failover on the server that currently holds the scopes. The wizard replicates the scope to the partner. If both servers already have the same scope configured independently, remove it from the second one first or you will end up with a conflict you have to unpick.

Load balance or hot standby?

Load balance is the default and the right answer for most single-site networks. Both servers actively serve clients, splitting the address pool by a percentage you set: 50/50 unless you have a reason otherwise. Both are working all the time, so you find out immediately if one is misbehaving rather than discovering it during an outage.

Hot standby suits a branch-office pattern, where the standby lives at head office and should not normally answer local clients. You give it a reserved percentage of the range, five percent is typical, to use while it is covering for the primary.

Configuring it

The same thing in PowerShell, which is worth knowing because it is far quicker when you are rebuilding:

Add-DhcpServerv4Failover -ComputerName dhcp01.corp.local -PartnerServer dhcp02.corp.local -Name "corp-failover" -ScopeId 10.10.0.0 -LoadBalancePercent 50 -MaxClientLeadTime 01:00:00 -SharedSecret (Read-Host -AsSecureString)

# Add further scopes to an existing relationship
Add-DhcpServerv4FailoverScope -ComputerName dhcp01.corp.local -Name "corp-failover" -ScopeId 10.20.0.0

# Check the state of every relationship
Get-DhcpServerv4Failover -ComputerName dhcp01.corp.local | Format-List Name,Mode,State,PartnerServer

The gotchas that only appear later

Partner down is not automatic by default. When a partner disappears, the survivor enters a communication interrupted state, in which it keeps serving only its own share of the pool. It does not take over the full range until it is put into partner down state, and then only after the MCLT has elapsed. If you leave State Switchover Interval disabled, that transition is a manual step someone has to know to perform. Document it, or set the interval to 60 minutes and let it happen on its own.

Server-level options do not replicate. Failover replicates scope-level settings. Options set at the server level. A default DNS server list, for instance. Are not synchronised. Configure them identically on both partners by hand, and check them after any change.

Reservations replicate, but only inside failover scopes. A reservation in a scope that is part of the relationship comes across. One in an excluded scope does not. Audit which scopes are actually in the relationship rather than assuming all of them are.

Policies need explicit replication. If you use DHCP policies for device-class-based options, replicate the scope after changing them with Invoke-DhcpServerv4FailoverReplication. Policy changes do not always propagate on their own.

Restoring from backup breaks the relationship. Restoring a DHCP database onto one partner leaves the two with different lease views. Delete and recreate the failover relationship after any restore rather than hoping it reconciles.

Verifying it actually works

Configuring failover and never testing it is common and pointless. Test it deliberately, out of hours, with a plan to undo it.

# Force a replication and confirm both sides agree
Invoke-DhcpServerv4FailoverReplication -ComputerName dhcp01.corp.local -Force

# Manually declare the partner down (survivor only)
Set-DhcpServerv4Failover -ComputerName dhcp01.corp.local -Name "corp-failover" -PartnerDown

# Return to normal once the partner is back
Set-DhcpServerv4Failover -ComputerName dhcp01.corp.local -Name "corp-failover" -State Normal

# Compare lease counts on both partners
Get-DhcpServerv4ScopeStatistics -ComputerName dhcp01.corp.local
Get-DhcpServerv4ScopeStatistics -ComputerName dhcp02.corp.local

Stop the DHCP service on one partner, confirm clients still get addresses, then confirm the state transitions the way you expect. Write down what you did, because the person handling it at three in the morning will not be you.

Glossary

Frequently asked questions

Can DHCP failover use more than two servers?

No. A failover relationship is strictly between two servers. You can build multiple relationships across different scopes, but any single scope has exactly two partners.

Does DHCP failover need a cluster or shared storage?

No, and that is the main advantage over the old clustered DHCP approach. Each server keeps its own database and the two synchronise lease information directly.

What happens if both DHCP servers go down?

Clients keep their existing leases until they expire, so nothing breaks immediately. New devices and anyone past the renewal point will fail. This is why lease duration is worth thinking about, eight days gives you a comfortable window.

Should I enable automatic state switchover?

For most environments yes, set to around 60 minutes. It removes a manual step that is easy to forget during an incident. Leave it disabled only if you specifically want a human decision before a takeover.

Do split scopes still have a place?

Rarely. Split scopes were the pre-2012 workaround and required manual exclusion management on both servers. Failover does the same job properly, and there is no good reason to build a new split scope today.

Disclosure: this post may contain affiliate links. If you buy through one of them, we may earn a small commission at no extra cost to you. We only recommend products we’ve tested or genuinely rate.