Fix 'Error 1722: The RPC server is unavailable' on Windows

The Error

You open Services, Event Viewer, or Device Manager against a remote machine — or run a sc command — and Windows stops you cold:

Error 1722: The RPC server is unavailable.

The machine is online. Ping works. But anything that touches RPC is dead. Here's how to track down the cause and fix it.

Root Cause

RPC (Remote Procedure Call) is the transport layer under virtually every Windows remote management tool. Error 1722 means the client side reached the wire but couldn't complete the handshake. Usually it's one of these:

• The Remote Procedure Call (RPC) service or RPC Endpoint Mapper is stopped on the target machine
• Firewall is blocking TCP port 135 (RPC Endpoint Mapper) or the dynamic RPC ports (49152–65535)
• The network adapter profile flipped from Private to Public, silently killing remote management rules
• DNS is returning the wrong IP, so RPC can't locate the endpoint — common in domain environments after a DHCP change
• A VPN reconnect or network change left a stale route to the target

Step 1 — Verify RPC Services Are Running on the Target

RDP or physically log into the target machine first. Then run:

sc query RpcSs
sc query RpcEptMapper

Both need to show STATE: 4 RUNNING. Stopped? Start them:

net start RpcSs
net start RpcEptMapper

If RpcSs refuses to start, the system is in a bad state. Open eventvwr → Windows Logs → System and filter on source Service Control Manager — there will be an event explaining why.

Step 2 — Check Windows Firewall Rules on the Target

Nine times out of ten, this is the problem. Run on the target machine:

# See which remote management rules are actually enabled
Get-NetFirewallRule -DisplayName "*Remote*" | Select DisplayName, Enabled, Profile

Three rule groups must be enabled:

• Remote Service Management (RPC)
• Remote Service Management (RPC-EPMAP)
• Windows Management Instrumentation (WMI-In)

Enable all of them in two commands:

Enable-NetFirewallRule -DisplayGroup "Remote Service Management"
Enable-NetFirewallRule -DisplayGroup "Windows Management Instrumentation (WMI)"

No PowerShell remoting access? Fall back to netsh:

netsh advfirewall firewall set rule group="Remote Service Management" new enable=Yes
netsh advfirewall firewall set rule group="Windows Management Instrumentation (WMI)" new enable=Yes

Step 3 — Verify Port 135 Is Reachable From Your Machine

From your workstation:

Test-NetConnection -ComputerName TARGET_HOSTNAME -Port 135

TcpTestSucceeded : False means a firewall is blocking the path — Windows Firewall, a hardware firewall, or a network ACL. RPC can't work until port 135 is open. Full stop.

While you're there, spot-check a couple of dynamic ports too:

Test-NetConnection -ComputerName TARGET_HOSTNAME -Port 49152
Test-NetConnection -ComputerName TARGET_HOSTNAME -Port 49153

Step 4 — Fix a Firewall Profile Mismatch

Windows keeps separate firewall rule sets for Domain, Private, and Public networks. Remote management rules apply only to Domain and Private. If a NIC flips to Public — which happens after a network change or DHCP hiccup — those rules vanish silently.

Check the current profile on the target:

Get-NetConnectionProfile

Seeing NetworkCategory: Public on a corporate LAN adapter? Fix it:

Set-NetConnectionProfile -InterfaceAlias "Ethernet" -NetworkCategory Private

Swap Ethernet for whatever interface name appeared in the output above.

Step 5 — Check DNS Resolution

RPC uses hostnames internally during endpoint lookup. A stale DNS record returning an old IP is enough to break everything, even with firewall and services healthy.

# From your machine
nslookup TARGET_HOSTNAME

# PowerShell alternative
Resolve-DnsName TARGET_HOSTNAME

Wrong IP or resolution failure? Either fix the DNS record, or connect directly by IP address instead of hostname. On the target, flush and re-register:

ipconfig /flushdns
ipconfig /registerdns

Step 6 — Enable WinRM If You're Using PowerShell Remoting

PowerShell remoting and WMI have their own transport layer on top of RPC. If the Windows Remote Management service is stopped, you get Error 1722 even when base RPC is fine.

# Quickest fix — run on the target machine
winrm quickconfig

# Or force-enable PS remoting
Enable-PSRemoting -Force

Verification

Back on your workstation, confirm everything is working:

# Port 135 test
Test-NetConnection -ComputerName TARGET_HOSTNAME -Port 135

# Query a remote service (Spooler is always present)
Get-Service -ComputerName TARGET_HOSTNAME -Name Spooler

# Old-school equivalent
sc \\TARGET_HOSTNAME query Spooler

Get-Service returning results without throwing? RPC is alive. You can also open services.msc → right-click the root node → Connect to another computer → enter the hostname. Service list loading means you're done.

Quick Checklist for Production

• Target reachable? — ping, then Test-NetConnection -Port 135
• RPC services running? — sc query RpcSs and sc query RpcEptMapper
• Firewall rules enabled? — Remote Service Management group
• Network profile correct? — Domain or Private, never Public on a corp adapter
• DNS resolving correctly? — nslookup TARGET_HOSTNAME should return the right IP
• VPN or recent network change? — reconnect VPN or restart the adapter

If the Target Is Across a Subnet

Before blaming RPC, rule out basic routing issues. When your management workstation sits on a different VLAN than the target — common in segmented server environments — you need to confirm IP routing is actually in place. I use the Subnet Calculator on ToolCraft to verify CIDR ranges quickly and confirm both machines are on the same subnet or that a route exists between them. Runs entirely in the browser, nothing leaves your machine.

Prevention

• Push a GPO to enforce Remote Service Management and WMI firewall rules on all servers — local config drifts; policy doesn't
• Alert on RpcSs and RpcEptMapper service state in your monitoring stack — both services stopping is a known side effect of botched service dependency changes
• If your firewall can't handle dynamic port ranges, pin RPC to a fixed range: set HKLM\Software\Microsoft\Rpc\Internet with a defined port range (e.g., 50000–50100) and open only those ports
• Document the intended firewall profile for every network adapter on your servers — a NIC silently switching to Public is a recurring silent killer