Windows Server DHCP Troubleshooting (2026): Failover, Scope Exhaustion, APIPA & PowerShell Fixes

Updated: July 26, 2026

DHCP server troubleshooting on Windows Server 2025 comes down to five checks in this order: is the DHCP Server service running and authorized in Active Directory, is the scope active with free addresses, is failover in a NORMAL state on both partners, is the relay agent (IP helper) forwarding cross-subnet DISCOVERs, and (since the June 2025 patch cycle) is KB5060842 or its rollup successor causing the service to hang 20 to 50 seconds after boot. This guide walks each check with PowerShell you can paste into a helpdesk runbook, plus fixes for scope exhaustion, database corruption, rogue servers, and APIPA fallback on clients.

• Clients falling back to 169.254.x.x (APIPA) always mean DISCOVER/OFFER isn't completing. Start with Get-Service DHCPServer and Event Viewer's Microsoft-Windows-DHCP Server Events/Operational log before touching the client.
• Windows Server 2025/2022/2019/2016 all hit the June 2025 KB5060842 DHCP-service hang; the durable fix ships in cumulative updates from July 2025 onward, but a scheduled restart is the immediate workaround.
• Prefer DHCP failover (Load Balance mode) over the older split-scope design. It shares full lease state and doesn't burn 20% of your address pool on a standby you rarely use.
• Scope exhaustion is usually stale leases and rogue reservations, not real device growth. Reconcile scopes, drop lease duration to 1 or 2 days on high-churn subnets, and monitor the Get-DhcpServerv4Statistics percent-in-use counter.
• DHCP database corruption throws Event ID 1014/1046; recover with jetpack.exe dhcp.mdb tmp.mdb against a stopped service before restoring from backup.
• Rogue DHCP servers on a broadcast domain are the silent killer. Use dhcploc.exe or a scheduled Wireshark capture on port 67/68 to catch them.

How DHCP actually works: the DORA handshake

Honestly, every DHCP troubleshooting call I take on the helpdesk gets easier the moment the tier-1 tech understands the four packets that make up a lease. If you already know DORA cold, feel free to skim, but I've watched senior admins waste a full hour on a "DHCP outage" that turned out to be a client-side firewall dropping port 68. So it's worth setting the baseline.

DORA stands for Discover, Offer, Request, Acknowledge. When a Windows client's DHCP Client service (dhcp.exe) needs a lease, it broadcasts a DHCPDISCOVER to 255.255.255.255 on UDP/67. Any DHCP server that hears the broadcast, directly or via a relay agent, replies with a DHCPOFFER containing a candidate IP, subnet mask, gateway, DNS, and lease time. The client typically picks the first offer, broadcasts a DHCPREQUEST naming that server, and the winning server sends a DHCPACK to lock the lease. The Windows DHCP client then plumbs the address, writes it to ipconfig /all output, and (if configured) asks the DNS server to register an A record.

Here's why DORA matters for troubleshooting: every failure mode maps to one packet. No DISCOVER leaving the client means client-side firewall, disabled DHCP Client service, or wrong VLAN. DISCOVER but no OFFER points to server down, unauthorized, scope inactive, no relay for a remote subnet, or scope exhausted. OFFER but no ACK usually means another server hijacked the REQUEST (rogue), or the client rejected the offer via a decline because the address was already in use. ACK but client still shows 169.254.x.x means the client-side Winsock stack rejected the plumb (driver, IPv6 duplicate address detection failure, or a DHCPv4 conflict detected via ARP probe). Knowing which packet died tells you where to look.

Why is my DHCP server not issuing IP addresses?

The most common reason a Windows DHCP server stops issuing leases is that it isn't authorized in Active Directory, its scope is deactivated, or the pool is exhausted. Run this triage from an elevated PowerShell prompt on the DHCP server. It takes about ten seconds and rules out 80% of causes.

# Tier-1 DHCP triage. Runs against localhost.

