Windows Server DHCP failover does not take over the moment a partner dies. When we pulled the power on the first server, the second needed 67 seconds to notice and 5 more minutes to declare the partner down. Only after one full MCLT (10 minutes in our lab) did it lease from the half of the pool owned by the dead server. Existing clients never noticed, because the survivor kept renewing them. New clients feel the gap, and its size depends on the MCLT and the state switchover interval.
This guide configures failover between two servers in an Active Directory domain with PowerShell, then breaks it on purpose: a power-off, a service stop, a manual PARTNER DOWN and two recoveries. You will see when load balance beats hot standby, which event IDs mark each state change and what clients received. The full takeover after the power-off took 16 minutes 7 seconds (benchmarked October 2026 on Windows Server 2025, build 26100).
Load Balance vs Hot Standby: What We Measured
Load balance is the default and the right choice when both servers sit on the same site: each one owns half of the free addresses and both answer clients all day. Hot standby keeps one server idle with a small reserve, which suits a branch office whose DHCP server should not lean on a server across a WAN link unless it has to. The table below holds the numbers from our lab for both modes.
| Measurement | Load balance (50/50) | Hot standby (5% reserve) |
|---|---|---|
| Free addresses per server, scope of 101 | 46 and 43 after 12 leases | 84 on the active server, 5 on the standby |
| Who answered new clients (NORMAL) | DC01: 7 of 10, DHCP02: 3 of 10 | DC01: 4 of 4 |
| First lease to a new client | 600 s (equal to the MCLT) | 600 s |
| Lease after the first renewal | 691,200 s (8 days) | not re-measured |
| Partner powered off: COMMUNICATION INTERRUPTED after | 67 s | not tested |
| Partner DHCP service stopped: COMMUNICATION INTERRUPTED after | not tested | immediately |
| COMMUNICATION INTERRUPTED to PARTNER DOWN | 5 min 0 s (auto, StateSwitchInterval) | 1 s after the manual -PartnerDown |
| PARTNER DOWN to taking the partner’s free pool | 10 min 0 s (MCLT) | not waited out |
| Partner back to NORMAL | 1 to 2 s after contact | 10 min 1 s after contact (RECOVER WAIT) |
Three rows deserve a closer read. The 7 to 3 split is not a fault: Windows hashes each client MAC to pick the owning server, so a 50/50 relationship only evens out over hundreds of clients, never over ten. The 600-second first lease is the MCLT at work, since a server cannot promise a lease longer than its partner has heard about. And the two recovery times differ because of how the partner went away, which Step 6 explains. Pick a mode with these rules:
- Both servers on one site or one fast link: load balance. Both carry traffic, and during an outage the survivor keeps answering new clients, on short leases.
- A branch server backed up by a hub server: hot standby, with the branch server as active. The hub only answers from its reserve while the link or the branch server is down.
- A scope that is more than 90% used: fix the scope size first. A 5% reserve on a 100-address scope is 5 addresses, and that is all the standby can give new clients during COMMUNICATION INTERRUPTED.
DHCP failover needs no shared storage and no cluster, since the two servers replicate leases to each other. Keep Windows Server failover clustering for roles that cannot replicate their own state. The Microsoft DHCP failover overview lists the hard limits: two servers per relationship, IPv4 scopes only, and partner clocks within one minute of each other. The defaults are a 50% split for load balance, a 5% reserve for hot standby and an MCLT of 1 hour.
How the Lab Is Built
We kept the lab on its own VLAN so the test DHCP servers could never answer a real client, which also means the 10.0.1.0/24 addresses below are the ones the lab really used. DC01 runs AD DS, DNS and DHCP. DHCP02 is a plain domain member with only the DHCP role, which is the layout most small sites end up with.
The client side is a Rocky Linux VM named bench01 with a second NIC on the test VLAN. Each macvlan interface on that NIC has its own MAC address, so one VM behaves like 16 extra DHCP clients on top of its own NIC, and NetworkManager prints the server identifier and lease time each one received.
- DC01, 10.0.1.10: Windows Server 2025 Datacenter, 2 vCPU, 4 GB RAM, forest root of corp.example.com.
- DHCP02, 10.0.1.11: Windows Server 2025 Datacenter, 2 vCPU, 4 GB RAM, member server.
- Scope 10.0.1.0/24: range 10.0.1.100 to 10.0.1.200 (101 addresses), router 10.0.1.1, DNS 10.0.1.10, 8-day lease.
- Ports: UDP 67 from clients to both servers, TCP 647 between the partners. The DHCP role opens both in Windows Firewall when it installs.
If the servers are new, the Windows Server 2025 install guide gets you to a patched desktop. If you still need the domain itself, set up AD DS with PowerShell first, and point DHCP02’s DNS client at the domain controller before you join it, because the join and the failover cmdlets both resolve the partner by name through the Windows DNS server on DC01.
Step 1: Install the DHCP Role on Both Servers
Both partners need the same role and the management tools, because the failover cmdlets run from either side and talk to the other one over RPC. Open an elevated PowerShell session on each server and install the role:
Install-WindowsFeature DHCP -IncludeManagementToolsOn DHCP02 the install returned in one pass with no reboot needed, and the tools came along with the role:
Success : True
RestartNeeded : No
FeatureResult : {DHCP Server, Remote Server Administration Tools, DHCP Server Tools, Role Administration Tools}
ExitCode : SuccessThe role does not create its two local security groups until you ask for them. Run this on both servers; we restarted the service afterwards so it would use them:
Add-DhcpServerSecurityGroup
Restart-Service DHCPServerBefore we ran it, the System log on DC01 carried event 1036, “The DHCP server was unable to create or lookup the DHCP Administrators local group on this computer”, logged at 1:31:46 PM. The groups exist afterwards as DHCP Administrators and DHCP Users.
Step 2: Authorize Both DHCP Servers in Active Directory
A domain-joined DHCP server refuses to lease anything until it is listed in Active Directory, and that applies to the partner as much as to the first server. This is the most common reason a new Windows Server 2025 DHCP server looks installed and healthy yet clients never get an address. Run it from either server as a member of Enterprise Admins. We used the domain Administrator of a single-domain forest:
Add-DhcpServerInDC -DnsName dc01.corp.example.com -IPAddress 10.0.1.10
Add-DhcpServerInDC -DnsName dhcp02.corp.example.com -IPAddress 10.0.1.11
Get-DhcpServerInDCBoth servers should appear in the list. If one is missing, it will log event 1046 and serve nobody, as described under Errors we hit:
IPAddress DnsName
--------- -------
10.0.1.10 dc01.corp.example.com
10.0.1.11 dhcp02.corp.example.comAfter a PowerShell install, Server Manager can keep showing its “Complete DHCP configuration” notice, because the post-install wizard never ran (we set the flag in the lab without capturing the notice). Setting the configuration flag of the role clears the warning and changes nothing else. DHCP leases fine without it. Run it on each server:
Set-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\ServerManager\Roles\12 -Name ConfigurationState -Value 2Authorization lives in Active Directory, not on the server, so a retired DHCP server stays on that list until you remove it with Remove-DhcpServerInDC.
Step 3: Create the Scope on the First Server Only
The scope is created once, on DC01. The failover cmdlet in Step 4 copies the scope, its options and every existing lease to the partner, so building it on DHCP02 as well would only cause a conflict. Create the scope and its options:
Add-DhcpServerv4Scope -Name 'Office LAN' -StartRange 10.0.1.100 -EndRange 10.0.1.200 -SubnetMask 255.255.255.0 -State Active
Set-DhcpServerv4OptionValue -ScopeId 10.0.1.0 -Router 10.0.1.1 -DnsServer 10.0.1.10 -DnsDomain corp.example.com
Get-DhcpServerv4ScopeWith no -LeaseDuration, the scope takes the 8-day default:
ScopeId SubnetMask Name State StartRange EndRange LeaseDuration
------- ---------- ---- ----- ---------- -------- -------------
10.0.1.0 255.255.255.0 Office LAN Active 10.0.1.100 10.0.1.200 8.00:00:00Before going further, we let one client take a lease from DC01 alone. It received 10.0.1.100 with a lease of 691,200 seconds, which is the 8 days in the table above. That lease becomes useful in a moment, because it shows whether existing leases travel to the partner.
Step 4: Configure DHCP Failover with PowerShell
One command on DC01 creates the relationship, copies the scope to DHCP02 and starts the TCP 647 session between them. We shortened the MCLT to 10 minutes and set a 5-minute automatic switch to PARTNER DOWN so the outage tests would finish in one sitting; the defaults are 1 hour and no automatic switch at all.
Add-DhcpServerv4Failover -ComputerName dc01.corp.example.com -Name 'dc01-dhcp02' -PartnerServer dhcp02.corp.example.com -ScopeId 10.0.1.0 -LoadBalancePercent 50 -MaxClientLeadTime 00:10:00 -StateSwitchInterval 00:05:00 -SharedSecret 'Lab-Failover-Secret1' -ForceEach parameter here changes how the outage plays out, so it is worth knowing what each one buys you before you copy the values:
- -LoadBalancePercent 50: the share of client requests this server answers, which also decides how the free addresses are split. Passing it instead of
-ServerRolecreates a load balance relationship. - -MaxClientLeadTime: how far a server may extend a lease beyond what its partner knows, and how long it waits in PARTNER DOWN before taking the whole pool.
- -StateSwitchInterval: turns on the automatic move from COMMUNICATION INTERRUPTED to PARTNER DOWN. Without it, a server waits for you indefinitely.
- -SharedSecret: enables message authentication between the partners. Pick your own value; without it, authentication is off.
The command returned in 0.76 seconds. Read the relationship back from both partners, since each one keeps its own copy:
Get-DhcpServerv4Failover -ComputerName dhcp02.corp.example.comDHCP02 lists DC01 as its partner, the same mode and timers, and State Normal. EnableAuth True confirms the shared secret took:
Name : dc01-dhcp02
PartnerServer : dc01.corp.example.com
Mode : LoadBalance
LoadBalancePercent : 50
ServerRole :
ReservePercent :
MaxClientLeadTime : 00:10:00
StateSwitchInterval : 00:05:00
State : Normal
ScopeId : 10.0.1.0
AutoStateTransition : True
EnableAuth : TrueThe scope, the router, DNS and lease options and the 10.0.1.100 lease from Step 3 were all on DHCP02 within the same second. The per-server split shows up in the failover statistics:
Get-DhcpServerv4ScopeStatistics -ComputerName dc01.corp.example.com -FailoverThe 100 free addresses were cut into two halves of 50, and the one lease in use belonged to DC01:
ScopeId : 10.0.1.0
AddressesFree : 100
AddressesInUse : 1
PendingOffers : 0
ReservedAddress : 0
PercentageInUse : 0.990099
SuperscopeName :
AddressesFreeOnThisServer : 50
AddressesFreeOnPartnerServer : 50
AddressesInUseOnThisServer : 1
AddressesInUseOnPartnerServer : 0Then we brought up ten new clients at once. DC01 answered seven of them from 10.0.1.101 to 10.0.1.107, and DHCP02 answered three from 10.0.1.151 to 10.0.1.153, so each server leases from its own end of the range. Every one of those first leases was 600 seconds long, not 8 days. The clients renewed about nine minutes later and only then received the full 691,200 seconds. That fits the Microsoft definition of the MCLT as the most a server may extend a lease beyond what its partner knows: the partner knew nothing about these clients yet, so they got one MCLT.
The DHCP console also has a Configure Failover wizard on the scope menu; we did not use it, and only opened the console to read the result. The relationship shows up in the properties of the IPv4 node:
- 1Failover tab
- 2dc01-dhcp02
- 3State of the server
- 4Mode
This capture was taken on DC01 after the switch to hot standby in Step 7, so it shows the end state of the lab:
- Failover tab: right-click the IPv4 node and open Properties. The scope list also gains a Failover Relationship column.
- dc01-dhcp02: every relationship this server belongs to, one line each.
- State of the server: the same value
Get-DhcpServerv4Failoverreturns, Normal here. - Mode: Hot standby after Step 7, Load balance before it.
The console is fine for reading state, but scripts keep both servers identical, so the rest of this guide stays in PowerShell.
Step 5: Kill the Partner and Watch the Lease Takeover
We hard-stopped DC01 from the hypervisor at 14:09:54, the closest thing to a power cut, and watched DHCP02 from its own console. Two commands give you the whole picture during an outage: the relationship state and the DHCP admin event log.
Get-DhcpServerv4Failover | Select-Object Name, State
Get-WinEvent -LogName DhcpAdminEvents -MaxEvents 5 | Format-List TimeCreated, Id, MessageFor the first minute DHCP02 still reported Normal, because nothing had told it the partner was gone until the TCP 647 session to DC01 went quiet. These are the events it wrote, oldest at the bottom:
TimeCreated : 10/30/2026 2:16:01 PM
Id : 20251
Message : The failover state of server: dhcp02.corp.example.com for failover relationship: dc01-dhcp02 changed from: COMMUNICATION_INT to PARTNER_DOWN.
TimeCreated : 10/30/2026 2:11:01 PM
Id : 20252
Message : The failover state of server: dhcp02.corp.example.com for failover relationship: dc01-dhcp02 changed from: NORMAL to COMMUNICATION_INT.
TimeCreated : 10/30/2026 2:11:01 PM
Id : 20255
Message : Server has lost contact with failover partner server 10.0.1.10 for relationship dc01-dhcp02 .COMMUNICATION INTERRUPTED arrived 67 seconds after the power-off, and PARTNER DOWN exactly 5 minutes later, matching the StateSwitchInterval. In between, DHCP02 does not assume DC01 is dead; it assumes the link might be, and that DC01 might still be leasing on the other side. That caution shapes what clients get, which is why we tested both kinds of client during the interruption at 14:11:23.
A client that DC01 had leased 10.0.1.101 to renewed against DHCP02 and kept its address with a full 8-day lease. The lease table on DHCP02 explains why it could: the new expiry of 11/7/2026 2:11:21 PM was only 2 minutes 39 seconds past the 2:08:42 PM expiry that DC01 had already replicated, well inside the 10-minute MCLT. A brand-new client got 10.0.1.154 from the half that DHCP02 owns, with a 600-second lease. Existing clients ride through a partner outage untouched. New clients get short leases from the free pool of the survivor first. Microsoft documents that a load balance server then moves on to the free pool of its partner once its own runs out.
At 14:26:01, one MCLT after PARTNER DOWN, DHCP02 logged the event that marks the real takeover:
TimeCreated : 10/30/2026 2:26:01 PM
Id : 20288
Message : This DHCP server dhcp02.corp.example.com has transitioned to a PARTNER DOWN state for the failover relationship dc01-dhcp02 and the MCLT period of 600 seconds has expired. The server has taken over the free IP address pool of the partner server dc01.corp.example.com for all scopes
which are part of the failover relationship.Watch for that event rather than the statistics. Get-DhcpServerv4ScopeStatistics -Failover on DHCP02 kept showing 46 free addresses on this server and 43 on the partner for the whole outage, before and after event 20288, so the split counters do not tell you a takeover happened. With the default 1-hour MCLT and no automatic switch, none of this happens on its own: DHCP02 would sit in COMMUNICATION INTERRUPTED until someone runs the manual switch shown in Step 7.
Step 6: Bring the Partner Back
How fast a returning partner rejoins depends on what it knew when it went away, and we saw both paths: one after the power-off above, one after the manual PARTNER DOWN in Step 7. After the power-off, DC01 came back 50 seconds after we started it, made contact at 14:28:23 and was in NORMAL within two seconds. The block below is the same Get-WinEvent output trimmed to the state changes, all of them event 20251:
TimeCreated : 10/30/2026 2:28:24 PM
Message : The failover state of server: dhcp02.corp.example.com for failover relationship: dc01-dhcp02 changed from: POTENTIAL_CONFLICT to NORMAL.
TimeCreated : 10/30/2026 2:28:23 PM
Message : The failover state of server: dc01.corp.example.com for failover relationship: dc01-dhcp02 changed from: POTENTIAL_CONFLICT to CONFLICT_DONE.
TimeCreated : 10/30/2026 2:28:23 PM
Message : The failover state of server: dhcp02.corp.example.com for failover relationship: dc01-dhcp02 changed from: PARTNER_DOWN to POTENTIAL_CONFLICT.
TimeCreated : 10/30/2026 2:28:23 PM
Message : The failover state of server: dc01.corp.example.com for failover relationship: dc01-dhcp02 changed from: COMMUNICATION_INT to POTENTIAL_CONFLICT.DC01 had been cut off without warning, so it woke up believing only that communication was interrupted (event 20259 on DHCP02 reported its state as COMMUNICATION_INT at 2:28:23 PM). The two servers then passed through POTENTIAL_CONFLICT, where they compare bindings because either side might have leased the same address, and DC01 reported CONFLICT_DONE before both returned to NORMAL. The second outage in Step 7 ended differently: DC01 restarted its service while DHCP02 was already in PARTNER DOWN, so DC01 went through RECOVER and then waited in RECOVER_WAIT for exactly one MCLT, from 2:33:35 PM to 2:43:35 PM, before NORMAL. DHCP02 stayed in PARTNER DOWN and carried every client for those 10 minutes, which is the price of a long MCLT that you only pay after a declared PARTNER DOWN.
Step 7: Switch to Hot Standby and Force PARTNER DOWN
An existing relationship changes mode in place, with no need to delete and recreate it. Run the change on the server that should become active; the partner turns into the standby:
Set-DhcpServerv4Failover -ComputerName dc01.corp.example.com -Name dc01-dhcp02 -Mode HotStandby -ReservePercent 5 -ForceReading the relationship from DC01 afterwards shows ServerRole Active and ReservePercent 5, and DHCP02 reports itself as Standby. The pool moved with it: DC01 now owned 84 free addresses and DHCP02 only 5. Four new clients created after the switch were all answered by DC01, as they should be.
To test the manual path we stopped only the DHCP Server service on DC01, leaving the machine up. DHCP02 logged COMMUNICATION_INT at 2:32:20 PM, at once rather than after 67 seconds, because a clean service stop closes the TCP session instead of letting it time out. A new client then got 10.0.1.196 from the 5-address reserve on the standby, again with a 600-second lease. When you know the partner is not coming back soon, do not wait for the timer; declare it down on the surviving server:
Set-DhcpServerv4Failover -ComputerName dhcp02.corp.example.com -Name dc01-dhcp02 -PartnerDown -ForceThe state changed one second later. Only do this when you are sure the partner is really down, because two servers that both believe they own the whole pool can lease one address twice:
TimeCreated : 10/30/2026 2:33:16 PM
Id : 20251
Message : The failover state of server: dhcp02.corp.example.com for failover relationship: dc01-dhcp02 changed from: COMMUNICATION_INT to PARTNER_DOWN.The reserve is the number to size carefully in hot standby. During COMMUNICATION INTERRUPTED the standby hands new clients nothing but those reserved addresses, and once they run out it only renews existing clients; the rest of the pool opens to it only after PARTNER DOWN plus one MCLT.
Step 8: Replicate Scope Changes to the Partner
Failover replicates leases continuously, but not configuration. A scope option added on DC01 stays on DC01 until you push it, so a client that lands on DHCP02 would quietly get a different set of options. We added an NTP server option on DC01 to see it happen:
Set-DhcpServerv4OptionValue -ComputerName dc01.corp.example.com -ScopeId 10.0.1.0 -OptionId 42 -Value 10.0.1.10
Get-DhcpServerv4OptionValue -ComputerName dhcp02.corp.example.com -ScopeId 10.0.1.0DHCP02 still listed only the original four options, with no option 42:
OptionId Name Value
-------- ---- -----
15 DNS Domain Name {corp.example.com}
3 Router {10.0.1.1}
6 DNS Servers {10.0.1.10}
51 Lease {691200}Push the configuration for every scope in the relationship from the server you edited:
Invoke-DhcpServerv4FailoverReplication -ComputerName dc01.corp.example.com -Name dc01-dhcp02 -ForceThe cmdlet prints the scope IDs it replicated, here just 10.0.1.0, and DHCP02 then carried the new option:
OptionId Name Value
-------- ---- -----
15 DNS Domain Name {corp.example.com}
3 Router {10.0.1.1}
6 DNS Servers {10.0.1.10}
51 Lease {691200}
42 NTP Servers {10.0.1.10}Make that command part of every scope change, or edit scopes only on one server and replicate from there. Reservations, exclusions and policies follow the same rule.
Errors We Hit
Two of these stopped the lab outright, and the third is a trap in the monitoring rather than an error message.
Event 1046: “has determined that it is not authorized to start”
Right after the domain was promoted, DC01’s DHCP service was running and the scope was active, yet the test client sat with no offer. The System log had the reason, logged next to event 1059, “The DHCP service failed to see a directory server for authorization”:
The DHCP/BINL service on the local machine, belonging to the Windows Administrative domain corp.example.com, has determined that it is not authorized to start. It has stopped servicing clients.Running Add-DhcpServerInDC from Step 2 fixed it, and the client received 10.0.1.100 on its next request. If you see this on Windows Server 2025 with DHCP otherwise looking healthy, check Get-DhcpServerInDC before anything else. The same check applies to a single server built with our DHCP server install guide.
“The user name or password is incorrect” when joining the partner
DHCP02 refused to join the domain with credentials that worked everywhere else. Add-Computer failed with “Computer ‘DHCP02’ failed to join domain ‘corp.example.com’ from its current workgroup ‘WORKGROUP’ with following error message: The user name or password is incorrect.”, and DC01 logged event 4625 with status 0xC000006D. The clock was not the cause (the offset was 0.26 seconds). Comparing SIDs found the cause. Read the local Administrator SID on the member; everything before the final -500 is the machine SID:
(Get-LocalUser Administrator).SID.ValueOn DHCP02 that returned S-1-5-21-3778530057-3768371804-1503282553-500, and the domain SID on DC01 was S-1-5-21-3778530057-3768371804-1503282553. Both VMs had been cloned from the same template, whose own sysprep run had failed, so the member carried the same machine SID as the domain. Generalize the clone again before joining it. Our first sysprep attempt stopped with “SYSPRP RunDlls:Not running DLLs; either the machine is in an invalid state or we couldn’t update the recorded state, dwRet = 0x1f” because the template left GeneralizationState at 3; resetting it to 7 let sysprep finish. Treat that reset as a workaround for a template whose sysprep already broke, not as a routine step:
Set-ItemProperty HKLM:\SYSTEM\Setup\Status\SysprepStatus -Name GeneralizationState -Value 7
C:\Windows\System32\Sysprep\sysprep.exe /generalize /oobe /reboot /quiet /unattend:C:\lab\unattend.xmlThe answer file is the one our template already carried for Cloudbase-Init. It skips the OOBE screens. Without one, finish OOBE on the console after the reboot. The server came back with a new SID, its static IP and the DHCP role still in place, but with a random name, so we renamed it in the same step as the join with Add-Computer -DomainName corp.example.com -NewName DHCP02, which then succeeded on the first try. Anyone building the partner from a VM template, including the Proxmox Windows Server template route, should compare SIDs before the join rather than after.
Failover statistics that never move
As noted in Step 5, AddressesFreeOnThisServer did not change when DHCP02 took over DC01’s pool. A dashboard built on those counters would report the survivor as half-capacity for the whole outage. Alert on event 20288 instead.
What to Watch in the Failover Event Log
Every transition in this lab left an entry in the DhcpAdminEvents log, so that log is the one to forward to your monitoring. These are the IDs we saw and what each one meant in practice:
| Event ID | Level | Meaning in the lab | Act on it? |
|---|---|---|---|
| 20255 | Error | Lost contact with the partner on TCP 647 | Yes, check the partner and the link |
| 20252 | Error | NORMAL to COMMUNICATION_INT | Yes, new clients now get short leases |
| 20251 | Information | Any other state change, including PARTNER_DOWN and back to NORMAL | Read the from/to states |
| 20288 | not captured | MCLT expired in PARTNER DOWN, partner’s free pool taken over | Yes, the partner is now fully out of service |
| 20254 | Information | Contact with the partner re-established | Confirm NORMAL follows |
| 20259 | Information | Partner’s state reported on reconnect | No |
| 1046 | System log | Server not authorized in AD, serving nobody | Yes, run Add-DhcpServerInDC |
Two timers decide how long those events take to arrive, and we would set them deliberately rather than keep the defaults. A StateSwitchInterval turns a partner failure into an automatic takeover instead of a page at 3 a.m., and an MCLT shorter than the 1-hour default shortens both the wait for the full pool and the RECOVER_WAIT a returning partner sits through. The cost is short first leases for new clients, which matter little on a LAN. For the base DHCP setup on a single server, our guide to configuring a DHCP server on Windows Server covers scopes and options in more detail, and the Add-DhcpServerv4Failover reference lists every parameter.
