Testing RPC ports with PowerShell (and yes, it’s as much fun as it sounds!)

Doctor Scripto

Dr Scripto

Summary: Using PowerShell to identify RPC ports in use by capturing content from Dos Commands like PortQRY.exe

We’d like to introduce you today to one of our newest bloggers!  It’s a froopingly awesome friend of ours, Joel Vickery, PFE.  (did I mention Dr. Scripto is a big fan of books written by Douglas Adams?….oops!)

Take it away Joel!

Thanks Doc!  So hey everybody!

What do you do when you have to troubleshoot the dreaded “RPC Unavailable” error 1722, which rears its ugly head anywhere from Active Directory replication to Configuration Manager Distribution Point installations, and many other places in between?

Example of the Error 1722 RPC Server Unavailable in the wild

To help prevent this from becoming a blame pointing cage match between the System Admins and the Network Folks (we all know the Sys Admins would win anyway), I’m writing this post to help put some structure around troubleshooting this type of issue so that you have more facts to take to the conversation. “I think it’s a firewall issue” doesn’t get you very far in my experience.

RPC communication is one of the tougher firewall problems since most firewall folks want to know exactly which ports you need open.  With RPC, they get a range of ports from 49152 to 65535.  There are usually predefined rules on firewalls, WAN accelerators, and the various devices that traffic hops through to get to its destination.  They do not always work as planned.

To give you the simplest example I can think of, RPC sort of works like the concierge desk at a hotel.  You walk up and ask the person at the desk for the information about services at the hotel, like the gym or the swimming pool.  In our scenario, that person at the desk is RPC Endpoint Mapper on port 135 and they direct you to the services that are listening on the ephemeral ports. I’m just barely breaking the surface on RPC in this post.  If you want to get the full picture, take a look at what, in my opinion, is the best explanation about how RPC works in gory detail, written by Ned Pyle (and his dogs) at the link below: https://blogs.technet.microsoft.com/askds/2012/01/24/rpc-over-itpro/ I see a lot of administrators attempting to diagnose this network connectivity by looking up the RPC ports (135 & 49152-65535) and then attempting to connect to random ports in the ephemeral range, hopefully this post will help with isolating the ports that are truly listening on the server.

Getting the ports

The way I normally troubleshoot this type of network connectivity is with the SysInternals PortQry.exe utility, which can be downloaded from the Microsoft website. To begin, run the following command to query the RPC Port Mapper on the remote machine, this will return the ports in the ephemeral range that the machine is actively listening on for RPC services:


Querying target system called:

Attempting to resolve IP address to a name…

IP address resolved to DC1.contoso.com


TCP port 135 (epmap service): LISTENING

Using ephemeral source port

Querying Endpoint Mapper Database…

Server’s response:

UUID: d95afe70-a6d5-4259-822e-2c84da1ddb0d


UUID: 50abc2a4-574d-40b3-9d66-ee4fd5fba076


UUID: 897e2e5f-93f3-4376-9c9c-fd2277495c27 Frs2 Service


UUID: 367abb81-9844-35f1-ad32-98f038001003


UUID: c9ac6db5-82b7-4e55-ae8a-e464ed7b4277 Impl friendly name


UUID: 12345778-1234-abcd-ef00-0123456789ac


The output from this command will have an almost overwhelming amount of output.  Within this mountain of data will be just a handful of high-numbered ephemeral ports on which the server is listening.  You are looking for any lines that have “ip_tcp” in them and the ports are in brackets at the end of the line (highlighted in blue above).  This is where we will get a focused list of listening ports from the RPC server to query and validate connectivity. In the abbreviated example above, ports 49664 , 64555, 64502,and 49668 are listening.  Note that 49668 is listed twice.  There will be duplicates that you will have to filter out.

Once you have the full (and de-duplicated) list put together, you can then feed that list of ports back into PORTQRY.EXE to validate that they are reachable over the network. About now, you are probably saying to yourself that’s a  lot of work!  Never fear, I didn’t do this too many times before I decided to automate it in PowerShell.

(Editor.  Queue up Mighty Mouse and “Here I come to save the DAY!”)

RPCCheck.ps1 to the rescue!


Some things to note regarding the script:  It uses PortQry, so make sure you have that installed.  You’ll have to tell the script where the PortQry.exe binary is located by modifying the path on this line of the script: $strPortQryPath = “C:\Sysinternals” Also, the script requires PowerShell v4 since it was written to use WorkFlow and Test-NetConnection, which requires PowerShell v3 & PowerShell v4 respectively.  (PortQry.exe is Free solution you can download from www.sysinternals.com)


At the end of all of this, our family lion of a house cat (rescued from the Humane Society by the way), Roger, was very impressed. You can just imagine in on his face. Ned, in the off chance that you read this, I’m a dog person all the way, but the daughter wanted a cat.  If it helps, I asked for the “most dog-like” cat they had, and Roger doesn’t disappoint.

So that is all there is to pinging available RPC ports with PowerShell and cool Sysinternals tool!  Pop by next week as we into some amazing work with PowerShell and Parallel processes!

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Forum. See you tomorrow. Until then, Keep on Scripting!

Your good friend, Doctor Scripto

PowerShell, Doctor Scripto, Sysinternals, Joel Vickery, RPC, Ping


Leave a comment