Fix NERR_CantConnectRplSrvr (0X000009D1) Remote boot error

The 30-second fix: Check the Remote Boot Server service

What's actually happening here is your client machine sent a boot request, but the server never answered. The first thing to check — and I can't tell you how many times this was the issue — is whether the Remote Boot Server service is even running.

1. On your boot server, open Services (press Win+R, type services.msc, hit Enter).
2. Scroll down to Remote Boot Server (sometimes listed as Remote Installation Services or Windows Deployment Services depending on your Windows version).
3. Look at the Status column. If it says Stopped, right-click it and select Start.
4. Set the Startup Type to Automatic so it starts after a reboot.

Why does this work? The Remote Boot Server service is the actual listener that processes boot requests from clients. If it's not running, the server can't respond. Simple as that. I've seen admins spend an hour tweaking DHCP options when the real fix was clicking "Start" in a services window.

If the service fails to start, check the System event log for error details. Common causes: missing dependencies (like the Event Log service or RPC service), or the service account doesn't have the right permissions.

The 5-minute fix: Firewall and DHCP options

Still stuck? The service is running, but the client can't reach it. Two things to check: the firewall and the DHCP options. Let me walk through each.

Check the firewall on the boot server

The Remote Boot Server listens on UDP port 67 (DHCP) and UDP port 4011 (PXE boot). Yes, it uses DHCP ports — the boot server is basically a specialized DHCP server. If those ports are blocked, your client won't get a response.

# Quick PowerShell check — list inbound firewall rules for port 67
Get-NetFirewallRule | Where-Object { $_.LocalPort -eq "67" } | Format-Table Name, Enabled

If you see nothing, you need to add a rule:

1. Open Windows Defender Firewall with Advanced Security.
2. Click Inbound Rules → New Rule.
3. Select Port, then UDP, and enter 67, 4011 for the local ports.
4. Allow the connection, apply to all profiles (Domain, Private, Public).
5. Name it something obvious like "Remote Boot Server ports".

Don't use a third-party firewall? Same concept — open those two UDP ports inbound.

Verify DHCP option 60

Here's the part most people miss. The client needs DHCP option 60 set to PXEClient for remote boot to work. If you're using a separate DHCP server (not the boot server itself), you must configure this option.

1. Open DHCP management console on your DHCP server.
2. Go to Server Options or Scope Options.
3. Add Option 60, set the value to the string PXEClient (case-sensitive).

The reason step 3 works is that the PXE boot ROM in the client's network card looks for this specific option to identify the boot server. Without it, the client won't even attempt to connect to the RPL server.

The 15+ minute fix: Registry tweak and service repair

If you're still getting 0X000009D1 at this point, something deeper is broken. Let's dig into the registry and verify the service configuration isn't corrupted.

Registry check for RPL service

The Remote Boot Server service stores its settings in the registry. A common corruption is the ImagePath value pointing to a missing executable.

# Path for Remote Boot Server (RPL) service
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RplSrv

Look at the ImagePath value. For a standard installation, it should point to %SystemRoot%\System32\rplsvc.exe. If it's blank or points somewhere invalid, that's your problem.

To fix it:

1. Open Registry Editor (regedit) as Administrator.
2. Navigate to that key.
3. Double-click ImagePath and set it to %SystemRoot%\System32\rplsvc.exe.
4. Restart the service or reboot the server.

Re-register the service DLL

If the registry looks fine, the RPL service might have a corrupted DLL registration. Run these commands in an elevated command prompt:

regsvr32 /u %SystemRoot%\System32\rplsvc.dll
regsvr32 %SystemRoot%\System32\rplsvc.dll

The /u flag unregisters it first, then the second command re-registers it. I've seen this fix a "service failed to start" error that showed up as 0X000009D1 on clients.

Verify network bindings and adapter

This one's rare, but worth checking if your server has multiple network adapters. The boot server binds to a specific interface. If that adapter lost its IP or went down, the service won't respond.

1. Open Network Connections (ncpa.cpl).
2. Right-click the adapter the boot server should use → Properties.
3. Check that Internet Protocol Version 4 (TCP/IPv4) is enabled and has a static IP.
4. Run ipconfig and confirm the IP matches what you expect.

If the adapter shows an APIPA address (169.254.x.x), your boot server has no valid IP — and that's why clients can't connect.

When nothing works: Event log deep dive

Before you give up, look at the System event log on the boot server. Filter by source RplSrv or WDS. The event details often reveal the root cause.

Common events:

If you see Event ID 202, run netstat -anob | findstr :67 to see which process owns port 67. If it's not the RPL service, you have a port conflict. Stop the other service or change its port.

That's it. Start with the service check, move to firewall and DHCP options, then the registry and DLL. One of these will get you past error 0X000009D1.