Test-NetConnection vs. Test-Connection - Testing a network connection with PowerShell

Ultimately, there's going to come a time when a server goes offline from the rest of the network, and it'll leave you scratching your head wondering why. If it's because of a firewall, a bad network interface controller (NIC), or some other network connectivity issue, PowerShell's cmdlets Test-NetConnection and Test-Connection allow you to test the network connection.

Before we get into the fancy PowerShell commands though, do you remember good ol' ping.exe? That utility is in every sysadmin's toolbelt. The ping utility tests a server's network connection using ICMP. Responding to ICMP doesn't always mean a server is "up," but it's better than nothing!

For example, I have an Azure virtual machine online but with its network security locked down. If I used ping.exe against it, you'd think it's offline.

I know this virtual machine is online—it's just blocking ICMP. How else can we test network connectivity? How about using the PowerShell version of ping, the Test-Connection cmdlet? In my case, I get an obscure error message "error due to lack of resources." This is because I'm pinging an IP address, and Windows Management Instrumentation (WMI) isn't available on this remote computer.

Testing a network connection with PowerShell

Testing a network connection with PowerShell

However, when attempting to use Test-Connection against google.com, for example, all looks well.

The Test-Connection cmdlet has a few different parameters you can use to tailor your query to your liking. For example, you can change the buffer size and define the amount of seconds between the pings. The output is the same, but the request is a little different.

Test-Connection also can reach out to remote computers and ping a remote computer as well. Granted, you will need to have access to the remote computers to do this.

Is the output too much, and you're just looking for a binary yes or no? No problem—just use the -Quiet parameter.

PowerShell also has another excellent command to test network connectivity called Test-NetConnection. Test-NetConnection is the successor to Test-Connection and provides a lot of different ways to check network connectivity from a lot of various angles.

At its basic level, it merely needs a value for the -ComputerName parameter.

Unlike Test-Connection though, Test-NetConnection can test whether ports are open. In the example below, I'm checking to see if port 80 is open. As expected (since I'm testing google.com), port 80 is open, since TcpTestSucceded equals True.

Remember tracert? We don't need that old-school utility anymore either. We now have the -TraceRoute parameter on Test-NetConnection!

Test-NetConnection has quite a few other parameters that allow you to test many different situations. If you had to pick only one command to do this, pick Test-NetConnection. Sometimes it won't be available if you're using an old version of PowerShell, but it is more feature rich and allows more control over how to craft requests to remote computers than Test-Connection.

Join the 4sysops PowerShell group!

Your question was not answered? Ask in the forum!

  1. Raj 2 years ago

    Would you know if there is a way to check port listening vs. port open? PortQuery tool has this feature and is useful to test open ports to a new server before you install software. PortQuery shows FILTERED if port is closed otherwise LISTENING or NOT LISTENING.


    • Justin 1 year ago

      Try Get-NetTCPConnection.

  2. David 1 year ago

    I don't understand why they don't allow us ability to test UDP ports.  Will that be supported in the future?


    • It is due to nature of how UDP works. There is no response in UDP communication so you cant test it this way.


      UDP is a connectionless protocol that runs on top of IP (UDP/IP), and TCP is a connection-oriented protocol that runs on top of IP (TCP/IP). Connectionless means that a host can send a message to another host without first establishing a connection with the recipient. The host simply puts a message onto the network with a destination address and hopes that the message arrives. In addition, the transmission or receipt of a UDP packet doesn't guarantee any further communication in either direction.

      • David 1 year ago

        I understand UDP is spray and pray.  I'm curious how portqry.exe is able to test UDP ports then.

        Also it appears there is a way to do it in powershell by calling system.Net.Sockets.Udpclient

        I just wish they would build this feature into Powershell test-netconnection.  I someone could do it since Microsoft opensource their cmdlets.

        • UDP port scanning is based on negative scanning i.e. for a sent packet if no response is received, it is assumed that port is open and the server has accepted the packet(No ACK in UDP). And if the port is closed, server replies with ICMP 'Destination Port Unreachable' packet, implying port is closed. However, this inference is largely affected by factors such as ICMP packet drop in firewall or IDS, Or insufficient UDP protocol buffer in the target system. And thus this unreliability factor makes it difficult to use And could probably be the reason for not getting included in PS cmdlet.

          • David 1 year ago

            Thanks for clearing that up.  Makes sense now if it's unreliable.  I still think it's worth adding in if it does work for many users but I guess it's not my call and its low priority.


  3. Sam 10 months ago

    "This is because I'm pinging an IP address, and Windows Management Instrumentation (WMI) isn't available on this remote computer.". Has google.com WMI installed?


Leave a reply

Your email address will not be published. Required fields are marked *


© 4sysops 2006 - 2020


Please ask IT administration questions in the forums. Any other messages are welcome.


Log in with your credentials


Forgot your details?

Create Account