Windows DHCP Failover: Partner Down, Lease Conflicts and Recovery

Direct answer: Windows DHCP failover keeps two lease databases in step over TCP port 647. When the two servers lose contact, each goes into communication interrupted. In that state it renews existing clients for a short time and serves new clients within limits, but it does not take responsibility for the whole pool. In hot standby the standby can run out of its reserve; in load balance Microsoft's wording on the partner's free addresses is ambiguous (see How it works), so read the scope statistics rather than assume. By default nothing moves a server out of that state automatically. An administrator must tell the surviving server that its partner is down. After a wait equal to the maximum client lead time (MCLT, 1 hour by default), the surviving server can then use the whole pool.

Use these rules:

• Declare a partner down only when you know it is not serving clients. Declaring partner down on both sides of a network split is how two servers come to hand out the same address.
• When a failed server comes back, let it reintegrate from the partner that kept serving. Keep a server restored from a backup offline from clients unless a supported, rehearsed recovery plan exists.
• Replicate scope settings only from the server whose settings are correct. Replication overwrites the partner.

During recovery, turn on conflict detection for a while and investigate declined addresses; they are indicators of remaining duplicates.

Why it matters

Failover is usually set up once and forgotten until a server fails. Failures show up as symptoms, not clear errors:

• New devices get no address or a link-local one, while existing devices keep working: a server in communication interrupted serving within its limits.
• Two devices report an address conflict: a server leased an address without knowing the partner had, after a restore from an old copy, after both servers believed the other was down, or after a one-sided scope change.
• Clients get different options (DNS, gateway, lease time) depending on which server answered: scope options changed on one server and never replicated.
• DNS records stop updating after a failover event: Microsoft requires both partners to use the same DNS credentials when DHCP registers records for clients.

Virtual machines add a hazard: a DHCP server VM restored from a snapshot or backup holds a lease database days or weeks old, and on the client network it offers addresses from stale information.

How it works

Two servers, two databases, one protocol

Microsoft's DHCP failover overview describes these properties:

• Exactly two DHCP servers, DHCPv4 scopes only.
• Each server keeps its own synchronised lease database; either can renew a lease the other issued.
• Both partners must run at least Windows Server 2016.
• The partners keep a persistent TCP connection on port 647. Installing the role adds the firewall rules Microsoft-Windows-DHCP-Failover-TCP-In and Microsoft-Windows-DHCP-Failover-TCP-Out.
• Clients must be able to reach both servers. Where a relay forwards DHCP across subnets, it needs both server addresses. Microsoft also warns that VRRP or HSRP router pairs can produce duplicate relayed requests.
• Scope configuration changes are not replicated automatically; replication copies settings from the server where you start it, overwriting the partner's.
• A clock difference over one minute stops the setup wizard and, on running servers, logs a critical event.

Microsoft's Win32 documentation says the state machine follows the expired IETF draft-ietf-dhc-failover-12. Its design: partners that cannot talk keep serving inside limits meant to prevent duplicate leases, and only when an operator confirms one partner is down may the survivor take over its resources.

The two modes

The current overview is not fully consistent. For load balance it says a server that loses contact uses its own free pool and then its partner's. For hot standby it says a server in communication interrupted does not use the entire pool, tying 100% responsibility to partner down. How much of the partner's pool a load-balance server takes, or when, is not stated. Treat the table as a description, not a precise sequence, and base decisions on the observed state (Check 1) and the failover scope statistics (Check 3).

The maximum client lead time

The MCLT is the longest time one server may extend a lease beyond what its partner knows about. It does two jobs:

• It caps the risk while the partners are apart. A lease granted or extended without the partner's knowledge stays short.
• It sets the wait after partner down. The survivor waits one MCLT before it takes over the partner's available addresses. The wait does not mean every lease the partner granted has expired: addresses already leased to clients stay protected by their own expiry times, and the survivor keeps honouring them.

