- Create a certificate-signed RDP shortcut via Group Policy - Fri, Aug 9 2019
- Monitor web server uptime with a PowerShell script - Tue, Aug 6 2019
- How to build a PowerShell inventory script for Windows Servers - Fri, Aug 2 2019
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
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.
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.
Try Get-NetTCPConnection.
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
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.
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.
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.
"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?
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:
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.
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
Is there any way that i can use powershell or powercli to test if port open or not and then tell where packet gets dropped and what is the interface ip