Dell desktops aren't getting DHCP addresses after reboot. Where should I look?

November 14, 2026 4 answers
Asked by Miraq-6v

Several Dell desktops aren't getting an IP address after reboot. Releasing and renewing the lease works until the next reboot. The affected machines have both Intel and Realtek network adapters, and the DHCP server runs Windows Server.

Some clients have KB5101650 installed, but removing it from one test PC didn't fix the problem. Non-Windows devices and Windows virtual machines on the same subnet can get addresses. What should I check next?

Answers

c71!grommet_826

Start with a packet capture on an affected desktop during boot, plus the DHCP server logs or a capture on the server. Follow the DHCP Discover, Offer, Request and Acknowledgment exchange and see where it stops.

If the server is on another subnet, check the relay or helper configuration along the path too. A manual renew working doesn't tell you whether the initial request was sent, reached the server, or got a reply back.

c62!drizzle_907:

Also look at which server sent any offers. An unexpected offer could point to another device running DHCP on the network.

Reply to this answer
73q+hingeplate_506

Check the scope for available addresses and look for an active lease for a machine that failed to get one. A reservation is worth testing on one affected PC, but compare the result with a normal lease. It won't fix a request that never reaches the server.

Reply to this answer
spare+comma_12

The reboot pattern makes the wired link and adapter drivers worth checking. Compare driver versions and settings on affected and unaffected desktops, and check whether the switch port is ready to forward traffic when Windows starts DHCP.

Review the switch's spanning tree configuration for client-facing ports, including its edge or portfast equivalent. Don't change that blindly on ports connected to other switches.

Reply to this answer
n840!peppermill_3

I wouldn't pin this on KB5101650 yet. Removing it from one machine didn't resolve the issue, and the symptoms alone don't establish a cause. Compare update and driver versions across working and failing clients, then test changes on a machine you can reach locally.

Be careful with scheduled release and renew tasks during remote troubleshooting. If the machine doesn't come back on the network, you may lose access before you can inspect it.

Reply to this answer

Add your answer

Answers are reviewed before publication.

Related Discussions