"The RPC server is unavailable" (1722, 0x800706BA): causes and fixes

“The RPC server is unavailable” is Windows error 1722, shown as 0x800706BA by PowerShell and most management tools. It means the computer that shows it could not reach the RPC service it needed on the other machine: TCP port 135, or the dynamic port that service uses, is blocked, the name points at the wrong address, or nothing answers there. In most cases the cause is the network path (a firewall rule or name resolution), not a broken RPC service. Start with two lines on the computer that shows the error:

Resolve-DnsName server01                    # is this the address the target really has?
Test-NetConnection server01 -Port 135       # TcpTestSucceeded : True = the endpoint mapper answers

Replace server01 with the target’s name or IP address. The same error turns up in several wordings, depending on the tool:

The RPC server is unavailable.

Get-WmiObject : The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)

[SC] OpenSCManager FAILED 1722:

The RPC server is unavailable.

The RPC server is unavailable. 0x800706ba (WIN32: 1722 RPC_S_SERVER_UNAVAILABLE)

Event Viewer’s “Connect to Another Computer”, Computer Management and the Services console show the same sentence in a dialog; printer dialogs show the code as 0x000006BA, which often means the Print Spooler service on the print server is not running. All of them are the one error below.

Why does RPC fail when the server is up?

Because RPC needs two connections, not one. The client first asks the RPC endpoint mapper on TCP port 135 which port the service it wants (WMI, the event log, the service manager) is listening on. The answer is a port from the dynamic range, which Microsoft set to 49152 to 65535 in Windows Server 2008 and later. The client then opens a second connection to that port. Some interfaces travel over named pipes on SMB, port 445, instead. If any of these steps fails, the client reports that the RPC server is unavailable, even though the machine is running.

That explains the two most confusing cases. A firewall that allows port 135 but not the dynamic range still produces the error. And Remote Desktop keeps working while every management tool fails, because RDP uses port 3389 and no RPC at all, as the RDP port guide explains.

Which ports and services does your tool need?

The last row is the useful one: the CIM cmdlets and PowerShell remoting go over WinRM, a single fixed port. A script that fails with 0x800706BA under Get-WmiObject often works with Get-CimInstance against the same server, and when WinRM is blocked it fails with a WinRM error instead of this one.

How do I find where the call fails?

Work through the path from the computer that shows the error, in this order:

• The name. Resolve-DnsName server01 must return the address the target really has (check with ipconfig on the target). If the IP address works and the name does not, the problem is DNS or a hosts file, covered below.
• Port 135. Test-NetConnection server01 -Port 135. From Linux or macOS, nc -vz 203.0.113.10 135 does the same. If this fails, the endpoint mapper is not reachable at all: a firewall on the target or in between, or the wrong address.
• The dynamic port. Microsoft’s free PortQry tool asks the endpoint mapper for its list. Lines of the form ncacn_ip_tcp:<address>[<port>] name the ports the registered services listen on; test one of them the same way.

portqry -n server01 -e 135            # lists the endpoints registered with the endpoint mapper
Test-NetConnection server01 -Port 49668   # a port from that list (49668 is only an example)

PortQry reports a port as LISTENING, NOT LISTENING (the target refused it) or FILTERED (no answer at all, the signature of a firewall). Microsoft documents the tool and its download in Using the PortQry command-line tool. Read the result like this:

Is Windows Firewall on the target blocking it?

This is the most common cause. Windows Firewall has a built-in rule group for each remote management feature, and those groups know which program owns the dynamic port, so you do not have to open the whole range. Check the group your tool needs, then enable its inbound rules for your own address only. Run this on the target, over RDP or in the console:

$g = 'Windows Management Instrumentation (WMI)'     # or another group from the table
Get-NetFirewallRule -DisplayGroup $g -Direction Inbound | Format-Table DisplayName, Profile, Enabled

# enable the inbound rules, limited to the address you manage from
Get-NetFirewallRule -DisplayGroup $g -Direction Inbound |
  Set-NetFirewallRule -Enabled True -RemoteAddress 198.51.100.7

In cmd, netsh advfirewall firewall set rule group="Windows Management Instrumentation (WMI)" new enable=yes switches the same group on, for every address. On a non-English Windows the group names are translated; (Get-NetFirewallRule).DisplayGroup | Sort-Object -Unique lists them as your system spells them.

For a tool without a rule group of its own, Windows Firewall has two keywords for RPC that stand in for the port numbers: RPCEPMap is the endpoint mapper on 135, and RPC is the dynamic range. These two rules open RPC for every service, so keep them to your address:

New-NetFirewallRule -DisplayName 'RPC endpoint mapper, admin only' -Direction Inbound -Protocol TCP -LocalPort RPCEPMap -RemoteAddress 198.51.100.7 -Action Allow
New-NetFirewallRule -DisplayName 'RPC dynamic ports, admin only' -Direction Inbound -Protocol TCP -LocalPort RPC -RemoteAddress 198.51.100.7 -Action Allow

Does the rule apply to the network profile in use?

A rule only works in the profiles it is set for: Domain, Private or Public. Check which one the server’s network has, then compare it with the Profile column from the command above:

