Fix NERR_RPL_CONNECTED (0X000009D7) on Windows Networks

What's Happening Here

You're trying to map a network drive or connect to a shared folder, and Windows throws up NERR_RPL_CONNECTED (0X000009D7) — "A second connection to a Remoteboot resource is not allowed." I know this error is infuriating because it's vague and stops you dead. It's not about actual Remoteboot (PXE boot) 99% of the time. It's a classic Windows networking quirk: you've already got a connection to that same share under a different user credential, or you've hit the hidden SMB client limit for connections to one server. This tripped me up the first time too, especially when mapping drives with different logins.

The fix is straightforward once you know what's causing the block. Let's clear it out.

Fix 1: The 30-Second Win — Disconnect the Duplicate

Most of the time, this error means you've got an existing connection to the same share or server using different credentials. Windows, by default, allows only one set of credentials per server per session. You might not even see the old connection in File Explorer if it's hidden or broken.

1. Open a Command Prompt as Administrator. (Hit Start, type cmd, right-click and pick "Run as administrator".)
2. Type net use and press Enter. This lists all active network connections.
3. Look for any connection to the server you're targeting. It might use a different drive letter, or none at all (disconnected but still cached).
4. If you see one, delete it: net use * /delete (this removes all connections) or net use X: /delete (replace X with the drive letter).
5. Now try mapping your drive again.

That's the fix. I'd guess it resolves 80% of cases. But if the error persists, the connection might be persistent across reboots.

Fix 2: The 5-Minute Deep Clean — Kill Persistent Mappings

Persistent connections survive reboots and often hide from net use listings. They're stored in the registry and can latch onto credentials you've long forgotten. Here's how to nuke them properly.

1. Open Command Prompt as Administrator again.
2. Run net use * /persistent:no — this tells Windows not to reconnect anything automatically going forward.
3. Then run net use * /delete again. If some refuse to delete, reboot into Safe Mode with Networking and repeat.
4. Alternatively, clear the stored credentials in Credential Manager: go to Control Panel > User Accounts > Credential Manager > Windows Credentials. Look for anything under "Windows credentials" that matches the server name or IP address. Remove it.
5. Reboot and remap the drive fresh.

This clears the ghost connections that keep triggering the error. I've seen this happen after someone mapped a drive with one account, then tried to map a different share on the same server with another account. Windows treats them as the same session and blocks the second.

Fix 3: The 15+ Minute Fix — Registry Surgery (Advanced)

If you're still stuck, there's a registry tweak that increases the connection limit per session. This is rare but fixes edge cases with legacy software or odd SMB configurations. I'd only do this if the first two fixes failed.

1. Open Regedit as Administrator.
2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management.
3. Create a new DWORD (32-bit) value named PoolTag if it doesn't exist (case-sensitive). Set it to 0.
4. Next, go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters.
5. Create a DWORD named MaxMpxCt (if not already there) and set it to 255 (decimal). This raises the maximum number of outstanding network requests per session from the default of 50.
6. Then, on the client side (the machine where you're getting the error), go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters.
7. Create a DWORD named MaxCmds and set it to 255 (decimal).
8. Reboot both the server and client.

This is overkill for most home users but occasionally required in corporate environments where one server hosts multiple shares for the same user across different applications. I once had to do this on a Windows Server 2008 box serving file shares to a legacy ERP system.

When None of These Work

If you're still seeing the error, check if the server is using a different hostname or IP. For example, if you connected via \192.168.1.10\share and now try \server-name\share, Windows might see them as different connections but the server sees them as the same resource. Stick to one naming convention. Also, verify you're not hitting a server-side Remoteboot service (rare, but possible in older NT setups). In that case, you'd need to disable the Remoteboot service on the server or use a different protocol like WebDAV.

One last thing: if you're on a Windows 10 or 11 machine that was upgraded from an earlier version, the registry paths might still hold old connection data. A clean network reset (Settings > Network & Internet > Status > Network reset) can help, though it's a sledgehammer for a fly.