Many IT pros are quite proficient with Telnet and use that tool adroitly in testing and troubleshooting ports and connectivity. However, Telnet has its limitations for port testing. A major limitation is the inability of Telnet to determine whether the port is being filtered. Plus, Telnet is unable to test UPD traffic like LDAP or RPC. That is where Portqry.exe comes into the picture. Microsoft has developed this utility to aid in troubleshooting connectivity issues by allowing for better scanning of ports. Here’s how to unleash the power behind this utility.

A direct approach
Portqry.exe is actually a pretty straightforward tool. Once you learn the syntax and see a few basic usage examples, you will be ready to use it.

When you run the portqry command, this tool will report the status of the port on a particular host in one of three forms:

  • ·        Listening: When you receive this status back, it means that there is a process listening on the port you specified on your target host.
  • ·        Not Listening: A node reporting this status type indicates that there is no process listening on that port on the target computer.
  • ·        Filtered: The ability to report whether a target computer is filtering out a specific port is where Portqry.exe has a leg up on other similar utilities. Most utilities would simply report Not Listening if filtering is occurring, but not Portqry.exe. It will query a port up to three times to determine the correct status.

How to use the utility
As with any command line utility, syntax is paramount. Here are the various switches you can pass this utility from the command line:

  • ·        -n [server] IP address or name of server to query
  • ·        -p [protocol] TCP or UDP or BOTH (default is TCP)
  • ·        -e [endpoint] single port to query (valid range: 1-65535)
  • ·        -r [end point range] range of ports to query (start:end)
  • ·        -o [end point order] range of ports to query in an order (x,y,z)
  • ·        -l [logfile] name of log file to create
  • ·        -s “slow link delay” waits longer for UDP replies from remote systems
  • ·        -i bypasses default IP address-to-name lookup; ignored unless an IP address is specified after -n
  • ·        -q “quiet” operation runs with no output

Next, we’ll look at some examples of how you might put the above variables together in a command that can execute various options.

Determine whether SMTP is available on a node
If you want to verify that the SMTP protocol is running on an Exchange Server, you could issue the following iteration of Portqry.exe to ascertain its status:
portqry -n YourNode -p tcp -e 25

In the above command sequence, you are telling the program to verify that YourNode (-n parameter) is listening on TCP (-p parameter followed by tcp) port 25 (specified by the –e parameter and then the port number). If you were to issue this command against a node actually running SMTP, then the following response would be returned to you:
TCP port 25 (SMTP service): LISTENING

In addition, the port would return data similar to the following:
220 YourNode domain.com Microsoft ESMTP MAIL Service, Version: 5.0.2195.2966 ready at date and time -0900

If SMTP is not listening, it would return this data:
TCP port 25 (SMTP service): NOT LISTENING

Determine whether LDAP is available on a node
Because Telnet cannot easily test for UDP-based ports, Portqry.exe becomes a viable asset if, for instance, you want to test for LDAP availability on a node. For example, if you wish to verify connectivity from a client to an Active Directory domain controller, you could issue the following command from the client:
portqry -n yourserver.domain.com -p udp -e 389

In this case, the –n identifies your server, the –p identifies your protocol (in this case, UDP), and the –e signifies an endpoint or the port you specifically want to query (LDAP in this example, over port 389). The response you could receive back might look like Listing A.

A useful trick
As with any tool, it’s always nice to know what unique things you can do with it (outside the standard usage). One the cool things that I found was that Portqry.exe uses a Services file located in the %systemroot%\system32\drivers\etc directory (every Windows 2000 and Windows XP system has one of these). Portqry.exe uses this file to resolve the port numbers entered by the user to their corresponding service names; hence the contents of this file control to which ports Portqry.exe sends its messages. Now, if you happen to have a protocol that is not using its conventional port, you can simply edit this file and provide the port you need by adding or changing the port number resident in the file.

What it cannot do
Just like any utility, Portqry.exe has its limitations. While it is uniquely designed for port verification, it is a little slow. Microsoft makes it very clear that this tool is not a “security verification tool,” but rather it is a troubleshooting tool, much like Ping, Traceroute, and other built-in Windows network utilities.

A handy tool for verifying port status
All in all, this little utility is a nice tool for a network admin to have available. You probably will not need to use it to the level that you might use Ping or Ipconfig, but nevertheless it has its uses and is a great tool to have in your repertoire when you need to verify whether a port is open, closed, or being filtered.