# 1) Is the service even running?
Get-Service DHCPServer | Select-Object Status, StartType

# 2) Is this server authorized in AD? (unauthorized = silently stops leasing)
Get-DhcpServerInDC

# 3) Are the IPv4 scopes active and how much of the pool is used?
Get-DhcpServerv4Scope | Select-Object ScopeId, Name, State, LeaseDuration
Get-DhcpServerv4ScopeStatistics | Sort-Object PercentageInUse -Descending |
    Format-Table ScopeId, Free, InUse, Reserved, PercentageInUse

# 4) Any recent operational errors? Last 20 events.
Get-WinEvent -LogName 'Microsoft-Windows-DHCP Server Events/Operational' -MaxEvents 20 |
    Select-Object TimeCreated, Id, LevelDisplayName, Message

If Get-DhcpServerInDC doesn't list your server, that alone stops it from serving leases in a Windows domain. The service starts but refuses to hand out addresses. Fix it with Add-DhcpServerInDC -DnsName dhcp01.contoso.local -IPAddress 10.0.0.10 from an account with Enterprise Admin rights, then run Restart-Service DHCPServer. If the scope shows State: Inactive, activate it with Set-DhcpServerv4Scope -ScopeId 10.10.0.0 -State Active. And if PercentageInUse is at 100, jump straight to the scope exhaustion section before doing anything else. Nothing else will help.

The Operational event log is gold. Event ID 1046 means AD authorization failure, 1014 means database corruption, 1041 means the server can't bind to any interface (usually a static IP change nobody told DHCP about), and 10052 is the failover partner unreachable. If you see 1041, run Get-DhcpServerv4Binding and confirm at least one binding has BindingState: True; if not, run Set-DhcpServerv4Binding -InterfaceAlias 'Ethernet0' -BindingState $true.

Fixing APIPA fallback (169.254.x.x) on Windows clients

APIPA, or Automatic Private IP Addressing, is Windows falling back to a self-assigned 169.254.0.1 to 169.254.255.254 address when it can't reach a DHCP server. Any time ipconfig shows a 169.254 address, the DORA handshake didn't complete: either DISCOVER never left the client, no server answered, or the client refused the offer. That's your diagnostic tree.

On the client, run this from an elevated PowerShell to gather the state a tier-2 escalation actually wants:

# Client-side APIPA diagnostics. Save output before escalating.

# Current adapter state and any APIPA fallback.
Get-NetIPAddress -AddressFamily IPv4 |
    Where-Object InterfaceAlias -notlike '*Loopback*' |
    Format-Table InterfaceAlias, IPAddress, PrefixOrigin, SuffixOrigin

# Is the DHCP Client service alive?
Get-Service Dhcp | Select-Object Name, Status, StartType

# Force a lease renewal on all adapters and capture the outcome.
ipconfig /release
ipconfig /renew

# DHCP client operational log: server offers, declines, and conflicts.
Get-WinEvent -LogName 'Microsoft-Windows-Dhcp-Client/Operational' -MaxEvents 30 |
    Format-Table TimeCreated, Id, Message -Wrap

Three failure signatures to recognise. PrefixOrigin: WellKnown with SuffixOrigin: Link means pure APIPA fallback (no server response). Event ID 1003 in the Dhcp-Client log ("Your computer was not assigned an address from the network") confirms DISCOVER got no answer within the timeout. Event ID 50036 means the client declined the offer, usually because an ARP probe detected the offered IP is already in use. That's a server-side stale-lease problem, not a client one.

If the DHCP Client service itself is stopped or set to Manual, that's your fix: Set-Service Dhcp -StartupType Automatic; Start-Service Dhcp. If the service is running and you still get APIPA, check the Windows Defender Firewall on the client for a rule blocking outbound UDP 68 (a common casualty of over-aggressive endpoint hardening baselines). Rare but real: a broken NIC driver will silently drop the OFFER; a driver reinstall via pnputil resolves it. Our full network diagnostics toolkit covers the Wireshark/pktmon captures if you need to prove where the packet dies.

