Helpdesk: "Third floor is down. Every laptop that docked this morning shows a 169.254 address and 'No internet.' People who never undocked are fine. The network team swapped a switch stack over the weekend. Someone already restarted the DHCP Server service twice. Can you just add more addresses to the scope?"
Don't widen the scope yet. "DHCP not assigning IP addresses" on a Windows Server network is rarely the DHCP service being "broken." It's usually one layer in a documented chain: the client is actually sending DHCP requests (adapter, DHCP Client service, firewall on UDP 67/68), or it isn't → the DHCP Server service is running and authorized in Active Directory, or it stopped servicing clients and logged Event 1046 → the scope for that subnet is Active and has free addresses, or it's full (Event 1063), blocked by BAD_ADDRESS leases, or colliding with static devices that were never excluded → the request reaches the server, either because the server's binding is on that subnet or because a relay agent (IP helper) forwards it, or the relay/snooping layer drops it → no MAC filter or policy is quietly refusing the client → a failover relationship is in a healthy state, not COMMUNICATION INTERRUPTED with the partner holding the free pool → a two-sided packet capture shows exactly which DORA packet goes missing. ipconfig /all, Get-DhcpServerInDC, Get-DhcpServerv4ScopeStatistics, Get-DhcpServerv4Binding, the DHCP audit log, Get-DhcpServerv4Failover, and a Wireshark trace on both ends are the sources for that chain. Restarting the service or adding addresses can clear the symptom for an hour. It doesn't tell you which layer failed, which is why the same floor goes dark again after the next switch change.
If the client gets an address but Wi-Fi authentication or the network profile is the real failure, start with Intune Wi-Fi Profile Not Applying. If the machine has a valid address but policy never arrives, use Group Policy Not Applying. This post covers "Windows clients on one or more subnets aren't getting an IPv4 address (or are falling back to 169.254 APIPA) from a Windows Server DHCP server, and you need a read-first path through the client, authorization, scope, relay, filters, and failover before you restart, re-authorize, widen, or rebuild anything."
TL;DR
- 169.254.x.x means the client gave up, not that DHCP is "off." Microsoft's APIPA article: a DHCP-configured Windows client assigns itself an address from 169.254.0.0–169.254.255.255 when no DHCP server answers, and it can't reach other subnets with it.
- One client, one subnet, or everyone? Microsoft's checklist asks exactly that first. One client points at the client or switch port. One subnet points at the scope or relay. Everyone points at the server, authorization, or failover.
-
Read the server before you touch it. Service running (
net start), authorized (Get-DhcpServerInDC, Event 1046), scope Active with free addresses (Get-DhcpServerv4ScopeStatistics, Event 1063), BAD_ADDRESS leases, and bindings (Get-DhcpServerv4Binding). - Remote subnets need a relay. Microsoft's checklist: confirm the relay agent (IP helper) is configured and that its IP can be pinged from the DHCP server. With failover, the relay must point at both partners.
- Filters and failover can refuse clients silently. An enabled allow list with no entries serves nobody (Event 20098). A failover partner stuck in COMMUNICATION INTERRUPTED doesn't take over the whole pool.
- Prove it with DORA. Capture on client and server at the same time. Which of DISCOVER, OFFER, REQUEST, ACK is missing on which side tells you whose layer it is.
Where in the chain did it break?
| Step | What should be true | Typical symptom when it breaks |
|---|---|---|
| 1. Symptom captured | Scope of impact (one client / one subnet / all), when it started, what changed, APIPA or no address | "DHCP is down" with no subnet, time, or change history |
| 2. Client asking | Adapter up, DHCP Client service running, no firewall on UDP 67/68, client DHCP logs read | Server-side changes for a single laptop with a bad cable or driver |
| 3. Server running and authorized | DHCP Server service started; server listed in Get-DhcpServerInDC; no Event 1046 |
Service restarts that never help because AD says it isn't authorized |
| 4. Scope has addresses | Scope Active; free addresses left; no BAD_ADDRESS pile-up; statics excluded | Widening the range while the real problem is conflicts or an inactive scope |
| 5. Request reaches server | Binding on the right interface, or a relay (IP helper) forwarding to it; ports 67/68 not taken | Scope looks perfect but no DISCOVER ever arrives |
| 6. Filters and policies | Allow/deny lists and policies match what you intend | Some devices served, specific MACs or device classes refused |
| 7. Failover healthy | Relationship NORMAL; time in sync; both partners reachable by clients and relays | Half the clients fail after a partner outage or a relay change |
| 8. DORA proven | Two-sided capture shows where the exchange stops | Arguments between server and network teams with no packet evidence |
| 9. Change | Only after Steps 1–8 agree: one layer, one change | Service restarted, scope widened, server re-authorized, still failing |
Step 1: Capture the exact symptom (read-only)
Microsoft's DHCP troubleshooting checklist starts with questions, not commands. Write these on the ticket before anyone restarts the service:
| Fact | Why it matters |
|---|---|
| When did it start? | Lines up with switch, firewall, patch, or server changes. Microsoft asks whether anything changed before the problem started |
| Has it ever worked? | A new scope that never worked is a design problem (relay, binding, authorization). A working scope that stopped is a change problem |
| Persistent or intermittent? | Intermittent failures point at failover, duplicate relays, or a nearly full scope. Persistent ones point at authorization, an inactive scope, or a missing relay |
| All clients or one subnet? | Microsoft's own split: all clients versus only specific clients such as a single-scope subnet |
| Same subnet as the DHCP server? | Microsoft asks whether clients on the server's own subnet still get addresses. If they do, the relay path to remote subnets is suspect |
| Standalone, split-scope, or failover? | Changes which server should answer and which pool it can use |
| Snooping / DAI / VRRP / HSRP on the path? | Microsoft explicitly calls out these intermediate-device features as known to cause problems |
| Address the client actually has | 169.254.x.x (APIPA), an old lease, an address from the wrong subnet, or nothing |
Then match the symptom:
| What you see | Likely layer |
|---|---|
| One laptop on APIPA, neighbors fine | Client, cable, port, or MAC filtering on the switch (Step 2) |
| Every client on every subnet failing, Event 1046 on the server | Authorization (Step 3) |
| One subnet failing, Event 1063 or a scope near 100% in use | Scope exhausted (Step 4) |
| Scope has free addresses but audit log shows code 13 or many BAD_ADDRESS leases | Address conflicts / static devices not excluded (Step 4) |
| Server-local subnet works, remote subnets get nothing after a switch change | Relay / IP helper (Step 5) |
| Specific devices refused while others on the same subnet work | Filters or policies (Step 6) |
| Problems started when one failover partner went offline | Failover state (Step 7) |
| Client sends DISCOVER, server logs nothing | Network path, snooping, or relay drop (Steps 5 and 8) |
Step 2: Is the client really asking? (read-only)
Microsoft's client checklist is short: cables connected and working, MAC filtering on the switch, adapter enabled, current driver, DHCP Client service running, and no firewall blocking UDP 67 and 68 on the client.
# Read-only. Run on an affected client
ipconfig /all
Get-NetAdapter -IncludeHidden |
Select-Object Name, InterfaceDescription, ifIndex, Status, MacAddress
net start
In ipconfig /all, Microsoft's APIPA article says the client is using APIPA when Autoconfiguration Enabled is Yes and the address is 169.254.x.y. In net start, look for DHCP Client. Get-NetAdapter -IncludeHidden gives you the interface ID and MAC address you'll need to read the client events and match the server's lease and audit records.
Microsoft also points you to the client's own DHCP event logs (Microsoft-Windows-DHCP Client Events/Operational and /Admin under Applications and Services Logs). List the channel names first instead of guessing them:
# Read-only. List the DHCP channels this build has, then read the client ones
Get-WinEvent -ListLog '*Dhcp*' | Select-Object LogName, RecordCount
$clientLogs = (Get-WinEvent -ListLog '*Dhcp*' | Where-Object LogName -like '*Client*').LogName
Get-WinEvent -FilterHashtable @{ LogName = $clientLogs } -MaxEvents 20 -ErrorAction SilentlyContinue |
Format-List TimeCreated, LogName, Id, LevelDisplayName, Message
What APIPA tells you (and what it doesn't)
| Client state | What Microsoft's APIPA article says | What to read next |
|---|---|---|
| 169.254.x.y, never had a lease | Client broadcast several DISCOVERs, nobody answered, it assigned itself an APIPA address and keeps retrying | Steps 3–5 and 8: did any DISCOVER reach a server? |
| 169.254.x.y, had a lease before | Client couldn't find a DHCP server and couldn't reach its default gateway, so it fell back to APIPA | Same, plus whether the gateway / VLAN itself changed |
| Old lease still in place | If the default gateway answers, the client keeps its previously leased address | The outage may be wider than the tickets show; renewals will fail later |
| Address from the wrong subnet | Not APIPA: some DHCP server answered | Rogue or misconfigured server, wrong relay target, or wrong VLAN on the port |
Lease timing matters for "it worked yesterday." Microsoft's DHCP troubleshooting guide says clients send unicast renew requests to their server after 50 percent of the lease, and broadcast rebind requests to any server after 87.5 percent. An outage that started overnight may only show up on clients whose leases reach those points.
If the client side is clean and other clients on the same port or switch fail too, move to the server. If only this device fails, check the switch port, MAC filtering, the dock or adapter driver, and the client firewall before anyone touches the DHCP server.
Step 3: Is the DHCP server running and authorized? (read-only)
Microsoft's server checklist begins with two facts: the DHCP Server service is started, and the server is authorized.
# Read-only. Run on the DHCP server (DhcpServer module)
net start
Get-DhcpServerInDC
netsh dhcp show server
In net start, look for DHCP Server. Get-DhcpServerInDC lists the DHCP servers authorized in Active Directory. Microsoft says only an authorized server on a domain-joined computer can lease IP addresses. netsh dhcp show server is Microsoft's command-prompt equivalent from the authorization troubleshooting guide.
How authorization fails
Microsoft's authorization guide says the authorized list lives in AD's Configuration partition (Configuration > Services > NetServices) and the DHCP server checks its authorization over LDAP every hour. If the server's IP address isn't in that list, it deauthorizes itself. So a server can work for weeks and stop within the hour after its entry disappears.
Symptoms Microsoft lists:
| Signal | Meaning |
|---|---|
| System Event 1046 | "The DHCP/BINL service on the local machine, belonging to the Windows Administrative domain ..., has determined that it is not authorized to start. It has stopped servicing clients." |
| Downward red arrow on IPv4 in the DHCP console | Server isn't authorized |
| Error Code: 20070 after the role install | "The DHCP service could not contact Active Directory" |
| "The specified domain either does not exist or could be contacted" | Manual authorization couldn't reach AD |
Related events on Microsoft's DHCP server event list: 1059 (the service failed to see a directory server for authorization), 1041 (not servicing any DHCPv4 clients because no active interface has a statically configured IPv4 address, or there are no active interfaces), and 1044 (authorized to start and servicing clients – the healthy one).
# Read-only. Server-side authorization and rogue-detection events
Get-WinEvent -FilterHashtable @{
LogName = 'System'
ProviderName = 'Microsoft-Windows-DHCP-Server'
Id = 1041, 1044, 1046, 1059
} -MaxEvents 30 -ErrorAction SilentlyContinue |
Format-Table TimeCreated, Id, Message -Wrap
Microsoft's four causes for authorization failures:
| Cause | Read-only check |
|---|---|
| Permissions | Was the authorizing account an Enterprise Admin? Microsoft recommends one |
| Entry missing from AD | ADSI Edit → Configuration → Services → NetServices: is the server's name there? |
| Connectivity |
Test-NetConnection -ComputerName <DC-IP> -Port 389 from the DHCP server; LDAP TCP/UDP 389 not blocked |
| AD replication / conflict objects | Entries under NetServices with a CNF tag in the CN (for example CNF:ca69f501234) block authorization |
# Read-only. From the DHCP server
Test-NetConnection -ComputerName 10.20.0.10 -Port 389
If authorization works when you re-run it but fails again a few days later, Microsoft's guide says the entry is being deleted from AD, and suggests auditing Directory Service Changes on the DCs plus an audit entry on the NetServices container to find who deletes it. That's a change to audit policy, so plan it with your AD owner.
The DHCP audit log
Microsoft documents a comma-delimited audit log under %windir%\System32\Dhcp (fields: ID, Date, Time, Description, IP Address, Host Name, MAC Address). The authorization codes are worth reading before you re-authorize:
| Audit ID | Microsoft's description |
|---|---|
| 54 | Authorization failed – likely followed by the server being stopped |
| 55 | Authorization (servicing) – authorized and serving |
| 56 | Authorization failure, stopped servicing – authorize it in the directory before starting it again |
| 59 | Network failure prevented the server from determining whether it's authorized |
| 64 | No DHCP-enabled interfaces – bindings, no active connection, or no static IP on an active connection |
# Read-only. Audit log settings, then recent authorization and lease-failure lines
Get-DhcpServerAuditLog
Select-String -Path "$env:windir\System32\dhcp\DhcpSrvLog-*.log" -Pattern '^(13|14|15|54|55|56|59|64),' |
Select-Object -Last 40 | ForEach-Object { $_.Line }
That audit-code table comes from Microsoft's archived Windows Server 2008 log reference, which is still the page Microsoft's current troubleshooting guide links to. Check the header of your own log file: it lists the event IDs that build actually writes.
Step 4: Is the scope active, and does it have free addresses? (read-only)
Microsoft's server checklist: verify that leases are available in the scope for the client's subnet, check for BAD_ADDRESS entries in Address Leases, and check for devices with static IP addresses that haven't been excluded from the scope.
# Read-only. On the DHCP server
Get-DhcpServerv4Scope |
Format-Table ScopeId, Name, State, StartRange, EndRange, SubnetMask, LeaseDuration -AutoSize
Get-DhcpServerv4ScopeStatistics |
Where-Object { $_.PercentageInUse -gt 80 }
The scope State is either Active or InActive (the values Set-DhcpServerv4Scope accepts). An InActive scope doesn't hand out addresses, which is easy to miss after a migration or a scope that someone "prepared for later." Microsoft's own example filters Get-DhcpServerv4ScopeStatistics on PercentageInUse -gt 80 to find scopes running out.
Full scope
| Event | Microsoft's text |
|---|---|
| 1020 | Scope, %1, is %2 percent full with only %3 IP addresses remaining |
| 1063 | There are no IP addresses available for lease in the scope or superscope %1 |
| 1341 | There are no IP addresses available for lease in IP address range(s) of the policy %1 in scope %2 |
| 1342 | IP address range of scope %1 is out of IP addresses |
Audit log code 14 is the same story from the log: a lease request couldn't be satisfied because the scope's address pool was exhausted.
# Read-only. Scope-full and low-address events from System plus the DHCP Server channels
$dhcpLogs = @('System') + (Get-WinEvent -ListLog '*DHCP*Server*' -ErrorAction SilentlyContinue).LogName
Get-WinEvent -FilterHashtable @{ LogName = $dhcpLogs; Id = 1020, 1063, 1341, 1342 } -MaxEvents 30 -ErrorAction SilentlyContinue |
Format-Table TimeCreated, LogName, Id, Message -Wrap
# Read-only. Free addresses, exclusions, reservations
Get-DhcpServerv4FreeIPAddress -ScopeId 10.20.30.0 -NumAddress 5
Get-DhcpServerv4ExclusionRange -ScopeId 10.20.30.0
Get-DhcpServerv4Reservation -ScopeId 10.20.30.0
Get-DhcpServerv4FreeIPAddress already leaves out exclusion ranges, reservations, active and offered leases, and bad (declined) leases, and it warns when it can't find the number you asked for. If it returns nothing, the scope really is full for new clients.
Two notes from Microsoft's cmdlet pages that change how you read this:
-
Exclusions don't beat reservations.
Add-DhcpServerv4ExclusionRangesays an address in an exclusion range is still leased to a client that has a reservation for it. -
Expired leases count as free.
Get-DhcpServerv4FreeIPAddressincludes addresses in the expired (doomed) state, so a scope can look busy in the console and still have room.
BAD_ADDRESS and conflicts
# Read-only. Declined leases in the scope, then everything including expired/declined
Get-DhcpServerv4Lease -ScopeId 10.20.30.0 -BadLeases
Get-DhcpServerv4Lease -ScopeId 10.20.30.0 -AllLeases |
Group-Object AddressState | Select-Object Name, Count
Get-DhcpServerSetting
Microsoft's Get-DhcpServerv4Lease page says a lease is marked bad (declined) when a client declines it because of a conflict with another client, and that address isn't offered to anyone until a 10-minute timer expires. Audit code 13 means an IP address was found in use on the network. A pile of BAD_ADDRESS entries in one range usually means static devices (printers, cameras, appliances) living inside the scope without an exclusion. Every time DHCP offers one of those addresses, the client detects the conflict and declines it.
Get-DhcpServerSetting shows ConflictDetectionAttempts. Microsoft's Set-DhcpServerSetting page says it accepts 0 through 5 and the default is 0, so by default the server doesn't ping an address before leasing it.
Step 5: Do the requests actually reach the server? (read-only)
A perfect scope doesn't help if the DISCOVER never arrives. Microsoft's checklist has four reads here.
Bindings
# Read-only
Get-DhcpServerv4Binding
Microsoft: the server must bind to at least one IP address, and that address must be inside the subnet of the scopes it leases from, unless a relay is used. Bindings live in the DHCP console under IPv4 Advanced properties. A second NIC added for backup or iSCSI, or a NIC that was re-addressed, can leave the service bound to the wrong interface. Audit code 64 and Event 1041 are the "nothing to bind to" versions.
Ports 67 and 68
netstat -anb
Run elevated and look for UDP 67 and 68. Microsoft says only the DHCP server should be listening there, and specifically calls out WDS or PXE as services that shouldn't occupy those ports. Microsoft's event list has Event 20090: the DHCP Server is unable to bind to the UDP port because another application is using it.
IPsec
If the environment uses IPsec, Microsoft says to verify that the DHCP server IPsec exemption is in place.
Relay agents (IP helpers)
Clients broadcast DISCOVER on their own subnet, and routers don't normally forward broadcasts. Microsoft's failover deployment notes say relay agents, usually on a router or layer-3 switch (ip helper-address 10.0.1.1 is Microsoft's example), forward DHCP between subnets. Microsoft's server checklist adds: verify that the relay agent IP address can be pinged from the DHCP server.
# Read-only. From the DHCP server, ping the relay agent (the gateway IP on the client VLAN)
Test-Connection -ComputerName 10.20.30.1 -Count 2
What usually breaks after a weekend switch change:
| Relay problem | What you see | Read-first check |
|---|---|---|
| IP helper missing on the new VLAN interface | Server-local subnet works, the moved subnet gets APIPA | Network team: helper configured on that VLAN's gateway interface |
| Helper points at an old or wrong DHCP IP | Nothing in the server's audit log for those MACs | Compare the helper target with Get-DhcpServerv4Binding
|
| Only one helper with failover | Clients served only while that one partner is healthy | Microsoft: clients must reach both partners; use two helpers |
| Gateway IP has no matching scope | DISCOVER arrives, no OFFER | Scope exists for the client subnet on this server (Step 4) |
| DHCP snooping / Dynamic ARP Inspection | Server sends OFFER, client never sees it | Trusted port / snooping config on the new switch (Step 8 proves it) |
| VRRP/HSRP pair with relays on both | Duplicate requests, inconsistent lease durations | Microsoft's duplicate-relay warning; vendor HSRP relay config |
The "gateway IP has no matching scope" row is our reading of how relayed requests work. The relay fills the relay-agent address (giaddr) and the server picks the scope that matches it, per RFC 2131. Microsoft's own checklist only says the binding must be in the scope's subnet "unless using DHCP relay."
Step 6: Filters and policies (read-only)
Microsoft's server checklist ends with "enumerate and check configured DHCP policies and filters." Both can refuse some clients and serve others, which looks a lot like a network problem.
# Read-only
Get-DhcpServerv4FilterList
Get-DhcpServerv4Filter
Get-DhcpServerv4Policy
Get-DhcpServerv4Policy -ScopeId 10.20.30.0
| Read | What can go wrong |
|---|---|
Get-DhcpServerv4FilterList |
Shows whether the allow and deny lists are enabled. An enabled allow list means only listed MACs get leases. Microsoft's Event 20098: no clients are being served because the allow list is empty and the server is configured to serve only clients in it |
Get-DhcpServerv4Filter |
The MAC addresses on each list. A replaced dock or USB-C adapter has a new MAC that isn't on the allow list |
Get-DhcpServerv4Policy (server and scope) |
Policies group clients by vendor class, user class, client identifier, MAC address, and similar, and can give them their own IP ranges. Event 1341 fires when a policy's range is full, even if the rest of the scope has room |
Get-DhcpServerSetting |
ActivatePolicies shows whether policy enforcement is on at the server level |
Audit code 15 (a lease was denied) next to a MAC address points you here.
Step 7: Is failover healthy? (read-only)
If the scope is in a DHCP failover relationship, read its state before you change anything on either partner.
# Read-only. On either partner
Get-DhcpServerv4Failover
Get-DhcpServerv4ScopeStatistics -ScopeId 10.20.30.0 -Failover
Test-NetConnection -ComputerName DHCP02 -Port 647
w32tm /stripchart /computer:DHCP02 /samples:3 /dataonly
What Microsoft's DHCP failover overview says that matters for "not assigning addresses":
| Fact | Why it matters |
|---|---|
| Modes: load balance (default, 50:50 by MAC hash) or hot standby (active/standby with a reserve, default 5%) | In hot standby, a standby that can't reach the active server hands out only its reserve for new clients until it's in PARTNER DOWN and the MCLT has expired |
| COMMUNICATION INTERRUPTED | Contact with the partner is lost. In hot standby, Microsoft says the standby won't use the entire pool while still in communications interrupted. In load balance, the surviving server serves all clients, starting with its own free pool |
| PARTNER DOWN | After the MCLT, the surviving server takes responsibility for 100% of the pool |
| MCLT | Microsoft Learn training says the default is one hour and it can't be zero. Renewals during interruptions get MCLT-length temporary leases |
| Auto state switchover |
Set-DhcpServerv4Failover: automatic COMMUNICATION INTERRUPTED → PARTNER DOWN is $False by default. Learn training gives a 60-minute default interval when you enable it |
| Time sync | Partners must be within one minute. Larger differences log a critical event (Microsoft's event list: the server is out of time synchronization with its partner) |
| TCP 647 | Failover traffic between partners. The role adds the Microsoft-Windows-DHCP-Failover-TCP-In / -Out firewall rules |
| Manual replication | Changes to a failover scope must be replicated manually to the partner. A new exclusion or option on one side isn't on the other |
| Relays | Clients must be able to reach both partners, directly or through relays |
Failover state events on Microsoft's list: 20251/20252 (failover state changed), 20253 (out of time sync with partner), 20254 (contact with partner established), and 20255 (lost contact with partner).
# Read-only. Failover state, time sync, and partner contact events from the DHCP Server channels
Get-WinEvent -ListLog '*DHCP*Server*' | Select-Object LogName, RecordCount
$foLogs = (Get-WinEvent -ListLog '*DHCP*Server*' -ErrorAction SilentlyContinue).LogName
Get-WinEvent -FilterHashtable @{
LogName = $foLogs
Id = 20251, 20252, 20253, 20254, 20255
} -MaxEvents 30 -ErrorAction SilentlyContinue |
Format-Table TimeCreated, LogName, Id, Message -Wrap
Step 8: Prove where DORA stops (read-only capture)
When Steps 2–7 disagree with the network team's view, Microsoft's guidance is a packet capture on both the client and the server at the same time. Filter on dhcp on the client, take the transaction ID, and filter dhcp.id == <id> on the server side.
ipconfig /release
ipconfig /renew
Run that on the client while both captures are running. Note that /release drops the client's current address – fine on a machine that's already on APIPA, disruptive on one that still works.
Microsoft's drop patterns:
| Client capture | Server capture | Where it broke |
|---|---|---|
| DISCOVER only | Nothing | Before the server: relay, VLAN, snooping, ACL |
| DISCOVER | DISCOVER + OFFER sent | Return path: OFFER dropped on the way back (snooping trust, relay, firewall) |
| DISCOVER, OFFER, REQUEST | DISCOVER + OFFER only | REQUEST lost on the way to the server |
| DISCOVER, OFFER, REQUEST | All four including ACK | ACK lost on the way back to the client |
| All four | All four | DORA worked. Look at the client (driver, adapter, duplicate address detection) or at what happens after the lease |
Microsoft's guidance says to involve the network team once drops are confirmed. For a support case, Microsoft's TSS scenarios are TSS.ps1 -Scenario NET_DHCPcli on the client and TSS.ps1 -Scenario NET_DHCPsrv on the server.
Common false starts (read these before you change anything)
| False start | Why it hurts | Read-first alternative |
|---|---|---|
| Restarting the DHCP Server service | An unauthorized server logs 1046 and stops servicing again. A full scope is still full | Step 3 (authorization) and Step 4 (free addresses) |
| Widening the scope range | Doesn't fix BAD_ADDRESS conflicts, an InActive scope, a policy range, or a missing relay. Can overlap statics |
Get-DhcpServerv4FreeIPAddress, BAD_ADDRESS, and exclusions first |
| Deleting all leases in the scope | Clients that still hold those addresses keep using them, so new offers can collide | Read -AllLeases by state; remove only bad leases after the static device is found |
| Re-authorizing in a loop | If AD keeps losing the entry, it will deauthorize again within the hourly check | Find CNF objects or the deleter (Microsoft's auditing steps) |
| Forcing PARTNER DOWN on a guess | Both partners may hand out the same pool if the "down" partner is actually up | Confirm the partner is really down; read 20255 / 20253 |
| Turning off APIPA on clients mid-outage | Gives nobody an address; it only changes what the failure looks like. Microsoft's article lists when you might disable it (routed networks, internet without NAT), but that's a design decision, not an outage fix | Fix the DHCP path first; decide on APIPA separately |
| Blaming the server without a capture | Snooping, helpers, and VRRP/HSRP are Microsoft's named suspects | Two-sided DORA capture (Step 8) |
Step 9: Change one layer, then watch (only after the read)
Pick the one change Steps 1–8 point at. Most DhcpServer Set-*/Add-*/Remove-* cmdlets support -WhatIf, so preview first.
# Change (DHCP server, elevated). Pick ONE that matches your finding
# Authorization (Enterprise Admin; Microsoft's example form)
Add-DhcpServerInDC -DnsName 'DHCP01.contoso.com' -IPAddress 10.20.0.5 -WhatIf
# Inactive scope
Set-DhcpServerv4Scope -ScopeId 10.20.30.0 -State Active -WhatIf
# Static devices inside the range: exclude them, then clear declined leases
Add-DhcpServerv4ExclusionRange -ScopeId 10.20.30.0 -StartRange 10.20.30.240 -EndRange 10.20.30.254 -WhatIf
Remove-DhcpServerv4Lease -ScopeId 10.20.30.0 -BadLeases -WhatIf
# Optional: ping before leasing (0-5 attempts; default 0)
Set-DhcpServerSetting -ConflictDetectionAttempts 1 -WhatIf
# Wrong binding
Set-DhcpServerv4Binding -InterfaceAlias 'Ethernet' -BindingState $true -WhatIf
# Failover: push this scope's config to the partner (run on the server whose settings you want)
Invoke-DhcpServerv4FailoverReplication -ScopeId 10.20.30.0 -WhatIf
Read-only confirm afterwards:
Get-DhcpServerInDC
Get-DhcpServerv4ScopeStatistics -ScopeId 10.20.30.0
Get-DhcpServerv4Lease -ScopeId 10.20.30.0 |
Sort-Object LeaseExpiryTime -Descending | Select-Object -First 10
Changes outside the DHCP server:
- Relay / IP helper: the network team adds or fixes the helper on the client VLAN's gateway interface, with both failover partners listed.
- Snooping / DAI: mark the uplink toward the DHCP server or relay as trusted, per the switch vendor's documentation.
-
Client:
ipconfig /renew(or reconnect) once the server side is fixed.
Watch one renewal cycle: a test client gets a lease in the right subnet, audit log code 10 (new lease) appears for its MAC, Event 1063 / 1046 / 20255 stop, and the scope statistics stay below your warning threshold.
Failover PARTNER DOWN (Set-DhcpServerv4Failover -Name '<relationship>' -PartnerDown) is a deliberate decision. Use it only when the partner is really offline for longer than you can wait out the MCLT, and plan how you'll bring it back.
When a change is justified
| Finding | Prefer | Avoid |
|---|---|---|
Event 1046, server missing from Get-DhcpServerInDC
|
Re-authorize with an Enterprise Admin; check NetServices for CNF objects first | Restarting the service until it "sticks" |
| Authorization keeps disappearing | Audit the NetServices container to find the deleter (Microsoft's steps) | Scheduled re-authorization scripts |
| Scope InActive | Activate it after confirming the range and options are correct | Creating a duplicate scope for the same subnet |
| Scope at 100%, few BAD_ADDRESS | Shorter lease for transient devices, or a larger range if the subnet allows | Overlapping the new range with statics or another scope |
| Many BAD_ADDRESS, audit code 13 | Exclude the static devices, then clear bad leases | Widening the scope and keeping the conflicts |
| Remote subnet only, after a switch change | Fix the IP helper (both partners) on the new gateway interface | Moving the DHCP server onto that VLAN |
| Allow list enabled, Event 20098 | Add the intended MACs or turn off the allow list deliberately | Disabling all filtering without asking why it was on |
| Failover COMMUNICATION INTERRUPTED, partner really down | PARTNER DOWN on purpose, or enable auto state transition with a sane interval | Forcing PARTNER DOWN while the partner is still serving |
| Scope config differs between partners | Replicate from the server that has the settings you want | Editing both sides by hand |
FAQ
Why is my DHCP server not assigning IP addresses?
Usually one of a handful of documented layers: the DHCP Server service isn't authorized in Active Directory (Event 1046), the scope is InActive or out of addresses (Event 1063), BAD_ADDRESS conflicts from static devices, the server's binding or relay doesn't cover the client's subnet, a MAC filter or policy refuses the client, or a failover partner is stuck in COMMUNICATION INTERRUPTED. Microsoft's checklist walks those in roughly that order.
Why does my computer have a 169.254 address?
That's APIPA. Microsoft's article says a DHCP-configured Windows client assigns itself an address in 169.254.0.0–169.254.255.255 when it can't reach a DHCP server, and it can only talk to other machines on the same local subnet with that address. Fix the path to DHCP. Don't treat the 169.254 address as the problem.
How do I check if a DHCP server is authorized?
Run Get-DhcpServerInDC (or netsh dhcp show server) and look for the server, or open ADSI Edit → Configuration → Services → NetServices. Microsoft says the server checks its authorization over LDAP every hour and deauthorizes itself if its IP address isn't in that list.
What does DHCP Event 1063 mean?
"There are no IP addresses available for lease in the scope or superscope." Read Get-DhcpServerv4ScopeStatistics and Get-DhcpServerv4FreeIPAddress, then look at BAD_ADDRESS leases and unexcluded static devices before you widen the range. Event 1341 is the same idea for a policy's IP range.
Why does DHCP work on the server's subnet but not on other VLANs?
Remote subnets depend on a DHCP relay agent (IP helper) on the router or layer-3 switch. Microsoft's checklist says to confirm the relay is configured and that its IP is pingable from the DHCP server. With failover, both partners need to be reachable, which usually means two helper addresses.
Related posts
- Intune Wi-Fi Profile Not Applying (when EAP succeeds but the device still has no usable network – VLAN, NPS, or DHCP on the other side)
- Group Policy Not Applying (once the client has a valid lease but domain policy still doesn't arrive)
- Active Directory Account Keeps Getting Locked Out (another read-first Windows Server triage: event 4740 on the PDC emulator and the stale credential)
Free checklist
A DHCP outage often shows up first as a wave of "can't sign in" and "device not compliant" tickets from machines sitting on 169.254, and that's the afternoon someone wants to loosen or rush Conditional Access for everyone. Before you change enforcement, the free Conditional Access pre-enforcement checklist keeps break-glass accounts, pilot groups, and report-only review on one page:
If you want the rest of the Intune runway written down for the team (enrollment hygiene, compliance phasing, break/fix cards and read-only PowerShell snapshots), the Intune & M365 Admin Starter Pack pairs with this triage: https://cashflow4375.gumroad.com/l/joonf?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=dhcp-not-assigning-ip-addresses
Admin Pack Studio; not affiliated with Microsoft. Steps 1–8 favor read-only checks: ipconfig /all, Get-NetAdapter, net start, client and server DHCP event logs (1020 / 1041 / 1044 / 1046 / 1059 / 1063 / 1341 / 1342 / 20090 / 20098 / 20251–20255), the DHCP audit log, Get-DhcpServerInDC, netsh dhcp show server, Test-NetConnection, Get-DhcpServerv4Scope / ScopeStatistics / FreeIPAddress / ExclusionRange / Reservation / Lease, Get-DhcpServerSetting, Get-DhcpServerv4Binding, netstat -anb, filters, policies, Get-DhcpServerv4Failover, and a two-sided packet capture. Authorizing servers, activating or resizing scopes, adding exclusions, removing leases, changing bindings, conflict detection, filters, policies, failover state or replication, relays, and snooping are deliberate changes. ipconfig /release disconnects the client. Change one layer at a time, watch one renewal cycle, and check current Microsoft Learn for defaults and console labels.
Top comments (1)
The DORA troubleshooting approach is the most useful takeaway here. Restarting DHCP or expanding the scope without identifying where the request fails can easily mask the real issue, especially after network changes. Capturing packets on both the client and server gives the team evidence to isolate the problem instead of guessing.