Knowledge Base

Windows Server: Troubleshooting "RPC Server Unavailable" Errors


This article provides information on troubleshooting an "RPC server unavailable" error in Microsoft Windows for Server.

Table of Contents

  1. Introduction
  2. Stopped RPC service
  3. Name resolution issues
  4. Traffic blocked by firewall
  5. Connectivity issues

1. Introduction

"The RPC server is unavailable" is a fairly common error in Windows that can occur in a wide variety of situations, most of them involving communication between two machines across a network. It can also occur during local operations on a machine, however. For clarity, in this article, the machine initiating RPC communication will be designated the client, and the machine with which it communicates will be the server.

Remote Procedure Call (RPC) is a mechanism that allows Windows processes to communicate with one another, either between a client and server across a network or within a single system. Numerous built-in Windows components utilize RPC. RPC uses dynamic ports for communication between systems, but a static port (TCP port 135) must also be used as a starting point for communication. The RPC endpoint mapper listens on this static port.

In a typical RPC session, a client contacts a server's endpoint mapper on TCP port 135 and requests the dynamic port number assigned to a particular service. The server responds with the IP address and port number that the service registered with RPC when it started, and the client then contacts the service on that IP address and port.

Possible causes of the "RPC server unavailable" error include the following:

  • Stopped RPC service: If the RPC service on the server isn't running, the client obviously won't be able to reach it.
  • Name resolution issues: The RPC server's name may be resolving to the wrong IP address, resulting in the client contacting the wrong server or attempting to contact an IP address not currently in use. Alternatively, the server's name may not be resolving at all.
  • Traffic blocked by firewall: A firewall or other security application on the server, or a network firewall appliance between the client and server, may be preventing traffic from reaching the server on TCP port 135.
  • Connectivity issues: The client may be unable to reach the server at all due to a general network problem.

The following steps, categorized by cause, may be useful in troubleshooting the issue.


2. Stopped RPC Service

  1. Open the Services console on the server.
  2. Locate the Remote Procedure Call (RPC) service and make sure it is running.
    Note: The Remote Procedure Call (RPC) Locator service does not typically need to be running.
  3. If the service is stopped, attempt to start it manually.


3. Name Resolution Issues

  1. Ping the server by name from the client to verify that the name resolves to the correct IP address. If it does, name resolution is not likely to be the cause of the issue, and the remaining steps in this section can be skipped.
  2. If the client and server are members of an Active Directory (AD) domain, DNS is used for name resolution. Verify that the client and server are both using the correct DNS servers, which must be inside the domain and will typically be domain controllers.
  3. If the correct DNS servers are being used, use the DNS Management console on those servers to verify that the RPC server has the correct record(s) registered in DNS. If necessary, the ipconfig /registerdns command can be used on the RPC server to re-register its DNS records.
  4. If there is no AD domain present, WINS may be used for name resolution. The ipconfig /all command will list, among other things, the WINS servers being used by the RPC server. Check the WINS database on these servers to verify that the records registered for the RPC server are correct. If necessary, the nbtstat -RR command can be run on the RPC server to re-register its WINS records.


4. Traffic Blocked by Firewall

  1. Check the Windows Firewall settings on the RPC server.
  2. If the firewall is enabled, make sure traffic on TCP port 135 is allowed to pass.
    1. If the server is running Windows Server 2003, the Windows Firewall may not correctly handle RPC dynamic port allocation. In this case, it may be necessary to disable the Windows Firewall or restrict the ports used by RPC (see step 4).
    2. If the server is running Windows Server 2008 or later, verify that the Windows Firewall service is running. The Windows Firewall in Windows Server 2008 and above should properly handle RPC traffic by default; however, if this must be manually configured, see this TechNet article for instructions: Allowing Inbound Network Traffic that Uses Dynamic RPC.
      If the Windows Firewall must be completely disabled in Windows Server 2008 or above, do not stop the Windows Firewall service. Instead, follow the steps in How to Properly Turn Off the Windows Firewall in Windows Server 2008 and Above.
  3. If third-party firewall software, another security application, or a network firewall appliance is in place, see the documentation for the application or appliance to determine whether it can be properly configured to handle RPC traffic.
  4. If the firewall software, other security application, or network appliance cannot be configured to properly handle dynamic RPC traffic, the port range used by RPC can be restricted, and this range can then be opened on the firewall or security application. To restrict the port range used by RPC, see How to Configure RPC Dynamic Port Allocation to Work with Firewalls.


5. Network Connectivity Issues

  1. Use the ping command to test basic connectivity between the RPC client and server. Note that this test may not be conclusive, as it is possible for a firewall to block ICMP traffic while allowing other traffic to pass. (ICMP, or Internet Control Message Protocol, is the protocol used by the ping and tracert commands.)
  2. The PortQry command-line utility can be used to test connectivity from the client to the server and determine which ports are open on the server. It includes support for RPC and can be used to determine which services have dynamic ports registered with RPC and which specific ports they use. Detailed information on PortQry version 2.0 is available here: New Features and Functionality in PortQry Version 2.0.
  3. If the client and server are on different subnets, verify that traffic is properly routed between the two. If they are in different physical locations, verify that the link between the sites is up and allowing traffic to pass freely.

For further instructions on troubleshooting this error, see Troubleshooting "The RPC Server is Unavailable."
For general information on RPC, see What Is RPC?




Need more help?
Find additional PowerEdge and PowerVault articles

Visit and ask for support in our Communities

Create an online support Request


Article ID: SLN283117

Last Date Modified: 05/09/2017 09:35 AM


Rate this article

Accurate
Useful
Easy to understand
Was this article helpful?
Yes No
Send us feedback
Feedback shows invalid character, not accepted special characters are <> () &#92;
Sorry, our feedback system is currently down. Please try again later.

Thank you. Your feedback has been sent.