Troubleshooting ‘RPC Server Not Available’

I. Understanding the problem:

The most common issue that causes ‘RPC Server Not Available’ is with the TCP/UDP ports that certain Windows subsystems require for gathering performance data from remote servers. These ports are as follows:

  • WMI Access:
  • TCP port 135 and a range of dynamic ports, [TCP 49152-65535 (RPC dynamic ports – Windows Vista, 2008 and above), TCP 1024-65535 (RPC dynamic ports – Windows NT4, Windows 2000, Windows 2003), or a custom range of ports (see note below)]
  • Widows Performance Counter Access: TCP port 445 (SMB, RPC/NP)
  • There are other reasons that you might have trouble gathering performance data, but inability to connect via the above ports are known to cause the ‘RPC server Not Available’ error specifically.

II. Tools for use in troubleshooting this error:

The following tools can be used to aid in discovering connectivity issues involving RPC:

A. Performance Monitor:

Using Performance Monitor, check to see if the Remote Registry service is working properly between the target and the monitoring server.

Perform the following from the server that is hosting the SQL Sentry monitoring service:

  1. Launch Performance Monitor
  2. Click on the + icon above the chart to add new counters
  3. Enter the name or IP address for the target server and hit Enter on your keyboard (you may have to wait a minute for the new counter list to load). If you receive an error message SQL Sentry will be unable to access performance counters remotely as well.

Note your results, and proceed to the next test.

B. wbemtest.exe:

  • Launch wbemtest.exe using a command prompt or the run command from the start menu
  • Click the Connect button to connect to the remote server
  • You will then enter the name (in UNC format) for the target server, along with the root\cimv2 WMI class path of the target server as shown here. (i.e. \\server_name\root\cimv2)

Note your results and proceed to the next test.

C. Check RPC Dynamic ports

RPC uses a range of dynamic ports to transfer data. The initial connection is made to the endpoint mapping port (135), and at the point a port from the dynamic port range is chosen for further communication. If you are using a firewall. You must ensure these dynamic ports are allowed through the firewall to enable RPC communication.                        

The default dynamic port range is quite large, and it is possible to restrict the range on each server using the following commands to improve security:

  • netsh int ipv4 set dynamicport tcp start=<start_num> num=<num_ports>
  • netsh int ipv4 set dynamicport udp start==<start_num> num=<num_ports>
  • netsh int ipv6 set dynamicport tcp start==<start_num> num=<num_ports>
  • netsh int ipv6 set dynamicport udp start==<start_num> num=<num_ports>

On windows 2008 and higher, the minimum amount of ports specified for <num_ports> is 255.

D. Test ports using PSPing

  1. PsPing (
    • PSPing can be used to ping a remote server on a specified port using TCP or UDP. The commands used should be as follows:
      1. If the test using Perfmon failed:
        1. Psping <server_name>:445
      2. If the test using wbemtest failed:
        1. Psping <server_name>:135
      3. Example

E. TCPView (

  • Allows you to see which ports are being used by which process as well as the Protocol being used and the State of the connection

This information can be quite useful in determining what processes are unable to connect to remote servers.

The above tools and techniques can be used to help determine connectivity issues with regard to accessing remote performance counters and WMI repository information. You can provide your test results to your network engineer, who can then work to ensure you have the necessary connectivity to fully monitor your environment. The following Microsoft KB could also be helpful in resolving the issue:

Have more questions? Submit a request


Please sign in to leave a comment.