Fix RPC_NT_CANNOT_SUPPORT (0XC0020041) on Windows Server

When This Error Shows Up

You'll see RPC_NT_CANNOT_SUPPORT (0XC0020041) when a client machine tries to make a remote procedure call (RPC) to a Windows Server but the server refuses to process it. Common triggers: a domain controller trying to replicate across sites, a management tool like DHCP Manager or Active Directory Users and Computers connecting to a remote server, or a custom app using RPC for inter-process communication. The exact message reads: "The requested operation is not supported." It often happens after a firewall rule change, a Windows Update, or when mixing server versions — say a Server 2012 R2 client talking to a Server 2022 server.

What's Really Happening

RPC is the backbone for a lot of Windows admin tools. When your server gets this call, it first checks if the protocol sequence (like TCP/IP or named pipes) is allowed. Then it looks at the interface UUID (the unique ID for the function being called). If either isn't registered or isn't allowed by the server's RPC configuration, you get 0XC0020041. The server isn't saying "I'm busy" — it's saying "I don't know how to do that thing you're asking for." Most of the time, the root cause is one of three things:

1. Blocked port 135 — the RPC endpoint mapper. No mapper, no connection.
2. Protocol mismatch — the client asks for TCP/IP but the server only accepts named pipes, or vice versa.
3. Disabled or misconfigured DCOM — Distributed COM allows remote object creation. If it's off, many RPC calls fail.

The Fix — Step by Step

Step 1: Check Port 135 Accessibility

On the client machine, open a command prompt as Administrator. Run:

telnet your-server-ip 135

If Telnet isn't installed, use PowerShell:

Test-NetConnection -ComputerName your-server-ip -Port 135

What you should see: TcpTestSucceeded : True. If you see False, port 135 is blocked. Check Windows Firewall on the server — you need inbound rules for "Remote Service Management" or "COM+ Remote Access." Also check any hardware firewall between them. A common trap: the server's firewall profile switched to "Public" after a network cable change, blocking RPC. Set it back to "Domain" or "Private."

Step 2: Verify RPC Protocol Bindings on the Server

Open Registry Editor on the server (regedit.exe). Go to:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\ServerProtocols

What you should see: At minimum, keys for ncacn_ip_tcp and ncacn_np (named pipes). If ncacn_ip_tcp is missing, the server won't accept RPC over TCP/IP. To add it back, create a DWORD (32-bit) value named ncacn_ip_tcp with data 1. Restart the RPC service (rpcss) after any change. But here's the catch — you can't restart RPCSS without rebooting the whole server because it's tied to the service control manager. So just reboot after this registry fix.

Step 3: Enable DCOM

Open Component Services on the server. Press Win + R, type dcomcnfg, hit Enter. In the left pane, expand Component Services > Computers > right-click My Computer > Properties. Go to the Default Properties tab.

What you should see: "Enable Distributed COM on this computer" should be checked. If it's unchecked, check it. Set "Default Authentication Level" to Connect (not None). Set "Default Impersonation Level" to Identify. Click Apply, then OK. This doesn't need a reboot — the change takes effect immediately for new connections.

Step 4: Check the Client's RPC Binding Order

On the client machine (the one making the call), open registry:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\ClientProtocols

Make sure ncacn_ip_tcp is there with value 1. If it's missing, add it the same way as Step 2. The client might be trying to use a protocol the server doesn't support — this forces TCP/IP as an option. After adding it, reboot the client.

Step 5: Reset RPC Settings with a Script (If Nothing Else Worked)

Sometimes the registry gets corrupted by a bad update. On the server, run this PowerShell script as Administrator:

# Reset RPC ServerProtocols to defaults
$path = 'HKLM:\SOFTWARE\Microsoft\Rpc\ServerProtocols'
New-ItemProperty -Path $path -Name 'ncacn_ip_tcp' -Value 1 -PropertyType DWord -Force
New-ItemProperty -Path $path -Name 'ncacn_np' -Value 1 -PropertyType DWord -Force
New-ItemProperty -Path $path -Name 'ncacn_nb_tcp' -Value 1 -PropertyType DWord -Force
New-ItemProperty -Path $path -Name 'ncalrpc' -Value 1 -PropertyType DWord -Force
Write-Host 'RPC protocols reset. Reboot required.'

After running this, reboot the server. Then test the connection from the client again.

If the Error Persists

Check these less common causes:

• Service account permissions — the account calling the RPC might not have "Impersonate a client after authentication" user right on the server. Check Local Security Policy > Local Policies > User Rights Assignment.
• IPv6 mismatch — if the client uses IPv6 but the server has it disabled, RPC falls back to IPv4. But if the server has both disabled, you're stuck. Enable IPv6 on the server's network adapter.
• Antivirus interference — some AV software blocks RPC endpoints. Temporarily disable the AV on the server and test. If it works, add an exception for svchost.exe running the RPCSS service.
• Windows version incompatibility — I've seen this happen when a Server 2008 R2 tool tries to connect to Server 2022. The older tool uses an RPC interface that was deprecated. In that case, upgrade the client tool or use a different management method like PowerShell remoting (WinRM) instead.