Windows error The RPC server is unavailableDescription The MID server can use WMI/Powershell to execute automations on windows devices. Error "The RPC server is unavailable" is returned when the MID server cannot complete communication to a target server. This could happen when running a Discovery, Orchestration, or IntegrationHub Powershell step. To successfully run a Powershell probe, it is a prerequisite to have an environment configured to allow communication between the MID server and the target server, and a credential with the necessary rights. It is often necessary to reach out to the windows/network team managing the target server/environment to resolve "The RPC server is unavailable" error. Support can provide best effort in helping resolve this error. The resolution section of this article contains a list of issues and resolutions support has found while helping resolve "The RPC server is unavailable" error. Table of Contents DescriptionRPC portsRoot CauseResolutionTroubleshootingExample Troubleshooting RPC ports WMI is based on DCOM/RPC. This means a connection is first initiated on port 135 to determine what dynamic port to use. The connection then proceeds to use the dynamic port negotiated. The default ranges of DCOM ports are: From 1025 to 5000: Windows 2000, Windows XP, and Windows Server 2003From 49152 to 65535: Windows Server 2008 and later versions, and in Windows Vista and later versions The following Microsoft documentation provides more information on this topic: Setting up a Remote WMI ConnectionHow to configure RPC dynamic port allocation to work with firewalls Error "The RPC server is unavailable" indicates the connection cannot complete successfully. In the following image we see a Wireshark capture of a successful WMI connection between two devices (In this example DCERPC traffic is filtered out). The initial connection to the target is on port 135. Then the connection continues on port 62199 (this was the dynamic port negotiated and could have been a different port). Root Cause Possible root causes are, but not limited to: Firewall SettingsAntivirusIncorrect Time and Time zone settings.DNS not up to dateKerberos issues Resolution Firewall Confirm the firewalls of the source device, target device, and network, are not blocking the connection on port 135, or one of the dynamic ports. If necessary, review following Microsoft documentation on Setting Up a Fixed Port for WMI. Antivirus Work with your antivirus team to allow the connection to complete, steps will depend on the antivirus software. Incorrect Time and Time zone settings. Verify correct Time and Time Zone settings. DNS/Kerberos issues DNS not being up to date can cause issues with Kerberos authentication. On the MID server, use command "nslookup" to check that both forward and reverse lookup are correct for the target device. Troubleshooting Overall Troubleshooting Confirm credential username and password are correctLog into the MID serverSet up a network monitor on the MID serverReproduce the issueReview the traffic capture Example Troubleshooting DNS/Kerberos issue Discovery returns "The RPC server is unavailable". Attempting a gwmi command against the target using same domain username and password returns the same error. The following image shows the output that is returned. In Wireshark, Kerberos errors and packets reset/timeouts were displayed. Note: The previous error is not related to discovery but rather bring to light an environment issue. Troubleshooting, in this case, would be best if done by the Windows/Network team managing the target server. Investigation on event logs on the target server also revealed errors such as the following: Log Name: System Source: Microsoft-Windows-Security-Kerberos Event ID: 4 Task Category: None Level: Error Keywords: Classic User: N/A Computer: computerName.domain Description: The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server serverName. The target name used was domain/serverName... Research on error KRB_AP_ERR_MODIFIED led to a Microsoft article which explained this error could be due to reverse lookup mismatch. Running command "nslookup <target_ip>" on the MID server and command "hostname" on the target confirmed the mismatch. Once the DNS was up to date the issue was resolved.