Fix RPC_NT_NO_ENDPOINT_FOUND 0XC0020009

Getting the RPC_NT_NO_ENDPOINT_FOUND error (0XC0020009) is a special kind of annoying—it stops Outlook from connecting to Exchange, breaks RPC over HTTP, and generally makes you question your network. I've seen this on Windows Server 2022, Windows 10, and even some legacy 2012R2 boxes. The core problem? The RPC endpoint mapper on the server isn't responding where your client expects it. Let's kill this fast.

Direct Fix – Restart the RPC Endpoint Mapper

On the server (or the machine hosting the RPC service), open Services.msc as admin.
Find Remote Procedure Call (RPC). Its display name is just "Remote Procedure Call (RPC)". The service name is RpcSs.
Right-click it, select Restart. If it won't restart, check if it's stopped—set it to Automatic and start it manually.
While you're there, find RPC Endpoint Mapper (service name RpcEptMapper). Ensure it's running and set to Automatic.
On the client machine, flush DNS and clear the RPC cache. Open an admin Command Prompt and run:
```
ipconfig /flushdns
net stop rpcrt4
net start rpcrt4
```
The rpcrt4 service restart isn't always needed, but it forces the local RPC runtime to re-register endpoints.
Test connectivity from the client to the server on port 135 (TCP):
```
Test-NetConnection -ComputerName SERVER_IP -Port 135
```
If that fails, you've got a firewall or routing issue. Fix that before anything else.

Why This Fixes It

The error code 0XC0020009 means the client sent an RPC request to the server, but the server's endpoint mapper couldn't find a listening endpoint for the requested interface. The endpoint mapper runs on port 135—it's the directory that tells clients "this RPC interface is on port XXXX." If the RpcEptMapper service is dead or the RpcSs service is in a bad state, the mapper won't respond. Restarting both services forces a fresh registration of all RPC interfaces and opens the endpoint mapper socket again.

What's actually happening here is that the RPC runtime on the server has lost its internal state—maybe from a hung thread, a memory issue, or a dependency that crashed. Restarting the services is the cleanest way to reset that state. I've also seen cases where the server's firewall blocked port 135 temporarily after a Windows Update, which makes the mapper unreachable but doesn't log an obvious error—the Test-NetConnection catches that.

Less Common Variations

Outlook RPC Over HTTP

If Outlook shows 0XC0020009 when connecting to Exchange via RPC over HTTP, the fix above still applies—but also check that the RPC virtual directories in IIS (on the Exchange server) haven't been misconfigured. Run Get-RpcClientAccess in Exchange Management Shell to confirm the server is listed. If it's not, add it with Set-RpcClientAccess. This happened to me after a failed Exchange update that nuked the virtual directory bindings.

DCOM Application Errors

Some third-party apps (like backup software or management tools) use DCOM and hit this error. The symptom: the app logs 0XC0020009 when trying to launch a remote component. The fix is the same—restart RpcSs and RpcEptMapper on the remote server—but you also need to verify DCOM permissions are correct. Use dcomcnfg to check that the launching user has "Remote Launch" rights under Component Services > Computers > My Computer > COM Security.

IPv6 vs IPv4

I've seen one weird case: a server had IPv6 disabled, but the endpoint mapper was registered only on an IPv6 address. The client tried IPv4, got nothing. If you've disabled IPv6 on the server, re-enable it temporarily, restart RpcSs, and see if the error disappears. If it does, the real fix is to reconfigure the RPC interface to listen on IPv4—not easy, but you can force it by setting HKLM\SYSTEM\CurrentControlSet\Services\RpcSs\Parameters and adding a DependOnService value that includes AFD. (Yes, that's a hack. It works.)

Prevention

You won't see 0XC0020009 often if you keep a few things clean:

Don't disable the RPC services. I know some "performance tweaks" recommend stopping RpcSs—don't. Windows depends on it.
Monitor port 135 availability with a simple PowerShell script that pings the port every 5 minutes and logs failures. Put it on a scheduled task.
Keep Windows up to date but not bleeding edge. I've seen a cumulative update for Server 2022 (KB5022842) cause RPC endpoints to drop randomly. That got fixed in the next patch. Wait 30 days before deploying non-security updates.
Use static RPC port ranges if your firewall is strict. Set HKLM\SYSTEM\CurrentControlSet\Services\RpcSs\Parameters\Ports to a range like 5000-5100, then open those ports in the firewall. This stops the endpoint mapper from dynamic port allocation, which reduces the chance of port conflicts.

If you hit this error again after the fix, check the event log on the server for RPC-related events in System under source RpcSs or RpcEptMapper. You'll often see a warning like "The RPC endpoint mapper failed to register with the RPC service"—that tells you exactly which service is the problem.