The Add-DhcpServerv4Failover page gives a default of 1 hour. Microsoft's legacy Windows Server 2012 settings page adds that the MCLT cannot be zero. In the expired IETF protocol design, each binding carries an expiry and a "potential expiration" the partner has acknowledged, and only free addresses become allocatable by the survivor after the MCLT wait; Microsoft's pages do not restate that detail for current Windows. A longer MCLT means a longer wait before the survivor can use the whole pool. A shorter one means shorter temporary leases while the partners are apart.

The states you will see

The Win32 FSM_STATE enumeration lists the states. These are the ones that matter in a recovery:

Two consequences matter for the decisions below. A server in POTENTIAL CONFLICT or RECOVER WAIT is not serving clients. That is by design, and it should not be "fixed" by forcing a state. And the two partners take different paths back. The returning server, which must update its bindings from the partner, can go through RECOVER, RECOVER WAIT and RECOVER DONE. The survivor, which ran in partner down, does not pass through RECOVER: Microsoft describes RECOVER DONE as an interlocked transition for one server coming from RECOVER and the other from PARTNER DOWN or COMMUNICATIONS INTERRUPTED, and the protocol draft keeps the survivor in PARTNER DOWN until its peer reaches RECOVER DONE. Depending on the states each server was in, the pair may instead go through POTENTIAL CONFLICT and CONFLICT DONE.

Automatic state transition

Add-DhcpServerv4Failover sets AutoStateTransition to False by default. If you pass a StateSwitchInterval, it becomes True. The legacy settings page says that without automatic transition a server stays in communication interrupted until an administrator moves it to partner down. With automatic transition it moves on its own after the interval.

Microsoft gives no reason for the default. The consequence to weigh: if the link between the partners fails while both still reach clients, automatic transition puts both into partner down after the interval, and both serve the whole pool. Whether that can happen is a network design question (Decision 5).

Read-only checks

None of these was run for this article; all read configuration, events or lease data. Reading needs a delegated right, usually DHCP Users, DHCP Administrators or local Administrators; the sources do not list rights per cmdlet. Run each check from a management host with -ComputerName against both partners: the difference between their views is often the diagnosis.

1. The relationship as each server sees it

# Read-only. Repeat with -ComputerName DHCP02.
Get-DhcpServerv4Failover -ComputerName DHCP01 |
    Format-List Name, PartnerServer, Mode, State, PartnerState, MaxClientLeadTime,
                AutoStateTransition, StateSwitchInterval, LoadBalancePercent,
                ReservePercent, ScopeId

Record each server's state, its view of the partner's state, the mode, the MCLT and automatic transition. If a property is missing on your build, use Format-List *.

2. When and why the state changed

# Read-only. State changes, lost/restored contact and clock warnings.
Get-WinEvent -ComputerName DHCP01 -LogName 'Microsoft-Windows-DHCP Server Events/Admin' -MaxEvents 200 |
    Where-Object { $_.Message -match 'failover|partner' } |
    Select-Object TimeCreated, Id, LevelDisplayName, Message

Microsoft's failover events page describes:

• State change events in the Admin channel, with previous and current state, relationship and host (example ID 20252): Error on leaving NORMAL or entering PARTNER DOWN, Information on returning to NORMAL, Warning otherwise.
• CommDown and CommUp when contact is lost and restored.
• Event 20253 for clocks out of sync, with the difference in seconds.

The Operational channel (Microsoft-Windows-DHCP Server Events/Operational) records configuration changes, such as relationships, scopes, MCLT, mode and interval, so you can see who changed what and when.

3. Is the pool really exhausted, and on which server?

# Read-only. -Failover adds failover-related statistics for scopes in a relationship.
Get-DhcpServerv4ScopeStatistics -ComputerName DHCP01 -Failover
Get-DhcpServerv4ScopeStatistics -ComputerName DHCP02 -Failover

Compare free and in-use counts on both servers. In communication interrupted a server can run short of free addresses while the partner's share stays unused; that is the main reason to decide rather than wait.

4. Leases and declined addresses

# Read-only.
Get-DhcpServerv4Lease -ComputerName DHCP01 -ScopeId 192.0.2.0 -AllLeases |
    Group-Object AddressState | Select-Object Name, Count