The June 2025 patch Tuesday DHCP bug (KB5060842)

Microsoft acknowledged in the Windows release health dashboard that the June 2025 cumulative updates (KB5060842 for Windows Server 2025, KB5060526 for Server 2022, KB5060531 for Server 2019, and KB5061010 for Server 2016) caused the DHCP Server service to stop responding roughly 20 to 50 seconds after boot. It's the single most common DHCP outage I've triaged on the desk this year, and if you rolled that patch to production DHCP servers, this is almost certainly your issue. I hit it myself shipping a routine security patch to a two-server failover pair; both partners hung within an hour of the reboot window.

Symptoms: DHCPServer service starts, then hangs. Get-Service DHCPServer shows Running, but Get-DhcpServerv4Statistics throws an RPC timeout, the MMC console times out expanding scopes, and clients start dropping to APIPA within 8 minutes (default renewal window on a 4-day lease). Event Viewer under System logs a Service Control Manager warning that DHCPServer didn't respond to control requests.

Don't roll back the update on a production DHCP server unless you've verified the failover partner is healthy and can carry the load. Pulling the CU forces a reboot, and during that reboot your partner has to serve 100% of leases. If you're running a single non-failover DHCP server (which, honestly, you shouldn't be), the reboot risk is your business decision, but plan the change during a low-utilization window. Verify the build version afterward with Get-ComputerInfo | Select-Object OsBuildNumber, WindowsProductName.

DHCP failover troubleshooting: Load Balance vs Hot Standby

Windows DHCP failover is the modern replacement for split scope, introduced in Server 2012 and unchanged in behaviour through Server 2025. Two servers share the entire scope and replicate lease state, so a client renewing at the "wrong" partner still gets its original address. There are two modes: Load Balance (default, 50/50, both partners answer new DISCOVERs) and Hot Standby (partner answers only when the primary fails). I recommend Load Balance for about 95% of deployments. It's less work to reason about, and both servers stay warm.

The failover state machine matters. A healthy relationship is NORMAL on both partners. If you see COMMUNICATIONS-INTERRUPTED, it means the servers can't reach each other but each still assumes the other is up (both serve their own share). PARTNER-DOWN means the surviving partner has taken over the full pool. RECOVER and RECOVER-WAIT are transitional. Check state on both partners:

