Server Unavailable errors when connecting to Remote Server

Redgate Monitor reports errors such as "machine unreachable" or "cannot connect" or "cannot add instance/server/cluster" or "Server not found or was not accessible". In Show Log, you will see 0x800706BA – The RPC server is unavailable. It means that Redgate Monitor cannot access the external server, usually because a firewall is blocking the WMI connection on the required port. This a very common problem when monitoring a remote cluster because the configuration is more complex, with more ports involved.

NOTE: These problems are WMI connection errors, not Redgate Monitor errors. You will be able to reproduce the error by running connection tests externally to Redgate Monitor, using wbemtest or PowerShell. The guidance that follows summarizes our previous experiences with these problems, typical underlying causes, and possible resolutions that have worked for other customers. Beyond this, Redgate cannot provide further support for these environmental issues. Once you fix the external problem, the connection error will be resolved in Redgate Monitor.

Overview of port and Firewall requirements

Redgate Monitor uses the Windows Management Instrumentation (WMI) Protocol, either over DCOM or WinRM, to connect to and gather information from the servers and SQL Server instances you wish to monitor.

WMI uses port 135 (RPC), but in addition to this, through its use of DCOM which it's built upon, it also uses a random port between 1065 and 65535 to continue the conversation. Finally, it uses TCP port 1433 (by default) for communication with each SQL Server instance on the machine (over TDS).

If you hit trouble, you'll need to run checks to verify the port on which traffic is being blocked, by the firewall.

0x800706BA resolution steps

The 0x800706BA – The RPC server is unavailable is an error seen when using WMI-over-DCOM, which uses the RPC protocol. It means simply that the Redgate Monitor base monitor service cannot reach the remote server. It can have a number of causes, but the most common is a firewall blocking access on one of the ports that must be open to allow WMI communication between Redgate Monitor and the remote machines.

The following checks and actions have helped other customers resolve these problems but please share the following suggestions with your own system administration team, along with the detailed error messages and WBEMtest results, and act on their advice.

1. Check that the server name you entered is definitely correct.
   
   
2. Check that the "Remote Procedure Call (RPC)" service is started, on the server where the Redgate Monitor base monitor service is installed, and on the remote machine to which it's connecting (this can be several machines if you're monitoring a cluster).
   
   
3. Review the firewall requirements – share the Summary of firewall requirements page in the documentation with your sysadmin team. It lists the ports that must be open for traffic on each remote machine that you need to monitor.
   
   
4. Run some connection tests, if possible– the section Test WMI Connection using PowerShell gives instructions and some simple PowerShell scripts to check for traffic restrictions or other problems. You can check that Port 135 is open, plus the further ports for DCOM communication, and that all the ports for TDS communication with the SQL are allowed through the firewall.
   
   
5. Consider using a restricted port range or static port for WMI over DCOM – if Port 135 is open but communication is still blocked, the WMI over DCOM page shows you how to configure dynamic port allocation to work with the firewall, restrict the port range or alternatively make it use a static port.
   
   
6. If monitoring a remote cluster you'll first need to have set up a DNS, and then open WMI communication ports both to the cluster name as well as all nodes in the cluster.
   
   When you connect to a cluster, Redgate Monitor discovers all the resources that belong to the cluster using the cluster name. Even if, in Redgate Monitor, you enter the connection details of the active node, Redgate Monitor will recognize that it is a part of the cluster, and attempt to connect to and query the cluster namespace first to discover the other nodes. It creates the connection string using the cluster node name (not the IP address) and then detects the instances through the SQL browser (so the SQL bowser must be running). In other words, you can connect to the active node name, or the cluster name and it takes you to the same place, but via a different IP address, and it's possible that the firewall may be blocking one but not the other. You'll need you firewall to allow WMI traffic to access both.
   
   
7. Check the ports for SQL Instances – check and edit the ports assigned to each instance from the Redgate Monitor web interface, from Configurations – Monitored Servers – Edit credentials – Edit properties.
   1. Named SQL Server instances use dynamic ports by default, so you need to configure a specific TCP port for each named instance.
   2. Check that the SQL Server Browser is enabled and allowing access to port 1434. See Summary of firewall requirements.

Verifying the error using wbemtest

Search the Redgate Monitor logs (Configuration - Diagnostics - Retrieve log files) using the affected server name as reference. You will see WMI errors for "0x800706BA – The RPC server is unavailable".

To reproduce the exact error externally, use the WBEMTest tool. Follow the steps described in the documentation for Testing a WMI Connection using WBEMTest (if connecting over DCOM, or PowerShell otherwise). Run the tests from the base monitor to the target server.

If you are monitoring a Windows Server Failover Cluster, queries the root\MSCluster namespace to obtain information about resources on the cluster, so you'll need to test queries MSCluster namespace in WMI, as well as to root/cimv2 for individual nodes.

1. In step 5, enter the cluster namespace:(\\myserver.example.com\root\mscluster)
2. Make sure that the packet privacy is enabled under Authentication level.
3. In step 7, use the query SELECT * FROM MSCluster_Resource WHERE Type = 'SQL Server'