The 1722 RPC Server Unavailable (RPC_S_SERVER_UNAVAILABLE) error is a fairly common one that domain administrators are faced with when AD replication is not working properly. However, this error can also occur on workstations running a desktop version of Windows 10/11 or Windows Server that do not have the ADDS role installed. This article will show how to troubleshoot and fix the RPC error 1722 in different cases.
In this section we’ll take a look at the basic ways to Error 1722: The RPC server is unavailable in Active Directory. In most cases, this error is caused by a communication problem between the domain controllers. If this happens, you may have problems with AD replication.
You can face the error both in the domain controller event logs and when trying to start or check the replication status using the Repadmin or dcdiag tool.
For example, you want to check the current replication status in Active Directory:
Dcdiag may return an error:
The replication generated an error (1722):
The RPC server is unavailable.
[lon-dc01] DsBindWithSpnEx() failed with error 1722.
Some of domain controllers may return an “(1722) The RPC server is unavailable” error. This means that some domain controllers are unable to replicate AD changes (or just inactive) for a few days.
Hint. There is a similar error RPC Server is Unavailable 0x800706BA, which is not usually associated with Active Directory domain controllers. This needs to be fixed differently.
Let’s consider the typical reasons for the 1722 AD replication error:
- The domain controller is offline (or broken);
- Some of the domain controller system services are not running;
- Incorrect network configuration and/or blocked ports on firewalls;
- Incorrect DNS configuration on domain controllers, or invalid DNS records;
- Poor network performance and/or high latency.
Make sure the specified domain controllers are powered on and running the following Windows services:
- COM+ Event System;
- Remote Procedure Call (RPC);
- Active Directory Domain Services;
- DNS Client;
- DFS replication;
- Intersite Messaging;
- Kerberos Key Distribution Center;
- Security Accounts Manager;
- Windows Time;
For example, lon-dc01 is the problematic DC that returns “1722 RPC server unavailable”. First, check the connection to lon-dc01 from the remote DC:
- Make sure you can access the problematic DC via the UNC path \\lon-dc01, and that the SYSVOL and NETLOGON folders are shared.
- If they are not available, check the basic network connectivity between the RPC client and server:
ping lon-dc01 tracert lon-dc01
- Then check that TCP port 135 (RPC locator) on the target DC is not blocked by a firewall:
Test-NetConnection lon-dc01 –port 135
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 primary address should be the address of another DC, and the secondary one is its own IP address.
Check the DNS health on a problem DC with the dcdiag tool:
DCDIAG /TEST:DNS /V /S:<ProblemDCName>
Hint. Problems with DC entries in Active Directory DNS, Netlogon and Sysvol services can often be resolved by simply rebooting the domain controller.
Active Directory uses the dynamic range of TCP ports for replication. Windows Server 2008 R2 (and higher) uses the following port range for TCP Dynamic RPC — from 49152 to 65535.
In some cases, an AD administrator can bind (restrict) Active Directory replication traffic to a specific port. In this case, the fixed RPC port number must be configured in the domain controller registry. For example, to bind the AD replication traffic on TCP port 5000 (0x1388), you need to change the registry key on the domain controller:
[HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters] "TCP/IP Port"=dword:00001388
If firewalls are used on your corporate network and the replication port AD is fixed, then replication won’t work on the newly promoted DC. This happens because the DC will try to replicate with the partner over a random port from the dynamic RPC range that is blocked by the firewalls.
If your domain controllers are running different versions of Windows (for example, 2019 and 2012 R2 DCs), you should check to see if SMBv2 is enabled on the older versions of Windows Server.
Get-SmbServerConfiguration | select EnableSMB2Protocol
DCs will not be able to communicate with each other with an RPC Unavailable error if this protocol is disabled.
After you’ve fixed all problems, you can run the repadmin /replsummary command again, and check if the replication was successful. We also recommend initiating the AD replication manually and checking for errors. Make sure the dcdiag /a /q command doesn’t return errors.
On Windows, you may receive the error “1722 The RPC server is unavailable” if the local service/app (RPC client) on your computer cannot communicate with the service on the remote computer (RPC server).
In this case, you must check that the services required for the RPC protocol are running on the remote computer:
- Remote Procedure Call (RPC);
- RPC Endpoint Mapper;
- DCOM Server Process Launcher;
Open the Service management console (services.msc), and check if the specified services are in the Running state. If not, start them manually.
You can also use PowerShell to check the status of services:
Check that TCP port 135 on the domain controller is in Listening state. The svchost process must be listening on this port:
netstat -ano | find "135" Get-Process -Id (Get-NetTCPConnection -LocalPort 135).OwningProcess
Also, some network applications may return error ‘1722 The RPC server is unavailable’ if the TCP/IPv6 protocol is disabled on the 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.
After that, use the following command to disable the Teredo IPv6 tunneling protocol:
netsh interface teredo set state disabled
And clear the DNS cache with the command:
Also, RPC error 1722 may also occur when you try to print a document on a remote computer with 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.
In Windows 10/11, in order for some RPC connections to work correctly, you will need to open the Advanced Sharing settings in the Control Panel (run the command: control.exe /name Microsoft.NetworkAndSharingCenter /page Advanced). Expand the setting for the network profile that you are using and enable the network discovery and file and printer sharing options.
Troubleshooting RPC Connectivity Using Portquery
The Remote Procedure Call (RPC) protocol is used in Windows to communicate between computers over a network. Many built-in Windows services use RPC (Distributed File System, AD Replication, DCOM services, MSSQL, Exchange, SCOM, SCCM, NLB, Microsoft Cluster Services, Certificate services, etc.).
The RPC protocol is based on a client-server model. The RPC server accepts and processes connections using the RpcSs service. Windows dynamic ports are used for communication between clients and the RCP server (TCP Range from 49152 and up to 65535).
The static TCP port 135 is used as the starting point for RPC communication. This port is listened by the RPC Endpoint Mapper (RpcEptMapper) service. In a normal RPC session, the client connects to the RPC endpoint mapper service on the server on port 135 and requests the dynamic port number assigned to the particular service. RpcEptMapper responds with the IP address and service port number (a random dynamic port is assigned when the service starts).
The most common causes of RPC errors are:
- Disabled RPC service;
- Name resolution errors (DNS or NetBIOS);
- Network connectivity issues;
- RPC traffic is blocked by the firewall.
You can use the portquery tools to diagnose the availability of the RPC and RPC Port Mapper services (PortQry Command Line Port Scanner).
To check the availability of the RPC Port Mapper port on a remote computer, run the command:
portqry -n <problem_server> -e 135
In this example, you can see that the RPC Port Mapper service is available on TCP port 135. The service also service returns a list of running RPC endpoints and the ports associated with them (in square brackets). Check if the service you are troubleshooting is on this list. Check that the port assigned to your TCP service is not blocked by firewalls between the client and server.
portqry -n <problem_server> -p tcp -e 49666