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
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 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!
Subscribe to Adam the Automator
Get the latest posts delivered right to your inbox