# Run on BOTH failover partners. States can differ during a fault.
Get-DhcpServerv4Failover | Format-Table Name, PartnerServer, Mode, State, `
    LoadBalancePercent, MaxClientLeadTime, StateSwitchInterval

# List every scope in a given relationship.
Get-DhcpServerv4Failover -Name 'DHCP-Failover-01' |
    Select-Object -ExpandProperty ScopeId

The classic error I see on the desk is Event ID 20013 when right-clicking a scope and choosing "Replicate Scope": "Failed to update reservations in scope on partner server, error code 20013". Nine times out of ten, this is a schema drift after one partner was restored from backup while the other kept accepting leases. The workaround Microsoft's own docs suggest: deconfigure the failover relationship with Remove-DhcpServerv4Failover -Name 'DHCP-Failover-01' -Force, then recreate it with Add-DhcpServerv4Failover -Name 'DHCP-Failover-01' -PartnerServer dhcp02 -ScopeId 10.10.0.0 -SharedSecret 'YourSharedSecret'. You lose no lease data; the source-of-truth is the primary. See the official Understand and Deploy DHCP Failover reference for the underlying protocol behaviour.

If a partner is genuinely down and you need to reclaim the full address pool, transition the survivor to PARTNER-DOWN manually with Invoke-DhcpServerv4FailoverStateTransition -ComputerName dhcp01 -Name 'DHCP-Failover-01' -State PartnerDown. Don't do this reflexively. The Maximum Client Lead Time (MCLT, default 1 hour) exists specifically so you can survive a partner outage without touching state, and forcing PARTNER-DOWN then bringing the peer back requires a controlled sync.

What causes DHCP scope exhaustion and how do I fix it?

Scope exhaustion is when 100% of your usable address range is leased, so new clients get no offer and fall to APIPA. In my experience, real exhaustion (genuine device growth beyond the /24) is rare. What's actually common: stale leases from mobile devices that never released, rogue reservations from a departed admin's cleanup script, and (increasingly in 2026) MDM-enrolled devices that rotate MAC addresses every roaming event, so a single laptop consumes six leases across a workday.

Run this to find the actual state:

# All scopes over 80% utilization. Worth investigating first.
Get-DhcpServerv4ScopeStatistics |
    Where-Object PercentageInUse -gt 80 |
    Sort-Object PercentageInUse -Descending

# For a hot scope, look at leases that haven't renewed recently.
$scopeId = '10.10.0.0'
Get-DhcpServerv4Lease -ScopeId $scopeId |
    Where-Object AddressState -eq 'Active' |
    Sort-Object LeaseExpiryTime |
    Select-Object IPAddress, HostName, ClientId, LeaseExpiryTime -First 30

# Reconcile the scope against the DHCP database.
Repair-DhcpServerv4IPRecord -ScopeId $scopeId

Three fixes, in order of preference. First, drop lease duration on high-churn scopes (guest Wi-Fi, BYOD) to 24 hours, or even 4 hours: Set-DhcpServerv4Scope -ScopeId 10.10.0.0 -LeaseDuration 1.00:00:00. Windows renewals happen at 50% and 87.5% of lease time, so short leases reclaim addresses fast without hammering the server. Second, run Repair-DhcpServerv4IPRecord; it reconciles the in-memory lease list against the Jet database and drops phantom entries. Third, if you're still at 100%, extend the scope (add addresses via Add-DhcpServerv4ExclusionRange/Set-DhcpServerv4Scope -EndRange) or superscope another subnet.

For BYOD or mobile-heavy environments with MAC randomization, consider disabling Wi-Fi private addressing at the SSID level via Intune or your MDM policy. Otherwise you're renting IPs to phantoms. Note that Universal Print devices, Teams Rooms panels, and older printers all struggle with short leases; put them in a separate scope with a 30-day lease.

Recovering a corrupted DHCP database

Windows DHCP stores lease data in a Jet database at %windir%\System32\dhcp\dhcp.mdb. It's the same engine as Active Directory's NTDS.dit: reliable, but it can bloat or corrupt after unclean shutdowns, disk-full events, or antivirus locking files. Signs of trouble: Event ID 1014 (database error), the DHCP MMC console showing empty scopes despite Get-DhcpServerv4Scope returning them, or the DHCP service failing to start with error 1053.

Recovery steps. Do these in order, and take a copy of the entire dhcp folder first:

# Stop the service (required; Jet locks the .mdb while running).
Stop-Service DHCPServer

# Back up the current database folder to a timestamped copy.
Copy-Item -Path "$env:windir\System32\dhcp" `
          -Destination "$env:windir\System32\dhcp.bak.$(Get-Date -Format 'yyyyMMddHHmm')" `
          -Recurse

# Compact and repair the Jet database. jetpack ships with the DHCP role.
Set-Location "$env:windir\System32\dhcp"
jetpack.exe dhcp.mdb tmp.mdb

# Restart the service and verify.
Start-Service DHCPServer
Get-DhcpServerv4Scope

If jetpack fails, your next option is a restore. Windows DHCP takes an automatic backup every 60 minutes to %windir%\System32\dhcp\backup. Restore it via the MMC (right-click server, All Tasks, Restore) or programmatically with Restore-DhcpServer -File "$env:windir\System32\dhcp\backup". Failover partners help here: a corruption event on one server is trivially recovered by removing the relationship, reinstalling the DHCP role on the affected box, and re-adding the failover. The healthy partner's state becomes the source of truth on replication.

How do I find a rogue DHCP server on my network?

A rogue DHCP server is any DHCP server on the broadcast domain that shouldn't be there. Usually it's someone's home router plugged into the office LAN, an ESXi host with unmanaged DHCP, or a lingering Windows machine with the DHCP Server role installed for testing. Symptoms are chaotic: some clients get 10.x.x.x from your real server, others get 192.168.1.x from a Linksys under a desk. AD authorization only protects Windows DHCP servers; a rogue non-Windows server will happily answer DISCOVERs.

The classic detection tool is Microsoft's dhcploc.exe from the Windows Server Support Tools (still works on Server 2025 if you copy it over from a 2012 R2 install). Modern approach: use a scheduled packet capture with pktmon filtering to UDP 67/68:

# Capture DHCP traffic for 60 seconds and dump to file.
pktmon filter add DHCP -p 67 68
pktmon start --etw -f C:\Temp\dhcp-capture.etl
Start-Sleep -Seconds 60
pktmon stop
pktmon etl2txt C:\Temp\dhcp-capture.etl -o C:\Temp\dhcp-capture.txt

# The 'Source IP' on any OFFER packet is a DHCP server on your segment.
# Any address that isn't your sanctioned DHCP server IP is your rogue.
Select-String -Path C:\Temp\dhcp-capture.txt -Pattern 'OFFER'

A cleaner enterprise fix: enable DHCP Snooping on your access switches. It designates uplink ports as "trusted" and drops DHCPOFFER/ACK packets from any other port, killing rogues at the wire. Cisco, Aruba, Juniper, and Meraki all support it; the syntax varies but the concept is identical. If you can't do snooping, at minimum set 802.1X on access ports so unknown devices can't get on the LAN in the first place. See our enterprise Wi-Fi troubleshooting guide for the 802.1X side of that story. The DHCP protocol RFC 2131 also documents the OFFER/ACK message flow if you want to sanity-check a capture against the spec.

DHCP relay agents and cross-subnet DISCOVER failures

DHCP works on broadcast, and broadcasts don't cross routers. Any client not on the same subnet as the DHCP server needs a relay agent (a.k.a. IP helper), typically the router's SVI for that subnet, configured with an ip helper-address statement pointing at your DHCP server. When cross-subnet clients get APIPA but on-subnet clients lease fine, the helper is your first suspect.

Verification from the DHCP server side: enable DHCP audit logging (it's on by default, at %windir%\System32\dhcp\DhcpSrvLog-*.log) and grep for the client's MAC. If the MAC doesn't appear at all, the DISCOVER never arrived, so the relay isn't forwarding. If it appears with a NAK, the server rejected it, usually because the giaddr field in the relayed packet doesn't match any scope's subnet.

# Grep today's DHCP audit log for a specific client MAC.
$mac = 'AA-BB-CC-11-22-33'
$today = (Get-Date).DayOfWeek.ToString().Substring(0,3)
Select-String -Path "$env:windir\System32\dhcp\DhcpSrvLog-$today.log" -Pattern $mac

# Server-side: list all IP addresses receiving relayed DISCOVERs.
# Look for entries with a source IP != your gateway on the DHCP subnet.
Select-String -Path "$env:windir\System32\dhcp\DhcpSrvLog-$today.log" -Pattern '^10' |
    Select-Object -First 20

Common relay pitfalls: firewall rules between the router and DHCP server dropping UDP 67, the router's helper pointing at a stale server IP after a DHCP migration, and Layer 3 devices in the path with ip forward-protocol disabled. If you use Windows RRAS as a relay agent (rare in enterprise, common in labs), remember it needs the DHCP Relay Agent routing protocol added under IPv4 and at least one internal interface bound.

Active Directory authorization and DNS credentials

Two AD-adjacent DHCP issues cause a surprising volume of tickets. First: Windows DHCP servers must be authorized in AD before they hand out leases. If a server was authorized under a hostname that later changed, or was authorized in a different forest, it will silently refuse to serve. Check with Get-DhcpServerInDC. Authorize with Add-DhcpServerInDC from an Enterprise Admin. If you're doing a forest recovery scenario, the authorization is stored in the Configuration partition; a bare-metal recovery of your DCs restores it.

Second: DHCP dynamic DNS updates. When a client leases an IP, DHCP can register the A record on the client's behalf into AD-integrated DNS. This needs credentials, and if you don't configure them explicitly, DHCP uses the computer account, which triggers a well-documented DnsUpdateProxy permissions problem. Records get created but nobody can update them later, and you end up with stale A records blocking new leases. This intersects tightly with the issues covered in our DNS troubleshooting guide. Set dedicated credentials once and forget it:

# Create a dedicated service account first (do this ONCE in AD, not here).
# The account needs no group memberships, just a strong password.

# Point DHCP at that account for DNS registration.
Set-DhcpServerDnsCredential -Credential (Get-Credential contoso\svc-dhcp-dns) `
    -ComputerName dhcp01.contoso.local

