Fix RPC_S_SERVER_UNAVAILABLE (0X000006BA)

When This Error Shows Up

You're trying to run a remote management tool—maybe dcomcnfg against a remote server, or wmic targeting a machine across the subnet—and instead of a connection, you get RPC_S_SERVER_UNAVAILABLE (0X000006BA). The dialog says something like "The RPC server is unavailable." On Windows Server 2022 and Windows 11, this often happens right after a firewall rule change or a reboot. Other common triggers: you moved a machine to a different VLAN, the remote server's RPC service crashed, or the DNS name resolves to the wrong IP.

What's Actually Happening

The RPC runtime on your local machine sends a request to the remote server's endpoint mapper (listening on TCP port 135). The mapper tells your client which dynamic port the target service is using for its actual communication. If port 135 is blocked, or the RPC service on the remote end isn't running, or the DNS entry points to a dead host, you get 0X000006BA.

This isn't some vague network hiccup. The error code is precise—it means the client couldn't even establish the initial contact. The reason is almost always one of these three things: a firewall blocking port 135, the RPC service (RpcSs) stopped, or a name resolution failure.

The Fix — Step by Step

Check if the remote RPC service is running. Use PowerShell or a remote console if you have another way in:
```
Get-Service -Name RpcSs -ComputerName TARGET-PC
```
If it's stopped, start it: Start-Service -Name RpcSs -ComputerName TARGET-PC. If you can't reach the machine any other way, you'll need to fix this locally or use iDRAC/iLO.
Verify DNS resolution. Open a command prompt and run:
```
nslookup TARGET-PC
```
Make sure the returned IP matches the machine's actual address. If it's stale or wrong, flush DNS (ipconfig /flushdns) or fix the DNS record. I've seen this trip up people who use DHCP leases that expire overnight.
Test TCP port 135 connectivity. On your client machine, run:
```
Test-NetConnection -ComputerName TARGET-IP -Port 135
```
If it says TcpTestSucceeded : False, the firewall is the culprit. On the remote server, check Windows Defender Firewall with Advanced Security. The rule you need is Remote Service Management (RPC-EPMAP)—it should be enabled for the appropriate profile (Domain, Private, Public).
Open the right firewall ports. RPC uses port 135 for the endpoint mapper, but the actual data flows on a dynamic port range (usually 49152–65535 on Windows Vista and later). If you're in a locked-down environment, you can configure a static RPC port range to make firewalling easier. Run this on the remote server:

Note: The next step requires a reboot. Plan accordingly.

netsh int ipv4 set dynamicport tcp start=50000 num=1000
netsh int ipv4 set dynamicport udp start=50000 num=1000

Then open ports 50000–51000 in your firewall for the target service's profile.

Restart the RPC services. On the remote machine, open Services.msc, find Remote Procedure Call (RPC) and RPC Endpoint Mapper. Restart both. They're interdependent, so do it in order: first RpcSs, then RpcEptMapper. After that, try your client connection again.
Check for DCOM permissions issues. If you're using DCOM tools, run dcomcnfg and navigate to Component Services > Computers > My Computer > Properties > COM Security. Ensure the remote user or machine account has Remote Access and Remote Launch permissions. This is a common gotcha in domain environments where the computer account doesn't have explicit rights.

What to Check If It Still Fails

If you've done all that and the error persists, look at these edge cases:

IPv6 vs IPv4 mismatch. If your network uses IPv4 but DNS returns an AAAA record, the RPC client might try IPv6 first and fail. Disable IPv6 on the client adapter temporarily to test.
Third-party security software. Symantec Endpoint Protection, McAfee, and CrowdStrike can block RPC traffic even if the Windows firewall seems open. Temporarily disable the AV's firewall component to test.
NetBIOS or SMB dependencies. Some older RPC calls rely on NetBIOS over TCP/IP. If you disabled NetBIOS or SMB on the remote machine, RPC might still fail. Enable NetBIOS for the adapter under Advanced TCP/IP settings.
Time skew. Kerberos authentication for RPC fails if the client and server clocks differ by more than 5 minutes. Sync both machines to the same NTP source.

That covers 95% of 0X000006BA cases. The rest are usually driver-level network issues (NIC offloading) or corrupt Winsock. A netsh winsock reset on the client can't hurt, but it's a last resort.