Fix 0X000009D0 Remote Boot Server Error

Quick Answer

Check that your WDS or RIS server is running and reachable from the client. Run wdsutil /get-server /show:all on the server. If it's offline, restart the service and verify DHCP options 66 and 67 point to the correct boot file.

Why This Happens

I know this error is infuriating when you're trying to PXE boot a new machine and it just drops this 0X000009D0 message. The exact error text says "The call to the Remoteboot server failed" with the code NERR_RplSrvrCallFailed. In my six years running a help desk blog, I saw this most often when someone moved a WDS server to a new subnet or changed DHCP scopes without updating the boot image paths.

This tripped me up the first time too. The client sends a DHCP discover with a PXE option, the DHCP server replies, but then the client can't open a TFTP or BINL connection to the WDS/RIS server. The server might be down, the firewall might be blocking UDP ports 67/68/69/4011, or the boot file path is wrong. On Server 2012 R2 and earlier, RIS used a different RPC binding to the Remoteboot service — if that service isn't running, you get this exact error.

Let's fix it.

Fix Steps

Check the WDS or RIS service — On your server, open Services.msc. Look for Windows Deployment Services Server (or Remote Installation Services on older servers). Make sure it's running and set to Automatic. If it's stopped, start it. If it won't start, check the System event log for error IDs 120 or 257 — those point to missing registry keys or corrupted database files.
Verify DHCP options — On your DHCP server, confirm that Option 066 (Boot Server Host Name) points to your WDS server's IP or hostname (use the IP for reliability). Option 067 (Bootfile Name) must be set to boot\x86\wdsnbp.com for BIOS clients or boot\x64\wdsnbp.efi for UEFI. If you're using RIS, it's OSCHOOSER\RIS.SIF. I've seen this error when someone typed boot\x64\wdsnbp.com instead of .efi for UEFI systems — double-check the architecture.
Test network connectivity from the client — On a machine that can reach the same subnet as the client, open Command Prompt and type telnet [WDS_IP] 69 (TFTP port). If it connects but the PXE client still fails, your firewall might be blocking port 4011 (BINL) or 135 (RPC for RIS). On Windows Firewall, create an inbound rule allowing UDP ports 67, 68, 69, 4011, and TCP port 135. On third-party firewalls, allow all traffic from the client subnet to the WDS server.
Restart the WDS service and clear cache — Run as admin: net stop wdsserver then net start wdsserver. On RIS, it's net stop remoteboot then net start remoteboot. After restarting, delete the C:\RemoteInstall\tmp folder contents (if it exists) to clear stale boot image references.
Check the BINL log on the server — On WDS, logs are in %windir%\tracing\wdsserver.log. Open it with Notepad. Look for lines containing BINL and 0X000009D0. A common entry is BINL: client request failed: could not open registry key for boot image. That means the boot image is missing from the WDS console. Right-click the image in WDS and select Replace to point to a valid install.wim.

Alternative Fixes

If the main steps don't work, try these:

Disable IPv6 on the WDS server — IPv6 can interfere with PXE broadcasts. On the server's network adapter properties, uncheck Internet Protocol Version 6 (TCP/IPv6). Restart WDS after.
Use a static IP for the WDS server — If your WDS server got a DHCP lease, the client may try to connect to the old IP after the lease renews. Set a static IP and update DHCP Option 066.
Reinstall the WDS role — This is drastic, but if the Remoteboot service won't start even after a reboot, uninstall the role, reboot, reinstall, and reconfigure. Back up your RemoteInstall folder first.

Prevention Tips

To stop this error from coming back:

Document your DHCP options and WDS boot file paths after every server migration or OS upgrade. I keep a text file in the RemoteInstall folder with the exact paths.
Monitor the WDS service with a simple scheduled task that checks if the service is running every 5 minutes and sends an alert if it's down. Use sc query wdsserver | find "RUNNING" in a batch file.
Test PXE boot from a known-good client after every Windows Update patch Tuesday — I've seen updates restart the WDS service and change the boot file path.