Version 2.0 adds some enticing functionality
You've probably heard of Portqry (portqry.exe), a useful tool for port scanning that Microsoft released a year or two ago. With the following Portqry command, you can—for example—test whether a computer named www.bigfirm.biz runs a Web server on port 80:
portqry -n www.bigfirm.biz -e 80
In that command, the -n option tells Portqry to test a machine named www.bigfirm.biz and the -e option says to test port 80. (Alternatively, you can use the -r option to specify a range of ports to test or the -o option to specify a list of ports.) If Portqry finds a Web server at port 80, you'll get a response such as TCP port 80 (http service): LISTENING. You might also get NOT LISTENING, which means nothing is running on that port, or FILTERED, which means some kind of firewall is blocking your ability to scan port 80 on that system.
In December 2003, Microsoft released Portqry 2.0, which offers some new features worth looking at. Enhancements include an interactive mode (similar to that of Nslookup), the ability to track all ports associated with a particular process, and firewall compatibility.
Let's take a look at the tool's interactive mode. Portqry is a helpful tool, but it often requires you to type long commands. My example above is just about the shortest useful command that you could use in the older version of Portqry. Many users don't enjoy memorizing a string of options and prefer to construct their query a bit at a time. Suppose I wanted to test port 25 on www.bigfirm.biz and couldn't remember the -n and -e options. With Portqry 2.0, I could simply type
to start Portqry in what you might call "training-wheels mode." A prompt would then let me specify the machine to query by typing
and pressing Enter. Next, I'd specify the port to query by typing
and pressing Enter. Finally, I'd execute the query by typing q and pressing Enter. If I wanted to test port 25 on another system, I'd need only to specify a new target with the Node command and execute the query by typing q and pressing Enter.
Portqry 2.0 also has a local mode that lists all the TCP and UDP ports on which your system is listening. You might respond by saying that Netstat -a has always given you this functionality, but Portqry offers a lot more information. On a Windows Server 2003 or Windows XP system, you'll see a complete list of all the running processes, as well as any ports those processes are using. Netstat -ano offers this kind of functionality by showing each listening port and the process ID of the program that opened the port, but knowing only the process ID doesn't help much. Knowing that the process with ID 4119 is doing something mysterious on a port that you don't recognize still leaves this question unanswered: "Which process has process ID 4119?" You then have to use Task Manager or another utility to look up the process. Portqry -local saves you a step by showing not only the process ID but also the process's name.
Let me briefly discuss some other Portqry 2.0 features. The new -wpid and -wport options let you tell Portqry to continually monitor a particular port or all ports associated with a particular process, respectively. Unlike other Portqry options—which essentially take a snapshot and exit—the -wpid and -wport options let Portqry watch and report on changes in activity. Both options require Windows 2003 or XP. Finally, folks wanting to test firewalls will appreciate that Portqry 2.0 lets them specify the port from which they'll be querying. Suppose I want to query www.bigfirm.biz's port 80 from port 5000 on my system. Portqry 2.0 lets me use the -sp option to do so:
portqry -n www.bigfirm.biz -e 80 -sp 5000
I've found the original Portqry quite useful, and I'm already finding uses for Portqry 2.0. For further information about Portqry 2.0, as well as download instructions, see the Microsoft article "New features and functionality in Portqry version 2.0" (http://support.microsoft.com/?kbid=832919). I think this tool will become an important part of your toolkit.