# Confirm it stuck.
Get-DhcpServerDnsCredential -ComputerName dhcp01.contoso.local

# Then add the account to the DnsUpdateProxy group. Members of this group
# don't own the records they create, so records can be updated by anyone.
Add-ADGroupMember -Identity 'DnsUpdateProxy' -Members 'svc-dhcp-dns'

One caveat that catches people out: never make a DC also the DHCP server AND put its computer account in DnsUpdateProxy. If you do, records created by other services on that DC also become "unowned" and can be hijacked by any authenticated user. Keep DHCP off DCs, or use dedicated credentials without DnsUpdateProxy and accept that stale records are your reconciliation problem instead.

Frequently Asked Questions

What is the difference between DHCP split scope and DHCP failover?

Split scope divides a single scope's addresses between two independent DHCP servers (typically 80/20), each unaware of the other's leases. DHCP failover, introduced in Windows Server 2012, has both servers share the full scope with replicated lease state, so a client renewal at either partner returns the same IP. Failover is strictly better for redundancy and address utilization; use it unless you're constrained to a legacy design.

How do I fix DHCP failover replication error 20013?

Error 20013 during a Replicate Scope operation almost always indicates schema or reservation drift between failover partners after a restore or manual edit. The reliable fix is to deconfigure the failover relationship with Remove-DhcpServerv4Failover -Force, verify the primary is the source of truth, and recreate it with Add-DhcpServerv4Failover. No lease data is lost because the primary keeps its full state.

