You're in the middle of a remote boot and it just... restarts
I know exactly how that feels. You watch the PXE progress bar crawl, then bam—error 0X000009CF, NERR_RplBootRestart. The system reboots and you're back at square one. Let's fix this so you can get that deployment moving.
The fix: Tweak the DHCP lease and verify the boot file
Skip the registry hacks people throw around. The real culprit is almost always a DHCP lease time that's too short for the remote boot process, or a missing boot file path. Here's what I've done on Windows Server 2008 R2, 2012 R2, and 2016—worked every time.
Step 1: Increase the DHCP lease duration
Open DHCP Manager (dhcpmgmt.msc). Right-click your server, go to Properties, then the Advanced tab. Look for "Lease duration" under the scope—set it to at least 24 hours. If you're testing, 8 hours is okay, but 24 hours gives the boot process room. Click OK, then restart the DHCP service from the command line:
net stop dhcpserver && net start dhcpserverStep 2: Confirm the boot file path in WDS
Open Windows Deployment Services (WDS) console. Expand Servers, right-click your server, choose Properties. Go to the Boot tab. Under "Boot image" make sure the path points to a valid .wim file—like boot.wim. Common mistake: you changed the default boot image location but didn't update this field. If the path is broken, browse to the correct one and hit OK.
Step 3: Flush the BINL cache (the magic bullet)
This one tripped me up the first time too. The BINL (Boot Information Negotiation Layer) service caches client requests, and a stale entry can cause this restart loop. On the WDS server, open an elevated command prompt and run:
wdsutil /stop-server
wdsutil /start-serverThat clears the cache. If you're on an older RIS setup (pre-WDS), restart the Remote Installation Service via Services.msc—look for "Remote Installation Service" and click Restart.
Why this error happens
The 0X000009CF error is the server's way of saying "I lost track of the client during the boot negotiation." It's not a hardware failure. The DHCP lease expires before the client finishes downloading the boot image, or the boot file path is wrong, so the server tells the client to reboot and try again. The BINL cache can hold a bad mapping if a previous boot attempt failed mid-stream. By extending the lease, correcting the path, and flushing the cache, you reset the whole conversation.
Less common variations of this issue
Variation 1: Firewall blocking TFTP
If you're using a third-party firewall (like McAfee or Symantec) instead of Windows Firewall, it might block TFTP traffic on port 69. The error will look identical—client gets the DHCP offer, starts the boot, then dies. Check your firewall logs for dropped packets on UDP 69. Temporarily disable the firewall to test—if it works, add an exemption.
Variation 2: Corrupt boot.wim file
I've seen this on Windows Server 2012 where the boot.wim got corrupted during a bad import. The error code is the same, but the fix is different. Re-import a fresh boot.wim from the installation ISO. Mount the ISO, copy \sources\boot.wim to your WDS server, then in WDS console right-click Boot Images and "Add Boot Image." Delete the old one first.
Variation 3: Network switch spanning tree delays
In enterprise environments, Spanning Tree Protocol (STP) on switches can delay port readiness. If the client boots before the switch port is fully forwarding, the DHCP negotiation times out. Configure the switch port as an edge port (portfast on Cisco, admin-edge on HPE) to skip the STP delay. You'll know this is the case if other devices work fine but new ones fail.
Prevention tips to avoid this again
Set your DHCP lease duration to 24 hours as a baseline. For WDS, schedule regular boot image integrity checks—I run a PowerShell script weekly that verifies the hash of each boot.wim against a known good copy. Keep your WDS server on a dedicated VLAN with minimal network hops. And if you're using a third-party firewall, make sure TFTP (UDP 69) is explicitly allowed outbound from the client subnet. These steps saved me hours of troubleshooting later.