Get-DhcpServerv4Lease -ComputerName DHCP01 -BadLeases
Get-DhcpServerv4Lease -ComputerName DHCP01 -IPAddress 192.0.2.57,192.0.2.58

• Without -AllLeases only active leases are returned; -AllLeases adds offered, declined and expired ones.
• -BadLeases returns addresses marked declined, which are not offered again until a 10-minute timer expires.

Under RFC 2131 a client that finds its offered address already in use sends a DHCPDECLINE, and the server records the address as declined. A rising count of bad leases is therefore an indicator to investigate, not proof that two devices are using one address now. Query the same suspect addresses on both partners and compare the client IDs and lease times. Two servers recording different clients for one address points at divergent databases; confirm a live collision with current evidence, such as the ARP or neighbour tables on the subnet's router or switch and which device answers at the address. A quiet bad-lease list does not by itself prove recovery is complete; keep the state and functional checks in Decision 2.

5. Clock and connection between the partners

# Read-only. Clock source and offset as Windows Time sees it.
w32tm /query /status /computer:DHCP01
w32tm /stripchart /computer:DHCP02 /samples:3 /dataonly

# Read-only. Can DHCP01 open the failover port on its partner?
Test-NetConnection -ComputerName DHCP02 -Port 647

# Read-only. The role's failover firewall rules and whether they are enabled.
Get-NetFirewallRule -CimSession DHCP01 -Name 'Microsoft-Windows-DHCP-Failover-TCP-*' |
    Select-Object Name, Enabled, Direction, Action

Run w32tm /stripchart from the other partner or a host whose time you trust. Test-NetConnection opens a real TCP connection; run it from the partner itself to prove the path between the servers. If rule names differ, filter on DisplayName -like '*DHCP*Failover*'.

6. Relay configuration

On each router or switch relaying DHCP for the affected subnets, use the vendor's read-only show commands to confirm the relay lists both servers. A relay pointing only at the failed server explains one subnet getting nothing. Watch also for duplicate relays from a VRRP or HSRP pair.

7. If a server was restored: when was its database taken?

Find the date of the backup, snapshot or replica the server was restored from, using your backup tool's records. Compare it with the last state change events from Check 2 on the surviving partner. Any restored copy can lack binding changes made after it was taken, however recent it is; treat it as stale and assess it against the survivor's current state in Decision 2.

Interpreting the results

Decision guidance

Make each change under change control, noting both servers' state (Check 1) before and after. If you are not sure the partner is down, fix the connection or confirm its status before changing state.

Decision 1: Declare the partner down

Do this only when you have confirmed the partner is not serving clients: its VM is off, its DHCP service is stopped, or it has no path to any client subnet. A failed TCP 647 test proves only that the two servers cannot reach each other.

# Changes state on DHCP01 only. Run on the SURVIVING server.
Set-DhcpServerv4Failover -ComputerName DHCP01 -Name 'DHCP01-DHCP02' -PartnerDown

-PartnerDown moves the server from COMMUNICATION INTERRUPTED to PARTNER DOWN. The survivor then waits one MCLT before it takes over the partner's available addresses. Plan for that wait (an hour by default); Microsoft does not describe changing the MCLT during an outage, so do not change it to shorten the wait. Keep the partner from returning to client networks by accident: leave its VM off or its adapter disconnected until Decision 2. Do not run -PartnerDown on both servers.

• Verification: Check 1 shows PARTNER DOWN on the survivor, and Check 2 has the Error-level state change event. After one MCLT, Check 3 shows the survivor using addresses from the whole pool, and new clients get addresses.
• Rollback: There is no command to return to COMMUNICATION INTERRUPTED. The way back is to restore contact with the partner, and the servers then reintegrate as described in Decision 2. If you declared partner down in error and the partner is in fact serving, restore the link between the partners immediately and start Decision 4 at once.

Decision 2: Bring a failed or restored partner back

The safe order is to let the partner that kept serving be the source of truth.