Why do my clients keep getting a 169.254 address after the June 2025 update?

The June 2025 cumulative updates (KB5060842 for Server 2025, KB5060526 for 2022, KB5060531 for 2019, KB5061010 for 2016) caused the DHCP Server service to hang 20 to 50 seconds after boot. The DHCP Server service shows as Running but silently stops answering DISCOVERs, so clients fall back to APIPA. Install the July 2025 or later cumulative rollup; as a stopgap, schedule a 6-hourly service restart.

How do I find out which DHCP server is issuing a lease to a client?

On the client, run ipconfig /all and check the "DHCP Server" line; it's the IP of the server that ACKed the current lease. For deeper diagnostics use Get-NetIPConfiguration in PowerShell, or scan the audit log at %windir%\System32\dhcp\DhcpSrvLog-<Day>.log on the server for the client's MAC address. If two IPs appear in ipconfig across renewals, you probably have a rogue DHCP server on the segment.

How often should I back up the DHCP database?

Windows takes an automatic Jet database backup to %windir%\System32\dhcp\backup every 60 minutes by default; that interval is configurable via Set-DhcpServerDatabase -BackupInterval. For enterprise sites, complement the built-in backup with a full offline copy of the entire dhcp folder in your VM-level or file-level backup job, and export scope configuration with Export-DhcpServer before any major change. Failover partners are not a backup; they replicate corruption too.