I'm a sysadmin managing around 1000 systems and recently encountered a puzzling DHCP issue. We have multiple DHCP scopes in our network, including one dedicated VLAN used for imaging new systems. Under normal circumstances, after imaging, these devices join our domain and receive necessary updates and software before transitioning to the primary user VLAN, which requires DHCP leasing. However, something changed last week, and now newly imaged systems don't receive DHCP leases on the primary VLAN.
We've confirmed that the devices' MAC addresses are detected all the way up to the switch connected to the DHCP server, indicating that the requests are making it through to that point. While our load-balanced DHCP servers are logging requests from these MAC addresses on the build VLAN, there are no hits at all on the primary VLAN once they switch. Existing devices on the primary user VLAN continue to function normally, even after attempts to renew leases.
Interestingly, when we assign a static IP to these newly imaged devices on the primary VLAN, they can then obtain a DHCP lease after the static address is removed.
I did spot an error 0x79 in the DHCP event logs, which suggests possible scope issues, IP conflicts, or configuration errors, though nothing seems out of place on our end. The one documented change was a recent GPO update that enabled Windows Defender Firewall on our DHCP servers, with domain policy allowing all inbound/outbound traffic (public/private traffic is more restricted). However, other administrative teams assert no changes occurred on their ends. Due to strict security policies, I can't use packet sniffing tools at this point.
I'm looking for insights or suggestions on why our DHCP scopes seem to be failing specifically for newly imaged devices.
8 Answers
Does your DHCP server perform conflict detection? If someone assigned a manual IP from the DHCP range without setting up a reservation, that could cause issues for new devices.
You might want to ensure that outbound private ranges are properly blocked. This can affect DHCP traffic.
This specific failure—new machines transitioning from a build VLAN to a user VLAN suddenly breaking—is very peculiar. What changed in your network recently?
How is your load balancing set up on the DHCP servers? Are you using split scopes or are both servers sharing the same scoping? That could influence how leases are being handed out.
We have the same scopes on both servers, configured for a 50-50 active load balancing.
A recent KB update caused us similar headaches, and it aligns with your timeline of issues. This might be worth looking into.
It sounds like you're going to need to communicate with your team to investigate further. Understanding what's happening on the network and reviewing the DHCP transactions is crucial at this point.
I had a similar issue where the DHCP database had corrupted entries, which only became apparent after a service restart. The event log showed the scope was full of invalid leases due to bad data.
This seems closely tied to your NAC/802.1x configuration. Definitely check the certs and switch logs to see if ports are being disabled. You’ll want to rule that out.
The certs are fine on newly imaged devices. I’ll ask the network team if they can check the logs for any authentication issues on Monday. If 802.1x was the root of the problem, I'd think that getting a static IP wouldn't resolve it afterward.
The only change we identified was a GPO update that enabled the Windows firewall on our servers last week. We hadn't considered this an immediate factor, but I’m curious how DHCP broadcasts interact with that firewall. I’ll also check the firewall logs on the DHCP servers.