Before the days of PowerShell's 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 cmdlet that is PowerShell Test-NetConnection. Think of PowerShell Test-NetConnection as ping, tracert, nslookup, telnet and a few other utilities wrapped up into one suite of troubleshooting goodness.

How to Troubleshoot a Network Connectivity Problem 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 Detailed

This 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!

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. 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.com

Even 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 -TraceRoute

Ensure 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 HTTP

However, 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 80

We'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.

Join the Jar Tippers on Patreon

It takes a lot of time to write detailed blog posts like this one. In a single-income family, this blog is one way I depend on to keep the lights on. I'd be eternally grateful if you could become a Patreon patron today!

Become a Patron!