Fix: RPC Server is Unavailable Error Code 1722

This article is a troubleshooting guide for RPC Unavailable error 1722 in various cases.

What Does RPC Error 1722 Mean?

The RPC Server Unavailable (RPC_S_SERVER_UNAVAILABLE) error code 1722, indicates that a Windows client device is having a problem communicating with a remote server via the RPC (Remote Procedure Call) protocol.

Keep in mind that RPC error 1722 is often a secondary symptom rather than the root cause. In many cases, the actual problem is related to DNS, authentication, firewall filtering, replication, or service dependencies.

Common Causes of RPC Unavailable Error

The most common causes of RPC connectivity errors are:

• Disabled RPC service
• Incorrect name resolution (including misconfigured DNS)
• Network connectivity issues
• Firewall rules that block RPC traffic

Troubleshooting the RPC Unavailable Error 1722 in Windows

Let’s start with the basic checks needed to troubleshoot the cause of RPC errors for nearly any service.

Step 1. Check RPC Services

Open the Services management snap-in (services.msc) on the RPC server you want to connect to, and check that the required services are running and configured to start automatically.

• Remote Procedure Call (RPC);
• RPC Endpoint Mapper;
• DCOM Server Process Launcher;

You can also use PowerShell to check the status of services:

Get-Service RpcSs,RpcEptMapper,DcomLaunch

Step 2. Test Basic Network Connectivity and DNS Resolution

Use the ping/tracert commands or PowerShell networking cmdlets to confirm the client can reach the RPC server by its hostname and IP address:

ping srv1
# Powershell
Test-Connection srv1

tracert srv1
# Powershell
Test-NetConnection srv1 -TraceRoute

Use the nslookup command or Resolve-DnsName PowerShell cmdlet to verify if the server’s hostname is resolved correctly:

nslookup [rpc-server-name]
# Powershell
Resolve-DnsName [rpc-server-name]

Try resetting the client’s DNS cache:

ipconfig /flushdns

Validating Kerberos Authentication

Keep in mind that RPC communication often relies on Kerberos authentication in AD environments.

You can check existing tickets with CMD:

klist

In order to purge cached tickets, run the command:

klist purge

To resynchronize client time, use the command:

w32tm /resync

Kerberos authentication may fail in case the client and DC clocks differ by more than 5 minutes.

Validate Domain Secure Channel

For domain-joined computers, you should check that the secure channel with AD is healthy:

Test-ComputerSecureChannel -Verbose

Repair in case it’s needed. Use the command:

Test-ComputerSecureChannel -Repair -Credential (Get-Credential)

Note that a broken secure channel can cause RPC authentication failures even when network connectivity is functioning correctly.

Step 3. Test RPC Port Connectivity

The Remote Procedure Call (RPC) protocol is based on a client-server model. In order for a client to connect to an RPC server, the following outgoing network ports must not be blocked by firewalls:

• TCP port 135 – this port is used by the RPC Endpoint Mapper (RpcEptMapper) service, which allows clients to query the RPC server to find the dynamic port used by the specific service.
• Dynamic RPC port range (TCP 49152–65535) – these are the dynamic (ephemeral) ports used by RPC services for communication, once the client has obtained the port number from the RPC Endpoint Mapper.

How RPC Endpoint Mapping Works

Keep in mind that RPC clients do not connect directly to the target service port. The connection process looks like this:

1. Client connects to TCP 135 (RPC Endpoint Mapper)
2. Endpoint Mapper returns the dynamic port assigned to the service
3. Client establishes a second connection to that dynamic RPC port

Here is an example:

Client
↓ TCP 135
RPC Endpoint Mapper
↓ returns TCP 49666
Client
↓ TCP 49666
Target RPC Service

Because of this behavior, it is not sufficient to open only TCP 135. Note that also you need to allow the dynamic RPC port range through internal firewalls.

To check if RPC firewall rules are enabled, use the command:

Get-NetFirewallRule -DisplayGroup "Remote Procedure Call*" |
Select-Object DisplayName, Enabled, Direction

Tip. In case Windows Defender Firewall rules appear correct but RPC traffic is still being blocked, you need to enable firewall logging to identify dropped packets. Use the command:

netsh advfirewall set currentprofile logging droppedconnections enable

Review the log file here after enabling logging:

%systemroot%\System32\LogFiles\Firewall\pfirewall.log

You can also list configured firewall rules:

netsh advfirewall firewall show rule name=all

or use PowerShell command:

Get-NetFirewallRule

Admins often restrict the default dynamic RPC port range using Group Policy/registry settings in hardened enterprise environments. In this case, you must ensure that the custom RPC range is allowed through internal firewalls.

In hardened environments, you can customize the dynamic RPC endpoint range through Windows RPC config (for example, registry settings under HKLM\SOFTWARE\Microsoft\Rpc\Internet) or other enterprise management mechanisms. When troubleshooting RPC connectivity, you should always check if a custom endpoint range is configured and ensure that the same range is allowed through internal firewalls.

By default, modern Windows versions use the TCP port range 49152–65535 (for both ephemeral client ports and RPC dynamic endpoints). You can view the current TCP dynamic port range with CMD:

netsh int ipv4 show dynamicport tcp

Check if port 135 is listening on the RPC server computer (in modern Windows environments, we recommend you to use PowerShell cmdlets as preferred check).

Get-NetTCPConnection -State Listen -LocalPort 135

Get-Process -Id (Get-NetTCPConnection -LocalPort 135).OwningProcess

You can also inspect listening ports and owning processes using PowerShell command:

Get-NetTCPConnection -State Listen |
Sort-Object LocalPort

In order to verify DNS resolution, ICMP reachability, and TCP/135 connectivity to the RPC server, you should use Test-NetConnection PowerShell cmdlet from a client machine:

Test-NetConnection lon-dc01 -Port 135

Use the built-in rpcping.exe command to test Remote Procedure Call (RPC) connectivity between a client and an RPC server:

rpcping -s <hostname_name_or_ip>

For a more explicit RPC over TCP test, you can specify the protocol sequence via CMD:

rpcping -s srv1 -t ncacn_ip_tcp -u 10 -a connect

You can also use the legacy PortQry utility (PortQry Command Line Port Scanner) to troubleshoot RPC connectivity and check if the required RPC ports are accessible. It is an old but still useful troubleshooting utility for diagnostics. It can be useful when you are troubleshooting endpoint mapper responses and RPC endpoint registration. Note that PortQry is a standalone Microsoft troubleshooting utility and is not installed with Windows by default.

Check that the RPC port mapper is responding on the remote computer:

portqry -n <problem_server> -e 135

The following command displays registered RPC interfaces and endpoints. In case the required service endpoint is missing, the service may not have registered successfully with the RPC subsystem.

The rpcdump utility is not included with Windows by default. If it is available in your environment, you can use it to inspect registered RPC endpoints. To query the RPC Endpoint Mapper directly, use the command from CMD:

rpcdump /s <server>

In this example, the RPC Port Mapper service listens on TCP port 135. A list of running RPC endpoints, along with the ports associated with them (in square brackets), is also returned by the service.

Check whether the service you are troubleshooting is on this list. Ensure that the TCP port assigned to your service is not being blocked by any firewalls between the client and the server.

portqry -n <problem_server> -p tcp -e 49666

If the connection is blocked, open the required ports in the firewall or temporarily disable it to test whether it is blocking RPC traffic.

Note that in enterprise environments, RPC connectivity problems are often caused by incorrect DNS records, stale AD replication metadata/broken secure channel communication between domain members.

Test WMI/CIM Remote Management Connectivity

Note that RPC errors commonly occur during remote WMI/CIM management. This includes PowerShell remoting, monitoring systems, inventory tools, and admin scripts.

Most of the modern Windows environments use CIM (Common Information Model) cmdlets. For example, to test remote CIM connectivity to the target computer, use the command:

Get-CimInstance Win32_OperatingSystem -ComputerName srv1

In case the RPC subsystem, firewall rules, authentication, or DCOM permissions are misconfigured, you may face RPC-related errors.

You can also test legacy WMI connectivity using:

Get-WmiObject Win32_OperatingSystem -ComputerName srv1

Note that Get-WmiObject is deprecated in modern PowerShell versions and is kept mainly for backward compatibility. We recommend you using Get-CimInstance instead.