Get-NetConnectionProfile | Format-Table InterfaceAlias, NetworkCategory

• Public on a server with a public IP address is correct, and so is a rule that is enabled only for Domain doing nothing there. Scope the rule to your address rather than switching the network to Private.
• A domain member showing Public or Private could not reach a domain controller when it identified the network, so the Domain rules stopped applying. Fix the connection to the domain controller (DNS first), then restart the NlaSvc service or the server.

Does the name lead to the right machine?

If the call works by IP address and fails by name, the name resolves to the wrong place: a DNS record left over from an old address, an entry in a hosts file, or an IPv6 address that the firewall does not allow while IPv4 would work.

Resolve-DnsName server01                     # A and AAAA records; compare with the target's ipconfig
Get-Content $env:SystemRoot\System32\drivers\etc\hosts | Select-String server01
ipconfig /flushdns                           # after fixing the record, drop the cached answer

In a domain, connecting by IP address also changes the authentication from Kerberos to NTLM, so a test by IP is a quick way to separate a name problem from a network problem. Fix the record afterwards rather than keeping the IP address in scripts.

Are the RPC services running on the target?

Get-Service RpcSs, RpcEptMapper, DcomLaunch | Format-Table Name, Status, StartType
Get-Service Winmgmt, EventLog, Schedule, Spooler | Format-Table Name, Status, StartType

The first three are the Remote Procedure Call service, the RPC Endpoint Mapper and the DCOM Server Process Launcher. They must be Running and Automatic, and Windows does not let you restart them while it runs: if one is stopped, restart the whole server. The second line covers the services behind the tools in the table. Start the one your tool needs, for example Start-Service Spooler for printing or Restart-Service Winmgmt -Force for WMI. A tool that reads the registry remotely also needs the RemoteRegistry service, which hardened servers often keep disabled.

Is DCOM switched off, or is the account refused?

WMI and other DCOM-based tools stop working if DCOM is disabled on either side. Microsoft’s support article on error 0x800706ba during certificate enrollment names the registry value to check; it must be Y, and a change takes effect after a restart:

Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Ole' -Name EnableDCOM      # EnableDCOM : Y
Set-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Ole' -Name EnableDCOM -Value 'Y'   # only if it says N, then restart

The same article describes a case that looks like a network fault but is a permission problem: when the account is not allowed to log on over the network (the user rights Access this computer from the network and Deny access to this computer from the network), authentication drops to an anonymous logon, DCOM refuses it, and the client still reports 0x800706BA. On the target, look for DistributedCOM warnings in the System log and check the user rights in secpol.msc or with gpresult /h C:\gp.html.

Are the clocks far apart?

In a domain, Kerberos rejects tickets when two clocks differ by more than the allowed tolerance, five minutes by default. Check the time whenever the RPC error comes together with logon or Kerberos failures, typically on domain joins and between domain controllers:

w32tm /query /status                                   # source and last successful sync
w32tm /stripchart /computer:server01 /samples:3 /dataonly   # offset to the other machine
w32tm /resync                                          # sync now

For replication between domain controllers, Microsoft keeps a separate article on Active Directory replication error 1722, which goes through the domain-specific checks.

Does a firewall in between only let port 135 through?

If port 135 answers and the dynamic ports are filtered, a firewall outside Windows (your office’s, a cloud security group or a router) allows the endpoint mapper but not the second connection. You can open the dynamic range on that firewall for your address only; netsh int ipv4 show dynamicport tcp on the target shows the range it uses. For WMI there is a narrower option: Microsoft documents how to move it to a fixed port, 24158, so that 135 and one more port are enough:

winmgmt -standalonehost
net stop winmgmt
net start winmgmt

Answer Y if net stop lists dependent services. Then allow the fixed port from your address only, and undo the change later with winmgmt /sharedhost followed by another stop and start of the service:

New-NetFirewallRule -DisplayName 'WMI fixed port, admin only' -Direction Inbound -Protocol TCP -LocalPort 24158 -RemoteAddress 198.51.100.7 -Action Allow

How do I manage a Windows VPS without exposing RPC?

On a Windows VPS you rent, Remote Desktop works from home while Event Viewer, Computer Management or a WMI script pointed at the server report that the RPC server is unavailable. If the rule groups for those tools are not enabled, or not for the Public profile, Windows Firewall drops the connections, and on a server with a public address that is the right result. Instead of opening RPC to the internet:

• Run the tool on the server. Event Viewer, the Services console and Get-CimInstance work locally inside the RDP session with no extra ports.
• Use a VPN. Connect your PC and the server through a tunnel and allow RPC only from the tunnel’s addresses. Putting RDP behind a VPN covers the same pattern for Remote Desktop, and a WireGuard server is the simplest tunnel to run.
• Use PowerShell remoting. WinRM over HTTPS on port 5986 (it needs an HTTPS listener with a certificate), allowed only from your address, replaces most of what WMI over DCOM was used for, with one port to manage.

If the error appears between two servers you own in the same location, the rule-group approach above, scoped to the other server’s address, is the clean fix. How to write and test such rules is in opening a port in Windows Firewall. The open port checker shows from outside whether 135 or 445 is reachable on your server, which it should not be.

Frequently asked