September 11, 2026
13 min read
By Kokil Thapa | Last reviewed: September 2026
When your sole DHCP server dies, every new device on the LAN stops getting an IP address. Printers stall. Wi‑Fi clients drop. VoIP phones go silent. DHCP Failover on Windows Server solves that by pairing two DHCP servers that share scope state and lease data. If you already understand basic DHCP from our DHCP guide for system administrators, this article walks through planning, PowerShell setup, and production checks on Windows Server 2022 and later.
Quick answer: DHCP Failover on Windows Server pairs two DHCP servers to replicate scopes and leases. Configure it with
Add-DhcpServerv4Failover in load balance or hot standby mode so clients keep receiving addresses when one server is offline.What is DHCP Failover on Windows Server and how does it work?
Microsoft added native DHCP failover in Windows Server 2012. Two Windows DHCP servers share one logical scope. They exchange lease grants, renewals, and releases over TCP port 647. Clients do not need special configuration. They still broadcast or relay DHCPDISCOVER packets as usual.
Each server maintains a partner relationship object. That object stores the shared secret, mode, scope IDs, and state flags. When DHCP01 grants a lease, it replicates the binding to DHCP02. If DHCP01 fails, DHCP02 already holds the lease database and continues serving the subnet.
Failover is scope-level, not server-level. You can fail over one subnet while others stay on a single node. That flexibility helps branch offices and multi-VLAN campuses. It also means you must configure each scope you want protected.
Active Directory authorisation still applies. Both servers must be authorised in AD before production use. Unauthorised DHCP servers are ignored by domain members and can cause audit failures under frameworks like CIS server hardening benchmarks.
Requirements before you start
- Two Windows Server machines with the DHCP Server role (2012 R2 minimum; 2022 or 2025 recommended in 2026).
- Identical scope definitions on both servers—address range, mask, options, exclusions, reservations.
- Network reachability on TCP 647 between partners; allow it on internal firewalls.
- A strong shared secret (minimum 8 characters; use 20+ in production).
- Time sync via NTP; skew beyond a few minutes can delay replication.
- DNS integration planned—see our Windows DNS server configuration guide for forward and reverse zones.
Microsoft documents the full cmdlet reference on Add-DhcpServerv4Failover. Read that page before changing production scopes.
How do you configure DHCP Failover on Windows Server step by step?
Start on a fresh Windows Server build. Our Windows Server 2022 getting started article covers baseline patching and remote management. Install the DHCP role on both nodes first.
Step 1: Install and authorise DHCP on both servers
Run these commands in elevated PowerShell on DHCP01 and DHCP02. Replace hostnames and IPs with your values.
# On both DHCP01 and DHCP02
Install-WindowsFeature DHCP -IncludeManagementTools
# On each server — use that server's own FQDN and IP
Add-DhcpServerInDC -DnsName dhcp01.corp.example.com -IPAddress 192.168.1.10
Set-DhcpServerv4Binding -ComputerName localhost -BindingAddress 192.168.1.10
# From a management workstation with RSAT
Authorize-DhcpServerInActiveDirectory -DnsName dhcp01.corp.example.com -IPAddress 192.168.1.10
Authorize-DhcpServerInActiveDirectory -DnsName dhcp02.corp.example.com -IPAddress 192.168.1.11Confirm authorisation in the DHCP console under Action → Manage authorized servers. Both entries should show as authorised.
Step 2: Create identical scopes on both partners
Define the scope on DHCP01, then mirror it exactly on DHCP02. Mismatched option values cause subtle client bugs—wrong gateway, broken DNS suffix, or split default routes.
# On DHCP01
Add-DhcpServerv4Scope -Name "Office-LAN" -StartRange 192.168.10.50 `
-EndRange 192.168.10.250 -SubnetMask 255.255.255.0
Set-DhcpServerv4OptionValue -ScopeId 192.168.10.0 -Router 192.168.10.1
Set-DhcpServerv4OptionValue -ScopeId 192.168.10.0 -DnsServer 192.168.1.5,192.168.1.6
Set-DhcpServerv4OptionValue -ScopeId 192.168.10.0 -DnsDomain "corp.example.com"
# Export and import, or repeat the same commands on DHCP02For large environments, export scopes with Export-DhcpServer and import on the partner. That reduces manual copy errors. Validate with Get-DhcpServerv4Scope on both hosts.
Step 3: Create the failover relationship
Choose load balance for equal partners or hot standby when one server should stay idle until needed. The next section compares modes in detail.
# Load balance — 50/50 split (run on DHCP01)
$secret = Read-Host "Enter shared secret" -AsSecureString
$BSTR = [Runtime.InteropServices.Marshal]::SecureStringToBSTR($secret)
$plain = [Runtime.InteropServices.Marshal]::PtrToStringAuto($BSTR)
Add-DhcpServerv4Failover -Name "Office-LAN-Failover" `
-PartnerServer "dhcp02.corp.example.com" `
-ScopeId 192.168.10.0 `
-SharedSecret $plain `
-LoadBalancePercent 50 `
-MaxClientLeadTime 1:00:00 `
-AutoStateTransition $true `
-StateSwitchInterval 0:60:00MaxClientLeadTime (MCLT) defines how long a partner waits before granting leases if replication is stale. One hour is a common starting point. Lower it for fast failover; raise it if WAN links are slow.
Step 4: Verify replication and test failover
- Run
Get-DhcpServerv4Failoveron both servers and confirm state is Normal. - Grant a test lease from DHCP01; confirm it appears on DHCP02 with
Get-DhcpServerv4Lease -ScopeId 192.168.10.0. - Stop the DHCP service on DHCP01:
Stop-Service DHCPServer. - Release and renew a test client; it should receive an address from DHCP02.
- Restart DHCP01 and confirm state returns to Normal within the state switch interval.
Automate health checks with scheduled tasks or PowerShell automation for Windows servers. Export JSON status and feed it into your monitoring stack.
What is the difference between load balance and hot standby modes?
Mode choice drives traffic split and capacity planning. Pick wrong and you either waste hardware or overload the standby node during failover.
| Criteria | Load balance | Hot standby |
|---|---|---|
| Traffic split | Configurable ratio (e.g. 50/50 or 70/30) | Active server handles 100%; standby idle until failure |
| Hardware use | Both servers serve clients daily | Standby mostly waits; good for unequal hardware |
| Failover speed | Fast—standby already warm | Fast after auto state transition |
| Complexity | Hash-based allocation by MAC | Roles: active / standby with optional reserve pool |
| Best fit | Equal VMs in same site | DR site, ROBO, or older secondary box |
In load balance mode, DHCP hashes the client MAC address to decide which partner should answer. The ratio sets probability, not a live counter. Over time, distribution approximates your percentage.
Hot standby assigns explicit roles. The active partner serves all clients. The standby holds a reserved percentage of addresses—often 5–20%—for new leases during an outage. Without that reserve, the standby cannot grant fresh leases until it enters PARTNER DOWN state.
# Hot standby — DHCP02 is standby with 20% reserve
Add-DhcpServerv4Failover -Name "Office-LAN-HS" `
-PartnerServer "dhcp02.corp.example.com" `
-ScopeId 192.168.10.0 `
-SharedSecret "YourLongSecretString2026!" `
-Mode HotStandby `
-Role Standby `
-ReservePercent 20Run the matching command on the partner with -Role Active if you configure from the other side. Usually one Add-DhcpServerv4Failover call on either server creates the relationship on both.
For a Nepal office with a Kathmandu primary and a Pokhara DR VM, hot standby is often cheaper. Both boxes need not run at full daily load. A law firm or travel agency with flat LAN traffic may prefer 50/50 load balance on identical Hyper-V hosts.
How do you monitor and troubleshoot DHCP Failover on Windows Server?
Failover can sit in a degraded state for days if nobody checks. Clients still get IPs, but you have no redundancy. Treat partner state like disk health—alert on anything other than Normal.
Health checks worth automating
Get-DhcpServerv4Failover | Select Name, Mode, State, PartnerServer— state should be Normal.- Event IDs 20000–20099 in Applications and Services Logs → Microsoft → Windows → DHCP-Server.
- TCP 647 connectivity from each partner (
Test-NetConnection dhcp02.corp.example.com -Port 647). - Scope utilisation on both servers—large gaps suggest replication lag.
- DHCP audit logs if enabled for compliance trails.
Pipe failover status to JSON and validate structure with our JSON formatter tool during script development. Production alerts belong in Nagios monitoring for servers or your existing SIEM.
Common failures and fixes
Communication interrupted. Firewall rules often block TCP 647 after a security audit. Allow the port between partner IPs only. Verify with Test-NetConnection from both directions.
Shared secret mismatch. Removing and recreating the failover relationship is the cleanest fix. Use Remove-DhcpServerv4Failover -Name "Office-LAN-Failover", align secrets, then run Add-DhcpServerv4Failover again.
Scope mismatch. Different exclusion ranges or option values break replication. Export both scopes and diff them. Fix DHCP02 to match DHCP01 exactly.
Stale leases after extended outage. Run manual replication:
Invoke-DhcpServerv4FailoverReplication -Force -ComputerName dhcp01.corp.example.com
Invoke-DhcpServerv4FailoverReplication -Force -ComputerName dhcp02.corp.example.comSplit brain after network partition. Both servers may enter PARTNER DOWN and grant overlapping leases. Resolve the network issue first. Then reconcile leases and restart the DHCP service on the partner that should be secondary.
Microsoft's overview at DHCP failover on Windows Server lists state transitions and timing defaults. Keep that page bookmarked for incident response.
What are the best practices for DHCP Failover on Windows Server in production?
Failover protects availability. It does not replace backups, DNS design, or security baselines. Treat it as one layer in a wider network plan—similar to how securing websites and servers in Nepal spans firewalls, patching, and monitoring together.
Design and security
- Place both DHCP servers on separate hypervisors or physical hosts. One host failure should not kill both VMs.
- Use dedicated management VLANs. Restrict who can RDP or WinRM to DHCP boxes.
- Store the shared secret in your vault—generate with a password generator, not a sticky note.
- Keep scopes below 80% utilisation. Failover reserve pools shrink usable space in hot standby mode.
- Document option 15, 6, 3, and custom options per VLAN. Drift causes helpdesk tickets that look like "Wi‑Fi is broken."
- Pair failover with split DNS or at least two domain controllers. DHCP without DNS is half a solution.
On mixed estates, Linux DNS on BIND and Windows DHCP coexist fine. Our BIND DNS server on Linux guide helps when your DNS tier is not on Windows.
Operations and change control
Schedule scope changes during maintenance windows. Adding exclusions on one partner only triggers replication errors. Change both, or remove failover temporarily, edit, then recreate.
Before decommissioning a partner, migrate roles:
# Move active role to remaining server before rebuild
Set-DhcpServerv4Failover -Name "Office-LAN-Failover" -PartnerServer "dhcp02.corp.example.com" -Mode HotStandby -Role ActiveExport DHCP configuration monthly:
Export-DhcpServer -File "C:\Backup\dhcp-config-$(Get-Date -Format yyyyMMdd).xml" -Leases -ForceStore exports off-server alongside your automated server backup setup. XML exports rebuild scopes faster than hand entry after ransomware or bare-metal recovery.
Teams that run web stacks on Linux still depend on Windows DHCP in many AD-dominated offices. The same discipline applies—document IPAM, tie DHCP to CMDB records, and review reservations quarterly. Unused reservations starve pools silently.
If you outsource infrastructure, confirm failover is in scope. Many Linux system administration contracts cover web servers only. DHCP pairs belong in support and maintenance or enterprise application runbooks when Active Directory is involved.
For office networks that also serve public web apps, split responsibilities clearly. Internal DHCP pairs stay on domain controllers or dedicated DHCP VMs. Public sites live on domain registration and hosting platforms or Linux web tiers documented in our Ubuntu server setup for PHP apps guide.
I've seen production deployments at SMB sites where a single Hyper-V host ran both DHCP VMs. Failover looked healthy until the host motherboard failed—then the entire subnet went dark. Separate hosts cost little compared to downtime.
Performance tuning matters on busy WLANs. Each DHCP transaction is small, but peak Monday morning association storms add up. Keep partner links on low-latency LAN segments. Avoid routing failover traffic over a congested WAN unless hot standby at a DR site is the explicit goal.
Finally, test failover twice a year. Add it to the same calendar as restore drills from database backup strategies for small servers. A relationship stuck in Communication Interrupted gives false comfort—redundancy exists on paper only.
Key Takeaways
- DHCP Failover on Windows Server needs identical scopes, AD authorisation, and TCP 647 open between partners.
- Use load balance for equal peers; use hot standby with a reserve pool for DR or uneven hardware.
- Create relationships with
Add-DhcpServerv4Failover, then verify lease sync before declaring production ready. - Alert on partner state changes—Normal is the only healthy state during steady operation.
- Export DHCP XML regularly; failover protects uptime but does not replace configuration backups.
- Never place both failover VMs on the same physical host or hypervisor cluster node without anti-affinity rules.
People Also Ask
Does DHCP Failover on Windows Server require Active Directory?
Both DHCP servers must be authorised in Active Directory Domain Services for production domains. Workgroup lab setups can skip AD authorisation, but clients in a domain ignore unauthorised servers. Failover itself does not require AD replication—only DHCP authorisation does.
Can you run DHCP Failover across different subnets or sites?
Yes, partners can live in different sites connected by VPN or MPLS. Keep TCP 647 latency low and increase MCLT if replication is slow. Many admins prefer hot standby for cross-site pairs so the WAN link is not hit with constant lease chatter.
How many failover relationships can one Windows DHCP server join?
A server can participate in multiple relationships—typically one per scope or scope group. There is no hard small-business limit, but monitor CPU and disk on busy hosts. Consolidate scopes thoughtfully and watch the DHCP audit log size.
What happens to existing leases when you enable failover?
Existing leases on the primary replicate to the partner after the relationship is created. Run initial replication and confirm with Get-DhcpServerv4Lease on both sides. Clients with valid leases keep them until renewal; they do not need a forced release.
Deploy DHCP Failover with confidence
DHCP Failover on Windows Server is the standard way to keep IP assignment running through a single-server outage. Install and authorise two DHCP nodes, mirror scopes, pick load balance or hot standby, then prove failover by stopping one service and renewing a test client. Monitor partner state, back up XML exports, and keep TCP 647 open between peers.
Need help designing site networks, hybrid Linux/Windows infrastructure, or ongoing server care? Review our infrastructure project work or contact us to plan DHCP, DNS, and monitoring together.
Frequently Asked Questions
It pairs two Windows DHCP servers to replicate scopes and leases over TCP 647, so clients keep getting IP addresses if one server goes offline.
Windows Server 2012 R2 minimum; Microsoft added native failover in Windows Server 2012. For 2026 deployments, Windows Server 2022 or 2025 is recommended.
TCP port 647. Both DHCP partners must reach each other on that port; internal firewalls often block it after security audits, breaking replication.
Install and authorize the DHCP Server role on both nodes in Active Directory using Install-WindowsFeature and Authorize-DhcpServerInActiveDirectory. Create identical scopes on each partner with matching ranges, options, exclusions, and reservations. On one server, run Add-DhcpServerv4Failover with the partner FQDN, scope ID, shared secret, and chosen mode. Verify with Get-DhcpServerv4Failover that state shows Normal, grant a test lease on one partner, confirm it appears on the other with Get-DhcpServerv4Lease, then stop the DHCP service on the primary and renew a client to prove failover works.
Load balance splits client traffic by hashing MAC addresses against a configurable ratio such as 50/50 or 70/30, so both servers serve leases daily. Hot standby assigns active and standby roles; the active node handles all clients while the standby waits idle until failure. Hot standby needs a reserve pool, often 5 to 20 percent of addresses, so the standby can grant fresh leases during an outage before entering PARTNER DOWN state. Pick load balance for equal peers in the same site; pick hot standby for DR sites or unequal hardware.
No. Clients continue broadcasting or relaying DHCPDISCOVER packets as usual and do not know which partner answered. The failover relationship exists entirely between the two Windows DHCP servers, which replicate lease grants, renewals, and releases over TCP 647. Your client-side concern remains standard DHCP relay configuration on routers if the servers sit on a different subnet. No firmware changes, reservations, or option tweaks are required on workstations, printers, or VoIP phones for failover to function.
Active Directory authorization is a security control. Unauthorized DHCP servers are ignored by domain members and can trigger audit failures under hardening frameworks like CIS server benchmarks. Before creating a failover relationship, authorize each server with Authorize-DhcpServerInActiveDirectory and confirm both entries appear under Manage authorized servers in the DHCP console. Skipping authorization leaves scopes visible in the console but produces unreliable production behavior and undermines your domain security posture.
The surviving partner already holds replicated lease bindings and continues serving the subnet. In load balance mode, the remaining server picks up traffic immediately because it was already warm and serving clients. In hot standby, the active server handles everything until failure; then the standby uses its reserve pool and auto state transition to enter service. MaxClientLeadTime controls how long a partner waits before granting leases if replication is stale. One hour is a common starting value; lower it for faster failover on low-latency LANs.
MaxClientLeadTime, or MCLT, defines how long a failover partner waits before granting new leases when replication appears stale. The article's load balance example uses one hour, which is a common production starting point. Lower MCLT speeds failover after partner loss but increases duplicate-grant risk on slow WAN links. Raise it if partners connect across high-latency circuits. Tune MCLT alongside StateSwitchInterval, which the example sets to sixty minutes for automatic state transitions when a partner stops responding.
First check TCP 647 connectivity in both directions with Test-NetConnection against the partner FQDN. Firewall rule changes after security audits are the most common cause. If the shared secret drifted, remove the relationship with Remove-DhcpServerv4Failover, align secrets on both sides, and recreate it with Add-DhcpServerv4Failover. For scope mismatch, export both scopes and diff exclusion ranges and option values. DHCP02 must mirror DHCP01 exactly. Run Invoke-DhcpServerv4FailoverReplication -Force on both partners after fixing the root cause.
Split brain occurs after a network partition when both partners enter PARTNER DOWN and may grant overlapping leases to different clients. Fix the underlying network connectivity first; do not restart services blindly while the partition persists. Once partners can communicate again, reconcile duplicate leases, identify which server should remain secondary, and restart the DHCP service on that node. Run Invoke-DhcpServerv4FailoverReplication -Force on both servers after the network is stable to resynchronize binding databases before returning to Normal state.
Hot standby suits DR sites, branch offices, and unequal hardware because the standby server stays mostly idle until needed, saving daily capacity on the secondary box. Configure ReservePercent at 5 to 20 so the standby can issue new leases during an outage. Load balance fits equal VMs in the same site where both nodes should share traffic via MAC hash allocation. For a Kathmandu primary with a Pokhara DR VM, hot standby is often the cheaper practical choice because both boxes need not run at full daily load.
Place both DHCP VMs on separate hypervisors or physical hosts so one hardware failure cannot kill both partners. Keep scope utilization below 80 percent, especially in hot standby where reserve pools shrink usable space. Store the shared secret in a vault and use twenty or more characters, not the eight-character minimum. Export DHCP configuration monthly with Export-DhcpServer including leases, store exports off-server, and test failover twice a year alongside restore drills. Alert whenever partner state is anything other than Normal.
Automate checks with Get-DhcpServerv4Failover and alert when State is not Normal. Review Event IDs 20000 through 20099 under Applications and Services Logs, Microsoft, Windows, DHCP-Server. Test TCP 647 reachability regularly with Test-NetConnection and compare scope utilization on both partners; large gaps suggest replication lag. Export failover status as JSON for Nagios or your SIEM. A relationship stuck in Communication Interrupted still serves clients but offers no real redundancy, so treat partner state like disk health.
Yes. Failover is scope-level, not server-level. You can protect one subnet while leaving others on a single node, which helps branch offices and multi-VLAN campuses. Each protected scope needs an identical definition on both partners and its own failover relationship created with Add-DhcpServerv4Failover. Scopes without failover continue relying on a single server, so document which VLANs are covered during IPAM reviews. Mismatched option values on one scope alone can cause subtle client bugs such as wrong gateways or broken DNS suffixes.
0 Comments
Leave a comment
Your email is not published. Comments appear once they have been read. Sign in to have your details filled in.
