How to Fix DHCP Not Giving IP Addresses on Windows Server

A client boots up, can’t reach anything, and ipconfig shows an address starting with 169.254. That’s the telltale sign DHCP isn’t doing its job — the machine asked for a lease, heard nothing useful back, and gave itself a link-local APIPA address as a last resort. The network is technically “up” and completely useless.

The frustrating part is that DHCP failures all look the same from the client, but the cause can sit anywhere between the client and the server. This guide works through the suspects in the order that finds the problem fastest: scope state and authorization first (they take seconds to rule out), then pool exhaustion and conflicts, then the cross-subnet relay and firewall issues that explain why “it works on the server’s own subnet but nowhere else.”

First, read the symptom correctly#

Before changing anything, confirm what the client is actually getting. On the client:

ipconfig /all

The output tells you a lot:

• Address 169.254.x.x, “Autoconfiguration Enabled: Yes” — pure APIPA. The DHCP request got no usable answer at all.
• A real address but wrong subnet/gateway — the client got a lease, but from the wrong scope or a rogue server. Different problem.
• “DHCP Enabled: No” — the client is statically configured. DHCP was never going to answer it.

This guide is about the first case: the client wants a lease and isn’t getting one. Note the client’s subnet, because whether it shares a subnet with the DHCP server changes which causes are even possible.

Cause 1: Scope isn’t active#

The quickest thing to rule out: the scope exists but isn’t turned on. A scope that’s been created but never activated, or one that was deactivated during maintenance, hands out nothing.

In the DHCP console (dhcpmgmt.msc), an inactive scope shows a red down-arrow on its icon. Right-click it and choose Activate. In PowerShell:

# Check scope state
Get-DhcpServerv4Scope | Format-Table ScopeId, Name, State, StartRange, EndRange

# Activate a scope that's showing Inactive
Set-DhcpServerv4Scope -ScopeId 10.10.0.0 -State Active

While you’re there, sanity-check the scope’s subnet mask, default gateway (option 003), and DNS servers (option 006). A scope that’s active but handing out the wrong gateway will get clients an address that still can’t route.

Cause 2: The server isn’t authorized in Active Directory#

This one catches people after a rebuild or a migration. A domain-joined Windows DHCP server checks Active Directory to confirm it’s an approved DHCP server. If it isn’t on the authorized list, it deliberately refuses to lease addresses — this is the built-in protection against rogue DHCP servers.

The tell is in the server’s event log (DHCP Server log) and the console: the server node shows a red down-arrow rather than a green up-arrow. Authorize it:

# Check authorization
Get-DhcpServerInDC

# Authorize this server in AD
Add-DhcpServerInDC -DnsName "dhcp01.ad.example.com" -IPAddress 10.10.0.5

Or in the console: right-click the server node → Authorize, then refresh. Authorization needs Enterprise Admin rights, which is a frequent snag — a Domain Admin who isn’t an Enterprise Admin can’t authorize a DHCP server.

Cause 3: The address pool is exhausted#

If the scope is active and authorized but only some clients fail — usually the newest ones — suspect an empty pool. Every address in the range is leased, so there’s nothing left to give.

Get-DhcpServerv4ScopeStatistics |
  Format-Table ScopeId, Free, InUse, PercentageInUse, Reserved

PercentageInUse at or near 100 confirms it. This is common on guest or BYOD networks where lots of short-lived devices each grab a lease and hold it for the default 8 days.

For a busy guest network, dropping the lease from 8 days to a few hours often solves exhaustion on its own:

Set-DhcpServerv4Scope -ScopeId 10.20.0.0 -LeaseDuration (New-TimeSpan -Hours 4)

Cause 4: Address conflicts and bad reservations#

Sometimes the server hands out a lease but the address is already in use by a statically-configured device, so the client gets it, detects a conflict, and ends up with nothing usable. Or a reservation points the wrong MAC at an address.

Turn on the server’s conflict detection so it pings an address before leasing it. Keep it low (1–2 attempts) — it adds a small delay to each lease:

Set-DhcpServerSetting -ConflictDetectionAttempts 1

The better long-term fix is discipline: keep statically-assigned devices (printers, servers, switches) outside the DHCP pool, either below the StartRange or in an exclusion range. Carving out an exclusion stops DHCP from ever handing out an address you’ve pinned by hand:

Add-DhcpServerv4ExclusionRange -ScopeId 10.10.0.0 -StartRange 10.10.0.1 -EndRange 10.10.0.20

Cause 5: No relay across subnets (the big one for remote VLANs)#

Here’s the classic “works here, not there” case. DHCP discovery is a broadcast, and routers don’t forward broadcasts. So a client on the same subnet/VLAN as the DHCP server gets a lease fine, while clients on every other subnet get nothing — because their DISCOVER never crosses the router.

The fix lives on the router or layer-3 switch, not the DHCP server: a DHCP relay agent, configured on most gear as an ip helper-address pointing at the DHCP server. Each remote VLAN’s gateway interface needs it.

! Example on a router/L3 switch interface for VLAN 20
interface vlan 20
 ip helper-address 10.10.0.5

If you’d rather relay through Windows than the router, the Routing and Remote Access role includes a DHCP Relay Agent you can bind to the relevant interfaces — but configuring the helper on the layer-3 device is the cleaner, more common approach.

Cause 6: Firewall blocking DHCP#

If discovery is reaching the server but no lease comes back, a firewall may be eating the traffic. DHCP runs over UDP:

Installing the DHCP Server role normally opens the right inbound rules in Windows Firewall, but a hardened image, group policy, or a third-party firewall can close them again. Confirm the inbound rules for the DHCP service are enabled, and check any firewall sitting between the relay and the server isn’t dropping UDP 67.

Force the client to try again, then verify#

Once you’ve changed something on the server side, make the client re-request rather than waiting for its lease timer:

ipconfig /release
ipconfig /renew
ipconfig /all

After /renew, ipconfig /all should show a real address, the correct gateway, and a DHCP Server field listing your server’s IP — that last field is the clean confirmation the lease came from where you expect.

On the server, confirm the new lease appeared:

Get-DhcpServerv4Lease -ScopeId 10.10.0.0 |
  Format-Table IPAddress, HostName, AddressState, LeaseExpiryTime

Wrapping up#

DHCP failures show up identically at the client — that lonely 169.254 address — but the cause is usually in one of a handful of places. Rule out the fast ones first: is the scope active, and is the server authorized in AD? Then check whether the pool is simply empty. If only remote subnets fail, the answer is almost always a missing relay on the router. And if discovery reaches the server but nothing comes back, look at the firewall.

Work the list top to bottom, force a /release and /renew after each change, and confirm with ipconfig /all that the address came from your server. For DHCP that’s tightly tied to AD, it helps to know your DNS and directory are healthy too — our notes on the best DNS settings for domain controllers pair well with a clean DHCP setup.