RPC Server Unavailable (RPC_S_SERVER_UNAVAILABLE) error code 1722 indicates that your Windows computer is having a problem communicating with other remote computers or devices over the network.
There are a number of reasons for this error. RPC error 122 is most commonly seen on domain controllers, it is an indication that AD replication is not working properly.
This article is a troubleshooting guide for RPC Unavailable error 1722 in various cases. 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.
Table of Contents
Active Directory Replication Error 1722: RPC_S_SERVER_UNAVAILABLE
Error 1722: The RPC server is unavailable can be found in the domain controller’s Event Viewer logs if it cannot contact its replication partner according to the AD topology. This error indicates that there are problems with AD replication.
Try using 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.
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 DCs, or invalid entries in the primary DNS domain zone;
- Poor network performance and/or high latency.
Make sure the target 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;
- Server;
- Workstation;
- Windows Time;
- Netlogon.
You can use the PowerShell command to quickly check the status of the specified services on a DC:
Get-Service EventSystem, RpcSs,NTDS, Dnscache, Dns, DFSR, IsmServ, Kdc, SamSs, LanmanServer, LanmanWorkstation,W32Time, Netlogon
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:
- Check if you can access the shared SYSVOL and NETLOGON folder using the UNC path (\\lon-dc01);
- If they are not available, check the basic network connectivity to the problem DC:
ping lon-dc01 tracert lon-dc01
- Then check that TCP port 135 (RPC locator) on the target DC is not blocked by a firewall. Use the PortQry tool to test the RPC connection to the target DC (according to the last chapter of this post):
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 preferred DNS server address should point to another DC in the same AD site, and the alternate is to its own IP address.
Check the DNS health on a problem DC with the dcdiag tool:
DCDIAG /TEST:DNS /V /S:<ProblemDCName>
Hint. Rebooting the domain controller can often fix missing DC entries in DNS, and resolve problems with Netlogon and Sysvol services.
If your domain controllers are running different versions of Windows (for example, 2019 and 2012 R2), you should check to see whether SMBv2 is enabled on the older versions of Windows Server. DCs will not be able to communicate with each other with an RPC Unavailable error if this protocol is disabled.
Get-SmbServerConfiguration | select 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.
On desktop computers running Windows 10 and 11, you may receive the error “1722 The RPC server is unavailable” if the local service/app (RPC client) 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:
Get-Service RpcSs,RpcEptMapper,DcomLaunch
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 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:
ipconfig /flushdns
The RPC error 1722 may occur while trying to send a document to a shared network printer on a remote computer. In this case, you need to check if the remote computer is powered on, and the Print Spooler service is running on it.
Testing RPC Ports with PortQry
The Remote Procedure Call (RPC) protocol is widely used in Windows for communication between computers. It based on a client-server model. To accept client connections, the following services should be running on the RPC server side:
- RPC Endpoint Mapper: RpcEptMapper – is listening on a static TCP port 135
- Remote Procedure Call (RPC): RpcSs – accepts connections on a dynamic TCP port range (from 49152 to 65535)
RPC sessions work in this way. The client connects to the RPC Endpoint Mapper and requests the dynamic port number assigned to the specific RPC service. RpcEptMapper responds with the IP address and service port number (a random dynamic port is assigned when the service starts).
You can use the portquery command line tool to check connectivity via RPC. (PortQry Command Line Port Scanner).
Check that the RPC port mapper is responding on a remote computer:
portqry -n <problem_server> -e 135
In this example, the RPC Port Mapper service listens 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
1 comment
Thanks for the article Cyril. Just another tip if you’re still having this problem after following all of the above advice. I was having issues with a 2012R2 DC talking to a 2019 DC – for some reason the 2012R2 DC wasn’t configured to use SMBv2 and enabling this fixed my issue.
Create a backup of the lanmanworkstation reg key before running the below commands from an elevated prompt;
sc config lanmanworkstation depend= bowser/mrxsmb10/mrxsmb20/nsi
sc config mrxsmb20 start= auto
sc start mrxsmb20
sc stop lanmanworkstation
sc start lanmanworkstation
Comments are closed.