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.
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.
Table of Contents
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
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!
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.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.
More from Adam The Automator & Friends
Find out how many of your Active Directory users are using leaked passwords by running a free read-only scan with Specops Password Auditor.
Do more with PowerShell and transform your Code to Self Service with au2mator Self Service Portal
Why not write on a platform with an existing audience and share your knowledge with the world?