How to Troubleshoot Like a Champ with Test-NetConnection

While working with a colleague the other day, we were troubleshooting a connection between devices. We tried a basic ‘ping‘ and it didn’t work, so he said we might need to try ‘tnc‘ instead. I then switched to PowerShell and tried a Test-NetConnection and we were able to verify that the devices could talk, but ‘echo’ was turned off.

My colleague then indicated to me that I wouldn’t believe how many people don’t know what Test-NetConnection is or how it works. I was surprised, as I use it all the time. I then asked my guys on the Service Desk, and none of them knew about it either. That is when I realized I hadn’t taught them about Test-NetConnection, a tool that I use regularly.

After spending some time in the IT field, you tend to develop some tricks of the trade for testing and troubleshooting things. It’s just part of the job. You learn something that helped, and you try to apply it to multiple situations to see where else it can help. I find that the more time I spend in PowerShell the more beneficial it is, and the more I tend to go to that first. Leaning towards a PowerShell first approach has helped me develop these skills faster because things start to become second nature.

The goal here today is to demonstrate the value of Test-NetConnection and hopefully educate a few others in this awesome tool.

DISCLAIMER

Please understand that the content herein is for informational purposes only. This existence and contents shall not create an obligation, liability or suggest a consultancy relationship. In further, such shall be considered as is without any express or implied warranties including, but not limited to express and implied warranties of merchantability, fitness for a particular purpose and non-infringement. There is no commitment about the content within the services that the specific functions of the services or its reliability, applicability or ability to meet your needs, whether unique or standard. Please be sure to test this process fully before deploying in ANY production capacity, and ensure you understand that you are doing so at your own risk.

Table of Contents

Benefits over ‘PING’
Basic Use of Test-NetConnection
Conclusion


Benefits over ‘PING’

PING has been around a long time, and since I’m not a gray beard nor am I a ping expert, this isn’t going to be a history lesson. All that you really need to know is that a PING is an ICMP packet that is sent to a destination. The destination, if configured to respond to ICMP packets, will send a response. The ping process then measures how long it took to be accepted and respond and will indicate if it is unsuccessful.

PING has two major disadvantages in modern networking:

  • Not protocol specific – meaning can only test basic connectivity.
  • Must be enabled – meaning it doesn’t work unless the device or firewall is configured to respond to it.

Don’t get me wrong, PING is a valuable tool for a quick test that is easy to remember and effective to see if something is up or not. However modern security practices mean that a PING may not be a true indicator of status, and over-reliance may lead to mistakes.

Advantages of Test-NetConnection

When you need some more advanced troubleshooting for connection issues, Test-NetConnection is the superior tool. Here are a few of my favorite reasons why I believe this:

  • PowerShell is Object-Oriented
    • Since PowerShell will return the results as an object rather than as console output, that means that the results have meaning, and can be stored to a variable. This is great for scripting or sorting results. This also means it works great with Flow Control techniques like while-loops and for-loops. This reason alone is enough to make me switch in most cases.
  • Test-NetConnection includes Common Protocols and Ports
    • Just because a device responds to a PING, doesn’t mean that you can connect to it with any other device. If a device requires connection over a specific port or protocol, a PING isn’t going if the local firewall is blocking that connection. Test-NetConnection however lets you test specific ports and common protocols with an additional switch. If you are wondering if someone’s device can access a network file share, you can use Test-NetConnection with the -CommonTCPPort switch, and then indicate SMB to test access to that share.
  • Test-NetConnection includes Routing Information
    • Unlike PING, (which requires a separate command), Test-NetConnection allows you to also test routing and provide basic diagnostics while you are testing connectivity. This is an excellent combination of two tools that are frequently used together while also adding more information than they would on their own.

When it comes to a basic test to see if something is available and responding, a PING might be enough. However, it only takes taking down a server because of an IP address conflict once to help you understand that PING isn’t always enough. Let’s go over some examples for usage.


Basic Use of Test-NetConnection

There are several basic examples to cover for Test-NetConnection. The full list of switches and flags can be found in Microsoft’s documentation, so I won’t cover everything here. I’m just giving some basic examples to get you started.

Basic Connectivity Test for a Single Host

PS C:\> Test-NetConnection

ComputerName           : internetbeacon.msedge.net
RemoteAddress          : 13.107.4.52
InterfaceAlias         : Wi-Fi
SourceAddress          : 192.168.10.182
PingSucceeded          : True
PingReplyDetails (RTT) : 36 ms

