Troubleshoot Windows Server DHCP failures by checking scopes, leases, authorization, network relay and DHCP Server service health.
Confirm the DHCP service is healthy and the scope isn't exhausted, then verify authorization, relay configuration and an actual test lease.
A DHCP scope near exhaustion fails intermittently and only for new clients — existing leases keep renewing fine, which can mask the real cause for days.
Confirm the DHCP Server service is running and review recent service events.
Check the DHCP service and recent events
Get-Service DHCPServerIf it's running but clients still can't get addresses, check for recent service-level events before assuming a scope or network problem — DHCP logs its own audit log by default at C:\Windows\System32\dhcp\DhcpSrvLog-<Day>.log, which records every lease request, ACK, and NAK with a reason code, and is far more specific than the general Event Viewer entries.
Check scope health and utilization
A scope that's run out of available addresses fails in a way that looks identical to a network outage to affected users — new clients simply never get an address, while clients that already have a lease keep renewing normally, which can mask the problem for a long time. Check utilization directly:
Get-DhcpServerv4ScopeStatistics -ScopeId 10.0.0.0 | Select-Object ScopeId, Free, InUse, PercentageInUseAlso check for reservations or exclusions consuming more of the range than expected, and confirm the scope isn't inadvertently deactivated:
Get-DhcpServerv4Scope | Select-Object ScopeId, State, StartRange, EndRangeCheck DHCP server authorization in Active Directory
In a domain environment, an unauthorized DHCP server refuses to hand out leases entirely — Windows Server DHCP checks AD authorization on startup and periodically thereafter. This is a common cause right after a new DHCP server is stood up or an existing one is rebuilt:
Get-DhcpServerInDCIf the server isn't listed, authorize it:
Add-DhcpServerInDC -DnsName "dhcp01.contoso.com" -IPAddress 10.0.0.10Check DHCP relay for routed networks
If clients are on a different subnet/VLAN than the DHCP server, DHCP broadcasts don't cross routers on their own — a relay agent (IP helper address configured on the router/L3 switch) is required. Confirm the helper address on the client's VLAN gateway points to the correct DHCP server IP, and confirm the DHCP server's scope actually covers that subnet. A relay pointed at the wrong server, or a scope that doesn't exist for that subnet, produces the same symptom as a completely unreachable DHCP server from the client's perspective.
Test from an actual client
Reproduce the failure directly rather than relying only on server-side data:
ipconfig /release
ipconfig /renewCapture the specific result — "media disconnected," "an error occurred while renewing," or a successful lease with an unexpected gateway or DNS server are three different problems. If ipconfig /renew hangs for a long time before failing, that's usually a broadcast/relay reachability issue rather than a scope or authorization problem, since the client is waiting for a response that never arrives at all.
Validate the lease details, not just success
A successful lease isn't automatically a correct one — confirm the assigned gateway, DNS servers and lease duration match the scope options you expect:
ipconfig /allA client receiving the right IP but the wrong DNS servers usually means scope options were edited at the server level after clients already had active leases, or a second, unauthorized DHCP server on the network is answering some requests — check for rogue DHCP servers with a packet capture or the built-in DHCP server conflict detection if this is suspected.