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.

PS C:\> ping X.X.X.X

Pinging X.X.X.X with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for X.X.X.X:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

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.

PS C:\> Test-Connection -ComputerName google.com

Source        Destination     IPV4Address      IPV6Address                              Bytes
------        -----------     -----------      -----------                              -----
MACWINVM      www.google.com  172.217.4.228                                             32
MACWINVM      www.google.com  172.217.4.228                                             32
MACWINVM      www.google.com  172.217.4.228                                             32
MACWINVM      www.google.com  172.217.4.228                                             32

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 www.google.com -Count 2 -BufferSize 128 -Delay 3

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.

Test-Connection -Source 'SRV2', 'SRV1' -ComputerName 'www.google.com'

Source        Destination     IPV4Address      IPV6Address                              Bytes    Time(ms)
------        -----------     -----------      -----------                              -----    --------
SRV2    google.com      172.217.7.174                                             32       5
SRV2    google.com      172.217.7.174                                             32       5
SRV2    google.com      172.217.7.174                                             32       6
SRV2    google.com      172.217.7.174                                             32       5
SRV1    google.com      172.217.7.174                                             32       5
SRV1    google.com      172.217.7.174                                             32       5
SRV1    google.com      172.217.7.174                                             32       5
SRV1    google.com      172.217.7.174                                             32       5

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

PS> Test-Connection -ComputerName google.com -Quiet
True

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.

PS C:\> Test-NetConnection -ComputerName www.google.com

ComputerName           : www.google.com
RemoteAddress          : 172.217.9.68
InterfaceAlias         : Ethernet 2
SourceAddress          : 192.168.86.26
PingSucceeded          : True
PingReplyDetails (RTT) : 54 ms

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.

PS C:\> Test-NetConnection -ComputerName www.google.com -Port 80

ComputerName     : google.com
RemoteAddress    : 172.217.5.238
RemotePort       : 80
InterfaceAlias   : Ethernet 2
SourceAddress    : 192.168.86.26
TcpTestSucceeded : True

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

Subscribe to 4sysops newsletter!

PS C:\> Test-NetConnection -ComputerName google.com -TraceRoute


ComputerName           : google.com
RemoteAddress          : 172.217.5.238
InterfaceAlias         : Ethernet 2
SourceAddress          : 192.168.86.26
PingSucceeded          : True
PingReplyDetails (RTT) : 44 ms
TraceRoute             : 192.168.86.1
                         192.168.0.1
                         142.254.146.117
                         74.128.4.113
                         65.29.30.36
                         65.189.140.166
                         66.109.6.66
                         66.109.6.30
                         107.14.17.204
                         216.6.87.149
                         72.14.198.28
                         108.170.240.97
                         216.239.54.125
                         172.217.5.238

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.

11 Comments
  1. Raj 3 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 3 years ago

      Try Get-NetTCPConnection.

      avatar
  2. David 3 years 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.

      https://www.itprotoday.com/strategy/tcp-vs-udp-ports

      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.

      avataravatar
      • David 3 years 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
        https://learn-powershell.net/2011/02/21/querying-udp-ports-with-powershell/

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

        avataravatar
        • 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.

          avatar
          • David 3 years 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 2 years 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?

    avatar
  4. Rugbyball 6 months ago

    Is there a way to set the Count in Test-NetConnection like you can in Test-Connection ?

    I only want Test-NetConnection to do one test, it looks like it does 3 tests when it can't connect. I understand why, incase there is an issue with the first test. But it would be helpful to have a -Count for Test-NetConnection for those who want more tests done or less.

    Meaning:

    Test-Connection -ComputerName google.com -Count 1 -quiet
    
    Test-NetConnection -ComputerName "google.com" -Port 3389 -InformationLevel Quiet

    • Leos Marek (Rank: 4)
      6 months ago

      The answer is no 🙂 The cmdlet first tests the port specified, which is relatively quick, but then it tends to do ICMP test which cannot be limited.

  5. Alex Pereluka 5 months ago

    psping.exe from SysInternals helps to check latency by using a custom TCP port instead of ICMP when the latter is blocked. Please see an example below.

    How that can be accomplished with PowerShell when psping.exe is not available and not allowed to be downloaded?

    PS P:\> psping http://www.google.com:443

    PsPing v2.01 - PsPing - ping, latency, bandwidth measurement utility
    Copyright (C) 2012-2014 Mark Russinovich
    Sysinternals - http://www.sysinternals.com

    TCP connect to 2607:f8b0:4007:811::2004:443:
    5 iterations (warmup 1) connecting test:
    Connecting to 2607:f8b0:4007:811::2004:443 (warmup): 24.19ms
    Connecting to 2607:f8b0:4007:811::2004:443: 19.59ms
    Connecting to 2607:f8b0:4007:811::2004:443: 24.81ms
    Connecting to 2607:f8b0:4007:811::2004:443: 20.24ms
    Connecting to 2607:f8b0:4007:811::2004:443: 17.57ms

    TCP connect statistics for 2607:f8b0:4007:811::2004:443:
      Sent = 4, Received = 4, Lost = 0 (0% loss),
      Minimum = 17.57ms, Maximum = 24.81ms, Average = 20.55ms

Leave a reply to Justin Click here to cancel the reply

Please enclose code in pre tags

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

*

© 4sysops 2006 - 2021

CONTACT US

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

Sending

Log in with your credentials

or    

Forgot your details?

Create Account