When you run just the Cmdlet alone, it has a built-in test to see if you have internet connectivity. This can be an excellent first step just to make sure that your connectivity issues aren’t with the device you are working on. This use is the same as the PowerShell version of a PING, so you could use this as a basic connectivity test in the early part of a script but be able to save the result to a variable for use later.

Test Connection to Internal Website

PS C:\> Test-NetConnection -ComputerName 192.168.10.230 -CommonTCPPort HTTP

ComputerName     : 192.168.10.230
RemoteAddress    : 192.168.10.230
RemotePort       : 80
InterfaceAlias   : Wi-Fi
SourceAddress    : 192.168.10.182
TcpTestSucceeded : True

In this case, you may need to check connection to an internal website or web server. Adding the -CommonTCPPort flag allows you to specify HTTP and perform a connection specifically over known port 80. While there is no “CommonTCPPort” for HTTPS, you can perform that check with -Port instead and specify 443.

PS C:\> Test-NetConnection -ComputerName 192.168.10.230 -Port 443

ComputerName     : 192.168.10.230
RemoteAddress    : 192.168.10.230
RemotePort       : 443
InterfaceAlias   : Wi-Fi
SourceAddress    : 192.168.10.182
TcpTestSucceeded : True

The key thing to note here is that the “TcpTestSucceeded” property came back as TRUE. When scripting this check (or just using this Cmdlet), this will be what you will be looking for to tell if it was successful.

Test Routing to Device or Website

#####################################################################################

#PowerShell TraceRoute to Google.com
PS C:\> Test-NetConnection -ComputerName google.com -TraceRoute

ComputerName           : google.com
RemoteAddress          : 142.250.191.238
InterfaceAlias         : Wi-Fi
SourceAddress          : 192.168.10.182
PingSucceeded          : True
PingReplyDetails (RTT) : 35 ms
TraceRoute             : 192.168.10.1
                         X.X.X.X
                         X.X.X.X
                         X.X.X.X
                         0.0.0.0
                         0.0.0.0
                         X.X.X.X
                         X.X.X.X
                         X.X.X.X
                         X.X.X.X
                         142.250.191.238

#####################################################################################

#Route Diagnostics test from Test-NetConnection
PS C:\> Test-NetConnection -ComputerName google.com -diagnoseRouting

ComputerName              : google.com
RemoteAddress             : 142.250.190.78
SelectedSourceAddress     : 192.168.10.182
OutgoingInterfaceIndex    : 19
SelectedNetRoute          : DestinationPrefix: 0.0.0.0/0
                            NextHop: 192.168.10.1
RouteDiagnosticsSucceeded : True


In these examples, we’re looking at ways to test routing between two points. The first option is like a traditional traceroute command, except that it can be saved to a variable (a common thing here) and have its data retained. The second example is a simplified version that will test routing but not display every hop.

These can be useful if you need to troubleshoot high latency, or if you are logging the routes to see if it is changing. For example, if you have intermittent latency, your carrier may be having issues that results in abnormal routing. The only way you would be able to identify this is by regularly running and logging this command. Not a common use case, but it is just an example to demonstrate one possible use case.


Conclusion

There you have it. Some basic examples for one of my favorite Cmdlets. I’m a big believer in knowing some kind of scripting language for system administrators, and PowerShell is my weapon of choice. Once you get used to the Object-Oriented way PowerShell works, you start to realize how nice it is when you need to include things like this into your scripts. Having modern examples of ‘old-school’ tools keeps your abilities sharp and allows you to do more to incorporate them into your work.

Not to mention, you can be much more confident that you aren’t going to cause an IP address conflict when you are out there winging it! (Let’s be honest, we’ve all done it…). Next time you will be more prepared and can avoid those situations all together. I think this is a helpful tool for a new Help Desk person or Jr System Administrator. If you know one who might benefit, please share this with them.

As always, let me know what you think and if this worked for you. Hit me up on Twitter @SeeSmittyIT to let me know what you thought of this post. Or if you are avoiding the bird site, I’m also posted up on Mastodon @[email protected]. Thanks for reading!

Smitty

Curtis Smith works in IT with a primary focus on Mobile Device Management, M365 Apps, and Azure AD. He has certifications from CompTIA and Microsoft, and writes as a hobby.

View all posts by Smitty →