1. A server that failed and comes back with its own, current database (it was down, not restored): keep it away from client subnets until it is reconnected to its partner. On a VM, connect it first to a network where it can reach the partner on TCP 647 but not the client subnets. If your design cannot isolate it, keep it powered off or disconnected and plan the return under change control; do not connect it to clients and watch.
2. Let reintegration run. The returning server updates its bindings from the survivor. Microsoft's legacy description says a server in RECOVER updates its bindings database before serving clients and can rebuild it completely from the partner; RECOVER WAIT lasts one MCLT. The survivor stays in PARTNER DOWN until its peer reaches RECOVER DONE. Do not restart services or force states.
3. A server restored from a backup, snapshot or replica is a different case. Microsoft's current pages publish no procedure for returning a restored failover partner, and the expired protocol draft describes the design, not a Windows restore procedure. It notes that a restored copy's bindings, and its record of which updates the partner acknowledged, can both be out of date. Watching events cannot stop a stale database from answering clients. Keep the restored instance offline from client networks. Bring it back only through a recovery or rebuild plan that is supported for your Windows version, keeps it isolated until its state and leases are reconciled with the survivor, and has been rehearsed in a lab and reviewed by someone qualified. If you have no such plan, leave the instance off and keep the survivor serving.

This article does not give a remove-and-recreate procedure. Remove-DhcpServerv4Failover removes a relationship from both servers, but its page does not state what happens to the scopes and lease data on each side, so treat that route as unverified until a supported procedure for your version, the survivor's backups and the recovery steps are in place.

• Verification: Check 1 shows NORMAL on both servers, with each reporting the other as NORMAL. Check 2 shows the returning server's path (RECOVER, RECOVER WAIT, RECOVER DONE, or POTENTIAL CONFLICT and CONFLICT DONE) to NORMAL, the survivor moving from PARTNER DOWN to NORMAL, and no repeating CommDown events. Check 4 on both servers shows matching bindings for sampled addresses, and any declined address has been investigated. A test client on each affected subnet gets an address and the expected options.
• Rollback: If the returning server misbehaves, power it off or disconnect its adapter. The survivor goes back to communication interrupted, and you can repeat Decision 1. Do not restore a newer copy of its database over a running relationship.

Decision 3: Bring scope settings back in line

# Changes the PARTNER: copies scope settings from DHCP01 over DHCP02's settings.
# Run only from the server whose settings are correct. Prompts for confirmation; do not add -Force.
Invoke-DhcpServerv4FailoverReplication -ComputerName DHCP01 -ScopeId 192.0.2.0

The cmdlet replicates scope properties, reservations, options and policies for named scopes, a relationship or all failover scopes; leases are not part of it. Start from the server with the settings you want, and with mixed Windows versions from the newer one. First record the partner's current settings:

# Read-only. Compare the two before replicating.
Get-DhcpServerv4OptionValue  -ComputerName DHCP02 -ScopeId 192.0.2.0
Get-DhcpServerv4Reservation  -ComputerName DHCP02 -ScopeId 192.0.2.0

Replicate one scope, not all, unless every scope needs it.

• Verification: Option values and reservations match on both servers, clients of either server get the same options, and the Operational channel shows no unexpected changes.
• Rollback: There is no undo. Re-enter the recorded settings on the partner, or replicate again from a server that holds the right ones.

Decision 4: Catch duplicates during recovery

# Changes a server-wide setting: the server pings an address before offering it.
Set-DhcpServerSetting -ComputerName DHCP01 -ConflictDetectionAttempts 1

Values are 0 to 5; the default is 0 (off). RFC 2131 recommends probing a reused address, for example with ICMP echo, before allocating it. On both servers during recovery, addresses that answer are marked bad instead of offered. Each attempt waits for a reply before the offer (an editorial inference), so keep the count low. Devices that do not answer ping are not detected.

• Verification: Get-DhcpServerSetting shows the new value. Check 4 shows any addresses found in use as bad leases, which you then trace to the device holding them.
• Rollback: Set -ConflictDetectionAttempts 0 when bad leases have stopped appearing for at least the longest lease duration.

