I get it. As a device management utility, Telnet needs to go away. I guess that’s why, starting with Server 2008 and Vista, Microsoft decided to stop installing Telnet by default on its operating systems. While the little white angel on my shoulder says, “Great! One less insecure protocol to worry about,” the little devil on the other shoulder screams, “Terrible! What a pain!” (Or, as Paul would say: “Bloody awful!”)
It’s true, not having Telnet on a server or workstation when you are troubleshooting a communications problem can be a real pain. How many times has a quick Telnet command to query for a listening TCP/IP service saved you valuable troubleshooting time? Me too! Sure, you can go through the hassle of installing the Telnet client, but what if you don’t have privileges to do so? Or maybe the server’s owner doesn’t want you mucking around like that. What then?
Lately, I’ve been using Microsoft’s PortQry tool to solve my “’telnet’ is not recognized as an internal or external command…” woes. No installation needed. Download the package from Microsoft, extract it, and execute the PortQry.exe from a Command Prompt or PowerShell session. I keep a copy of PortQry.exe on the C: drive of the computers from which I do most of my management so that I can quickly access it from the Remote Desktop session client-drive mapping.
Want to know if your web server is listening? (PortQry defaults to TCP port 80.)
PortQry.exe –n hostname
Not sure if you need to request a firewall rule for the Bacula client on a new server?
PortQry.exe –n hostname –p tcp -e 9102
Don’t stop there. Those sneaky engineers at Microsoft stuffed in a bunch of other functionality that goes well beyond your beloved Telnet.
Maybe your web server is supposed to be listening for HTTPS requests also.
PortQry.exe –n hostname -o “80,443”
Not sure if your client is able to talk to the directory on your domain controller (or another LDAP, for that matter)? Not only will you find out if something is responding on that port, but PortQry sends an LDAP query and returns the results if an LDAP server responds.
PortQry.exe -n hostname -p udp -e 389
You get the idea. The above examples are just a few of the many scenarios where PortQry may come in handy. I’ve seen several Microsoft articles that discuss using PortQry for troubleshooting Active Directory, Exchange, and others. PortQry will return a LISTENING if something is listening on the target port and a NOT LISTENING or FILTERED if nothing is listening on the port or your request never reached its destination. The distinction between NOT LISTENING and FILTERED can be helpful in determining whether the target service is simply not running, or whether a firewall is blocking your request.
PortQry is not the only tool available on the Windows platform with this kind of functionality. The venerable Unix utility Netcat has been ported to Windows by a few different people. Unfortunately, Netcat is often flagged as malicious by anti-malware programs, and some of the Netcat implementations for Windows require Cygwin. Ned pointed me to Ncat, a Netcat incarnation that is included with the popular Nmap utility. While you don’t have to bother with Cygwin, Ncat uses the libraries included with Nmap and may require some work to make it into a standalone executable. The thing I like most about PortQry is that you can simply copy the PortQry.exe to any Windows computer and execute it.
Finally, for those of you who prefer a GUI, Microsoft even released PortQryUI.