Microsoft continues to add functionality to PowerShell, however unless you specifically keep up with PowerShell, you’re unlikely to realize what these updates are and how convenient they make life (compared to the previous/status quo).
When testing TCP port connection, most people think immediately of telnet. While it works OK to let you know if a port is open (instant connect), closed (instant fail) or blocked (timeout), it is not ideal because you either need to use a lightweight portable app or (most likely) install the feature in Windows. But then you need to remember to go back and uninstall it when you’re done… which sometimes falls through the cracks. Unless you’re OK with leaving it there or even incorporating it in your build (which I have seen done before).
Well, MS now has a solution for this and it is called Test-NetConnection. It was introduced in PowerShell 4.0 and Windows 8.1/2012R2. Admittedly, I did not even know about it until Windows 2016 came out; and still it took time to break the habit of pulling up CMD prompt and running Telnet.
You do not need to install anything to make it work because it is not part of a CMDlet that you need to import. You can simply just run the command:
test-netconnection -computer <hostname or IP> -port <tcp port>
You can also specify an information level (quiet to return Boolean value of true or false if it works; detailed to include more info):
test-netconnection -computer <hostname or IP> -port <tcp port> -informationlevel {Detailed | Quiet}
The informationlevel parameter could be very helpful when writing a script that attempts multiple connections and then stores the result. (i.e. loop through a range of IPs or hostnames and/or ports).
But wait, it gets better! Remember how much of a pain it is to troubleshoot RPC ports? You could only test telnet to port tcp-135, and not simulate the full RPC protocol by testing a port to open in the RPC range for the session. Not anymore:
test-netconnection -computer <hostname or IP> -commontcpport WINRM
You can also specifically test the following protocols: HTTP, SMB, RDP & (WinRM). Helpful, huh?
It gets better. You can also use this command to replace ping and traceroute. No more having to write powershell scripts that run a ping or tracert that then have to intelligently parse the results and store them. Instead, you can use:
test-netconnection -computer <hostname or IP>
test-netconnection -computer <hostname or IP> -traceroute
For a full diagnostic of routing, you can also use:
test-netconnection -computer <hostname or IP> -diagnoserouting
If you have multiple interfaces on your source machine, you can even provide a specific interface as the source (if you don’t know which interface is numbered which, you can use the get-netconnectionprofile to find out):
test-netconnection -computer <hostname or IP> -diagnoserouting -constraininterface <interface #>
Remember that you can always adjust your information level by specifying -informationlevel {Quiet | Detailed}!
Have fun! And remember, you should use this instead of PING, TRACERT, and TELNET 🙂 You can rest easy knowing that you don’t have to go back and uninstall Telnet or Portqry after a long day of troubleshooting.
BTW – you can use the abbreviation tnc instead of spelling out test-netconnection if you like using the bare minimum keystrokes like me.
Never A Null Moment 