Before the days of the PowerShell Test-NetConnection cmdlet, we had many different command-line tools we could choose from to troubleshoot various network connectivity issues.
We had ping for testing ICMP echoes and replies; tracert to see where our packets might be getting dropped; nslookup to perform DNS queries against our DNS servers; telnet to check for open TCP ports, and various other utilities. There was a utility for everything.
With the introduction of PowerShell v4 on Windows 8.1 and Windows Server 2012 R2, this single-utility-for-a-single-task approach to troubleshooting connectivity problems has become obsolete.
Allow me to introduce you to the new, all-powerful Test-NetConnection cmdlet. Think of the PowerShell Test-NetConnection as ping, tracert, nslookup, telnet, and a few other utilities wrapped up into one suite of troubleshooting goodness.
Troubleshooting with Test-NetConnection
Let’s see what we can do with the Powershell test-netconnection cmdlet and look at how we can use it when we’re in the unfortunate position of troubleshooting a network connectivity problem.
To demonstrate this, I’m going to use PowerShell Test-NetConnection to troubleshoot a common, real-world problem: “I can’t get to XYZ website!”
What most users don’t know is that successfully rendering a website in a browser is, itself, an amazing feat considering the number of moving pieces that have to work together to make that happen. At a minimum, the process entails:
- Having an internet connection.
- Having a route to your DNS server.
- Contacting the DNS server to resolve the URL.
- Having a route to the IP address the URL resolves to.
- Having TCP port 80 open.
- et cetera, et cetera .
Confirm Your Internet Connection
To begin troubleshooting, you’ll first need to confirm that you have an internet connection. You can do this by simply running PowerShell Test-NetConnection with no parameters at all. However, if you’d like to get more information, I suggest using the InformationLevel parameter with the Detailed argument.
Test-NetConnection -InformationLevel DetailedThis simple command checks your local connectivity and internet connectivity and confirms that your DNS client can resolve names directed at your DNS server all in one shot. Consider it a general health check for your network connection. This command checks three of the five processes needed to render a website in one fell swoop!
Use Test-NetConnection to Test Your Connection to the Website Host
We’ll now need to direct our troubleshooting to the website host in question. Let’s use google.com as an example. You could also use a remote computer too.
We can use Test-NetConnection with the ComputerName parameter to simultaneously ensure that the website host can be resolved in DNS, that there’s a TCP route available to get to the IP address that the name resolves to, and that it can be pinged.
Test-NetConnection -ComputerName google.comEven though this step technically verifies we have a route to the google.com web server, I want to find more detailed information about which routers my packets are flowing through to get to the google.com web server. To do that, I’ll use the TraceRoute parameter to get a list.
Test-NetConnection -ComputerName google.com -TraceRouteEnsure That Your TCP Port Is Open
Our final test is to ensure that the TCP port we’re expecting the web server to be running on is open. In this case, since we’re just specifying google.com, I’m going to assume it is TCP port 80. To do that, we’ll simply add another parameter to Test-NetConnection. Because Test-NetConnection understands the standard TCP port for a few different services, we don’t even need to know the port number. I can just pass HTTP to the CommonTCPPort parameter and it will do the work for me.
Test-NetConnection -ComputerName google.com -CommonTCPPort HTTPHowever, if the website might be running under a different port, such as 8080, you can specify a TCP port directly by using the Port parameter instead.
Test-NetConnection -ComputerName google.com -Port 80We’ve now tested each of the connectivity requirements outlined at the start of this article. If we still can’t render the website at this time, we’ve confirmed the problem does not lie with our client, and we can pass the problem on to Google or perhaps a downstream DNS server.
