RPC Server Unavailable (0x800706BA) from MID Server

[imtiazahmad]

• We are receiving the 0x800706BA – RPC Server Unavailable error from the MID Server while attempting to connect to the host machine.
• We have already verified that the required permissions are in place, the necessary services are running on the host, and the relevant firewall rules are configured correctly. However, the MID Server is still unable to establish the RPC connection with the host.
• Could you please assist us in identifying any additional configuration or connectivity checks that we should perform?

[NehaG8791370651]

Hello Imtiaz,

From an infrastructure perspective, the 0x800706BA error is fundamentally a network topology and protocol routing block rather than a ServiceNow platform defect. In complex enterprise environments, we see this frequently when strict network micro-segmentation policies are enforced.

While the primary RPC port (135) is often whitelisted by default, the secondary ephemeral ports required for WMI communication are frequently restricted by modern network security appliances sitting between the MID Server enclaves and target subnets.

From an architectural standpoint, I highly recommend engaging your network engineering team to audit the traffic path. Have them run a packet capture (PCAP) or check the firewall drop logs while you initiate a Discovery run. Standardizing your network security policies to consistently account for Windows RPC dynamic port ranges across your designated MID Server VLANs will resolve this and prevent future discovery blind spots as your infrastructure scales.

[imtiazahmad]

Hi Neha,
Thank you for the insight and recommendation.

During our investigation, we initially considered network and RPC communication as the primary cause due to the 0x800706BA (RPC Server Unavailable) error. As part of the troubleshooting, we performed the following validations:

• Verified network connectivity between the source server and target server.
• Confirmed TCP 135 (RPC Endpoint Mapper) connectivity was successful.
• Reviewed Windows Firewall configuration and compared it against a known working server.
• Verified that RPC (RpcSs), DCOM Launcher (DcomLaunch), and WMI (Winmgmt) services were running.
• Validated the WMI repository integrity using winmgmt /verifyrepository.
• Confirmed DCOM was enabled and remote access settings were correctly configured.
• Tested WMI locally and remotely using both WMI and CIM queries.
• Reviewed WMI Activity and System Event Logs for connectivity and permissions-related errors.
• Added and enabled the required inbound firewall rules for Dynamic RPC High Ports (49152-65535) to support remote WMI communication.

Through further analysis, we determined that the issue was not caused by a ServiceNow platform defect. While network connectivity and RPC communication were validated and the required firewall rules were in place, the root cause was insufficient permissions for the account used to perform the remote WMI queries.

Resolution implemented:

• Granted the required registry permissions to the service account used for remote WMI access.
• Added/verified the inbound firewall rules for Dynamic RPC High Ports (49152-65535).
• Restarted the Windows Management Instrumentation (WMI) service.
• Re-tested WMI connectivity and confirmed successful remote access and query execution.

Following these changes, the WMI queries completed successfully and the issue was resolved.

That said, your recommendation regarding validation of dynamic RPC ports and firewall policies remains valuable for future Discovery troubleshooting, especially in segmented environments where network controls can impact WMI-based communication.

Thanks for your support.

[VJ_Srivastava]

Hi Imtiaz,

Discovery connectivity issues like this are critical to resolve quickly, as they create immediate blind spots within your CMDB. When your MID Servers cannot reliably connect to host machines, the resulting stale data directly impacts the operational efficiency of your downstream ITSM and ITOM processes—ultimately slowing down incident resolution times and skewing asset compliance reporting.

Often, these technical bottlenecks stem from siloed teams. The fastest path to resolution here is usually to facilitate a quick alignment between your ServiceNow platform owners, your network security team, and the Windows infrastructure admins. Getting them to jointly review the ephemeral port traffic and domain policies ensures your CMDB stays accurate, keeping your operational data trustworthy for the business units relying on it.