In case CIM/WMI queries fail with RPC errors, verify that:

• RPC/DCOM ports are accessible
• Windows Defender Firewall allows WMI traffic
• The Windows Management Instrumentation (Winmgmt) service is running
• Remote Administration firewall rules are enabled
• DCOM permissions are configured correctly

Validating DCOM Config

First, you need to check if DCOM is enabled on the target machine. Run the command via CMD:

dcomcnfg

Now navigate to Component Services → Computers → My Computer → Properties → Default Properties.

You need to ensure that:

• Enable Distributed COM on this machine is enabled
• Default Authentication Level is Connect
• Default Impersonation Level is Identify/higher

Note that misconfigured DCOM settings may cause RPC-related WMI failures.

Enterprise note. In hardened environments, Group Policy settings such as Restrict unauthenticated RPC clients may prevent certain legacy/anonymous RPC calls. Although this policy does not normally cause the classic 1722 (RPC Server Unavailable) error, it can result in RPC authentication failures for apps/management tools that rely on unauthenticated RPC access.

Note that modern PowerShell remoting primarily uses WinRM (HTTP/HTTPS over ports 5985/5986) instead of classic RPC/DCOM communication. However, many legacy management tools, MMC snap-ins, WMI queries, and AD operations still rely on RPC connectivity.

Troubleshoot RPC with PowerShell

Many of the modern Windows Server environments rely on PowerShell-based networking and remote management diagnostics (instead of legacy CMD tools). Here are some useful PowerShell troubleshooting commands:

Resolve-DnsName srv1

Test-Connection srv1

Test-NetConnection srv1 -Port 135

Test-NetConnection srv1 -TraceRoute

Get-NetTCPConnection -LocalPort 135

Get-Service RpcSs,RpcEptMapper,DcomLaunch

Test-WSMan srv1

Get-CimInstance Win32_OperatingSystem -ComputerName srv1

Specific errors “1722: The RPC server is unavailable”

Next, let’s look at specific errors “1722: The RPC server is unavailable”, which can be caused by various network services.

Active Directory Replication Error 1722: RPC_S_SERVER_UNAVAILABLE

If the domain controller is unable to establish a connection with a replication partner in accordance with the AD topology, you may face the Error 1722: The RPC server is unavailable on a DC.

You can start with a general DC health check through CMD:

dcdiag /q

In case you need a detailed report, run the command:

dcdiag /v

This helps you to identify DNS, replication, authentication, and service-related problems before you dig into deeper RPC troubleshooting.

In order to check time sync between DCs, use CMD:

w32tm /query /status

To force syncing, run the command from CMD:

w32tm /resync

Keep in mind that Kerberos authentication failures caused by clock skew can prevent successful replication and generate RPC-related errors.

Use the Repadmin or dcdiag tool to check the current replication status in Active Directory:

repadmin /replsummary

Or:

repadmin /showrepl

The replication generated an error (1722):

The RPC server is unavailable.
[lon-dc01] DsBindWithSpnEx() failed with error 1722.

Verify that DC SRV records are correctly registered in DNS.

You can do this with CMD:

nslookup -type=SRV _ldap._tcp.dc._msdcs.theitbros.com

Or with PowerShell command:

Resolve-DnsName _ldap._tcp.dc._msdcs.theitbros.com -Type SRV

Note that missing/stale SRV records can prevent DCs from locating replication partners.

Hint. Error 0x800706BA is simply the HRESULT version of Win32 error 1722 (RPC_S_SERVER_UNAVAILABLE). Different Windows tools report the same RPC error using different formats.

Typical reasons for the 1722 AD replication error

1. The domain controller is offline (or broken);
2. Some of the domain controller system services are not running;
3. Incorrect network configuration and/or blocked ports on firewalls;
4. Incorrect DNS configuration on DCs, or invalid entries in the primary DNS domain zone;
5. Poor network performance and/or high latency.

To check DFSR Event Logs on DCs, go to Event Viewer → Applications and Services Logs → DFS Replication. Here you need to look for SYSVOL replication failures and staging issues.

Tips

