Support Tip: Pushing an Operations Manager agent fails with Error Code: 800706BA - "RPC server is unavailable"

First published on TECHNET on Jun 01, 2015

~ Arun Kumar | Support Escalation Engineer

When you are pushing an agent from an Operations Manager management server, you may encounter the following error:

The Operation Manager Server failed to perform specified operation on computer agent1.contoso.com.
Operation: Agent Install
Install account: contoso\Agent_action
Error Code: 800706BA
Error Description: The RPC server is unavailable

If you encounter this issue, it’s possible that either nonstandard ephemeral ports are being used, or that the ports are blocked at a firewall. For example, if nonstandard high range RPC ports have been configured, a network trace while pushing the agent will show a successful connection to RPC port 135 followed by a connection attempt using a nonstandard RPC port such as 15595 as shown below.

18748 MS Agent TCP TCP: Flags=CE....S., SrcPort=52457, DstPort=15595, PayloadLen=0, Seq=1704157139, Ack=0, Win=8192
18750 MS Agent TCP TCP:[SynReTransmit #18748] Flags=CE....S., SrcPort=52457, DstPort=15595, PayloadLen=0, Seq=1704157139, Ack=0,
18751 MS Agent TCP TCP:[SynReTransmit #18748] Flags=......S., SrcPort=52457, DstPort=15595, PayloadLen=0, Seq=1704157139, Ack=0, Win=8192

Since the port exemption for this non-standard range was not configured on the firewall, the packets are dropped and the connection is severed.

To give this a little perspective, in Operations Manager, monitoringHost.exe on the management server running the agent install task will connect to the agent's RPC service over TCP port 135, and in turn a secondary RPC connection is created on a standard RPC high range port. The same thing happens with WMI service as well, where monitoringHost.exe first connects to the port that the WMI service is listening on and then subsequently on a RPC high range port for some DCOM operation.

Now we know that in Windows Vista and above the RPC high range ports are 49152-65535 so that’s what we want to look for. To verify whether this is your issue, run the following command to see what RPC high port range is configured:

Netsh int ipv4 show dynamicportrange tcp

As per IANA standards, it should look something like this:

Protocol tcp Dynamic Port Range
---------------------------------
Start Port      : 49152
Number of Ports : 16384

If you see a different start port then the problem may be that the firewall is not configured correctly to allow traffic on those ports. You can change the configuration on the firewall or you can run the command below to set the high range ports back to their default values:

Netsh int ipv4 set dynamicport tcp start=49152 num=16383

Note that you can also configure the RPC dynamic port range via the registry. See the following for more information:

154596 - How to configure RPC dynamic port allocation to work with firewalls ( https://support.microsoft.com/en-us/kb/154596 )

If everything appears to be configured correctly but you still experience the problem, it may be that one of the following conditions are true:

1. DCOM has been restricted to a certain port. To verify, open dcomcnfg.exe and traverse to dcomcnfg -> My Computer –> Properties –> Default Protocols and ensure that there is not custom setting there.

2. WMI is configured to use a custom endpoint. To check if you have a static endpoint configured for WMI, open dcomcnfg.exe and traverse to dcomcnfg -> My Computer –> DCOM Config -> Windows Management and Instrumentation –> Properties -> Endpoint and ensure that there is no custom setting here.

3. The agent computer is running the Exchange 2010 CAS role. The Exchange 2010 Client Access Service changes this port range to 6005 through 65535. The range was expanded to provide sufficient scaling for large deployments. Do not change these port values without fully understanding the consequences of doing such.

Arun Kumar | Support Escalation Engineer | Microsoft GBS Management and Security Division

Get the latest System Center news on Facebook and Twitter :

System Center All Up: http://blogs.technet.com/b/systemcenter/

Configuration Manager Support Team blog: http://blogs.technet.com/configurationmgr/
Data Protection Manager Team blog: http://blogs.technet.com/dpm/
Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
Operations Manager Team blog: http://blogs.technet.com/momteam/
Service Manager Team blog: http://blogs.technet.com/b/servicemanager
Virtual Machine Manager Team blog: http://blogs.technet.com/scvmm

Microsoft Intune: http://blogs.technet.com/b/microsoftintune/
WSUS Support Team blog: http://blogs.technet.com/sus/
The RMS blog: http://blogs.technet.com/b/rms/
App-V Team blog: http://blogs.technet.com/appv/
MED-V Team blog: http://blogs.technet.com/medv/
Server App-V Team blog: http://blogs.technet.com/b/serverappv
The Surface Team blog: http://blogs.technet.com/b/surface/
The Application Proxy blog: http://blogs.technet.com/b/applicationproxyblog/

The Forefront Endpoint Protection blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/

System Center 2012 Operations Manager System Center 2012 R2 Operations Manager OpsMgr 2012 R2