Decision 5: Automatic transition and MCLT for the long term

After the incident, decide whether the relationship's settings fit your network:

• Automatic state transition suits a design where the partners can lose contact only when one is down, such as two servers on one network with nothing between them that can fail separately. It is risky across sites where the link can fail while both serve local clients.
• The MCLT trades the survivor's wait after partner down against the length of temporary leases while apart (default 1 hour).

# Changes the relationship on both partners. Example: turn on automatic transition after 60 minutes.
Set-DhcpServerv4Failover -ComputerName DHCP01 -Name 'DHCP01-DHCP02' -AutoStateTransition $true -StateSwitchInterval 01:00:00

• Verification: Check 1 shows the new values on both servers, and the Operational channel has a ChangeFailoverConfig event.
• Rollback: Set -AutoStateTransition $false (or the previous MCLT) the same way.

What not to do

• Do not declare partner down on both servers, and do not turn on automatic transition where the partners can be split from each other while both reach clients.
• Do not connect a restored DHCP server VM to client networks without a supported, rehearsed recovery plan. Its lease database is as old as the backup.
• Do not run Invoke-DhcpServerv4FailoverReplication from the server you have not checked. It overwrites the partner's settings.
• Do not change scopes on only one server and leave them, in either mode.
• Do not force a server out of RECOVER WAIT or POTENTIAL CONFLICT by restarting services or removing the relationship mid-recovery. Those states are how the protocol avoids duplicates.
• Do not put a shared secret on a command line, in a script or in a ticket.
• Do not leave conflict detection on by accident; it delays every offer.

Limitations

• Restored copies: Microsoft's current pages do not describe how a server restored with an old database rejoins a relationship, so this article gives no restore or rebuild procedure; Decision 2 keeps such a copy offline.
• Legacy sources: Several state descriptions, the non-zero MCLT rule and the automatic-transition description come from the Windows Server 2012/2012 R2 settings page; current pages agree where they overlap.
• Exact property names: These can vary between DhcpServer module versions. Use Format-List * where a named property is missing.
• Clusters: Use the cluster name as the partner, never a node name, and replicate a shared secret to all nodes; cluster-specific recovery is not covered.
• Network equipment: Relay configuration is vendor specific; Check 6 says what to confirm, not how.
• No lab testing: None of the commands was run for this article.

Acceptance checklist

• [ ] Both partners report NORMAL for themselves and each other (Check 1).
• [ ] The Admin channel shows no repeating CommDown events or clock warnings since recovery (Check 2).
• [ ] Clocks agree well within one minute (Check 5).
• [ ] Scope statistics show free addresses available to new clients on both servers (Check 3).
• [ ] Every declined address and differing binding has been investigated against current network evidence (Check 4).
• [ ] Option values and reservations match on both servers (Decision 3).
• [ ] Every relay for the affected subnets lists both servers (Check 6).
• [ ] Conflict detection has been returned to its intended value (Decision 4).
• [ ] Automatic transition and MCLT have been reviewed and the decision is recorded (Decision 5).
• [ ] The change record shows each state change you made, when and on which server.

References

All accessed 2 November 2026.