• Make sure the target domain controllers are powered on and running the following Windows services:
  

  Get-Service EventSystem, RpcSs,NTDS, Dnscache, Dns, DFSR, IsmServ, Kdc, SamSs, LanmanServer, LanmanWorkstation,W32Time, Netlogon

  
• Test the basic network connectivity between the healthy and problematic domain controllers.
• Ensure you can access the shared SYSVOL and NETLOGON folders using the UNC path (\\lon-dc01)
  

• A common cause of the 1722 replication error is the incorrect DNS configuration on the DC. Check if the correct DNS servers’ IP addresses are specified in the DC network connection settings. The Preferred DNS server should typically point to another healthy DC in the same AD site. Depending on the environment design, the alternate DNS server may point to another DC or to the local DC itself.
  
• Check the DNS health on a problem DC with the dcdiag tool:

  dcdiag /test:dns /v

If SYSVOL or NETLOGON access is failing, you need to check if SMB connectivity to the DC is working and that the required SMB firewall rules are allowed. You can test access to the SYSVOL and NETLOGON shares with the following commands:

Test-Path \\dc01\SYSVOL
Test-Path \\dc01\NETLOGON

You can also check the SMB server config with:

Get-SmbServerConfiguration | Select-Object EnableSMB2Protocol

Once you have resolved the RPC connectivity issues on the DC, force replication using the repadmin /replsummary command. Then run the dcdiag /a /q command and check that it its return no errors.

Hint. Rebooting the domain controller can often fix missing DC entries in DNS, and resolve problems with Netlogon and Sysvol services.

RPC Error 1722 When Request a Certificate from a Certificate Authority

The RPC Server Unavailable error often occurs when a domain client cannot enroll a certificate from the internal Certificate Authority (CA) running on Windows Server:

The certificate request could not be submitted to the certification authority. Error: The RPC server is unavailable. 0x800706ba (WIN32: 1722 RPC_S_SERVER_UNAVAILABLE)

First, test the RPC connectivity between the client and the Windows Server host running CA (as described above).

Use the built-in certutil command to test the connectivity and availability of your CA server from a client.

certutil -config FQDN_CAName -ping

Then, it’s necessary to verify that the resulting local CA policies allow this client to authenticate through the RPC interface:

1. Open the resulting Group Policy settings on the CA server by running the rsop.msc command.
2. Expand Computer Configuration > Windows Settings > Local Policies > User right Assignments.
3. Ensure that Authenticated Users and any required admin groups are granted the Access this computer from the network right.
   

   

4. The “Deny access this computer from the network” policy must not be configured.
   

   

5. Then check the DCOM service permissions on the CA host as described here.

Modern deployments. Some Microsoft workloads no longer rely on direct RPC connectivity. For example, Exchange Outlook Anywhere (RPC over HTTP/HTTPS) and Active Directory Certificate Services Web Enrollment (CEP/CES) use HTTPS-based communication instead of traditional RPC. If you’re troubleshooting these services, focus on IIS, HTTPS connectivity, certificates, authentication, and proxy config rather than RPC endpoint mapping and dynamic RPC ports.

Additional Solutions for RPC Server Unavailable Issues

Additional methods that can resolve the RPC unavailable error in some cases include:

Enable IPv6 and File Sharing

Some apps may error ‘1722 The RPC server is unavailable” if the IPv6 protocol is disabled on a computer. Open the properties of your network adapter in the Control Panel (Win + R > ncpa.cpl), and check if Internet Protocol Version 6 (TCP/IPv6) and File and Printer Sharing for Microsoft Network are enabled.

Enterprise note. Keep in mind that you should keep IPv6 enabled on Windows systems by design.
We don’t reccomend disabling IPv6 as a general troubleshooting step for RPC Error 1722.

Instead of disabling IPv6, you need to troubleshoot dual-stack networking problems such as:

• incorrect DNS AAAA records
• routing inconsistencies between IPv4/IPv6
• firewall rules affecting one protocol family only

Check Print Spooler and Network Profile

RPC error 1722 may occur when attempting to send a document to a shared network printer. In this case, you need to check if the remote computer is powered on, and the Print Spooler service is running on it.

Check the network profile

Check that the network profile assigned to the client and server is either Private or Domain network:

Get-NetConnectionProfile