• Microsoft Learn, "DHCP failover overview" (updated 27 March 2025; applies to Windows Server 2016–2025): two servers, DHCPv4, synchronised lease databases, Windows Server 2016 minimum, TCP 647 and firewall rules, relays for both servers and VRRP/HSRP duplicates, manual scope replication that overwrites the partner, hot standby reserve and MCLT behaviour, load balance default and hash, full pool only in partner down, clusters and shared secret, DNS credentials, one-minute time check. https://learn.microsoft.com/en-us/windows-server/networking/technologies/dhcp/dhcp-failover
• Microsoft Learn, "DHCP failover events and performance" (updated 25 April 2025): Admin and Operational channels, state change event fields and levels, event 20253, CommDown/CommUp, configuration audit events, performance counters. https://learn.microsoft.com/en-us/windows-server/networking/technologies/dhcp/dhcp-failover-events
• Microsoft Learn, "FSM_STATE enumeration (dhcpsapi.h)": failover states and conformance to draft-ietf-dhc-failover-12. https://learn.microsoft.com/en-us/windows/win32/api/dhcpsapi/ne-dhcpsapi-fsm_state
• Microsoft Learn (legacy, Windows Server 2012/2012 R2), "DHCP Failover Settings": MCLT meaning and non-zero rule, automatic state transition and interval, state descriptions including RECOVER, RECOVER WAIT, RECOVER DONE and POTENTIAL CONFLICT. https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn338985(v=ws.11)
• Microsoft Learn, "Add-DhcpServerv4Failover": defaults for AutoStateTransition, MaxClientLeadTime and ReservePercent; shared secret plain-text warning. https://learn.microsoft.com/en-us/powershell/module/dhcpserver/add-dhcpserverv4failover
• Microsoft Learn, "Set-DhcpServerv4Failover": PartnerDown, mode, MCLT, interval and shared secret parameters. https://learn.microsoft.com/en-us/powershell/module/dhcpserver/set-dhcpserverv4failover
• Microsoft Learn, "Get-DhcpServerv4Failover". https://learn.microsoft.com/en-us/powershell/module/dhcpserver/get-dhcpserverv4failover
• Microsoft Learn, "Remove-DhcpServerv4Failover": removes the relationship from both servers; effects on scopes and leases not stated. https://learn.microsoft.com/en-us/powershell/module/dhcpserver/remove-dhcpserverv4failover
• Microsoft Learn, "Invoke-DhcpServerv4FailoverReplication": what is replicated, and scope. https://learn.microsoft.com/en-us/powershell/module/dhcpserver/invoke-dhcpserverv4failoverreplication
• Microsoft Learn, "Get-DhcpServerv4Lease": AllLeases, BadLeases, 10-minute timer for declined addresses. https://learn.microsoft.com/en-us/powershell/module/dhcpserver/get-dhcpserverv4lease
• Microsoft Learn, "Get-DhcpServerv4ScopeStatistics": Failover switch. https://learn.microsoft.com/en-us/powershell/module/dhcpserver/get-dhcpserverv4scopestatistics
• Microsoft Learn, "Set-DhcpServerSetting": ConflictDetectionAttempts range and default. https://learn.microsoft.com/en-us/powershell/module/dhcpserver/set-dhcpserversetting
• IETF, RFC 2131, "Dynamic Host Configuration Protocol": server probe of reused addresses, client check and DHCPDECLINE. https://datatracker.ietf.org/doc/html/rfc2131
• IETF, draft-ietf-dhc-failover-12, "DHCP Failover Protocol" (expired draft): design goal of no duplicate allocation, operator informing the surviving server, potential-expiration times, survivor PARTNER-DOWN while the peer recovers; protocol design only, not a Windows procedure. https://datatracker.ietf.org/doc/html/draft-ietf-dhc-failover-12

Related articles

• Static IP Lost After a VM Restore or Virtual NIC Change

• DNS Changed but Users Still Reach the Old Application

• Duplicate IP or MAC Address After a VM Clone or Restore: Prove It, Contain It, Fix the Copy

• Clean Up Stale AD DNS Records: Scavenging Without Deleting Live Ones

Learning notes

1. In communication interrupted, each server serves within limits designed to prevent duplicates and does not take on the whole pool. New clients can run short of addresses, especially on a hot-standby server; read the failover statistics.
2. Automatic transition is off by default. -PartnerDown is the administrator's statement that the partner is not serving; make it on one server only, and only when that is true.
3. After partner down, the survivor waits one MCLT (1 hour by default) before taking over the partner's available addresses; existing leases stay protected by their own expiry.
4. A returning partner can reintegrate through RECOVER from the survivor, which stays in PARTNER DOWN until then. A restored copy stays offline without a supported plan. States that stop serving during recovery are safeguards, not faults.
5. Scope settings replicate only when you start replication, and replication overwrites the partner. During recovery, conflict detection plus a watch on bad leases catches the duplicates that remain.