3 Best PowerShell Cmdlets for Testing Connectivity

When managing a Windows environment some sysadmins tend to underestimate and maybe even take for granted the underlying layers on which they so freely work on and with to bring home the bacon. Most would probably admit that they sometimes forget about the foundational OSI model that they learned in the very beginning of their educational journey into the world of IT support and/or development. Each layer depends so much upon the underlying layers that when one fails or does not perform as designed, things can get chaotic quickly.

There are some foundational PowerShell cmdlets that not only pay homage to those layers in how they are used to accomplish a variety of objectives. These few cmdlets are going to be your go-to when it comes to troubleshooting, automation, or script creation.

Remember the OSI Model?

Some may have to think back pretty far to remember the Open Systems Interconnection (OSI) model, but the fundamental truths that it teaches are as relevant today as it was back then, even if it's forgotten. By way of review, the seven layers are as follows:

1. Physical

2. Data Link

3. Network

4. Transport

5. Session

6. Presentation

7. Application

The model, from a high level, is centered around communication. In this case, the communication between computers. In order to properly accomplish the work of supporting technology infrastructure and operations, having a healthy understanding of this model and striving for ultimate efficiency at each layer only allows for more overall performance improvements and the ability to adapt to the ever-changing pace of computing. In fact, Amazon Web Services requires a very deep understanding of this model even today. In short, the more it is understood how things communicate, the easier it is to manage, plan, and troubleshoot.

1. Starting with Get-NetAdapter

When it comes to understanding how the local station can talk to other devices on the local network, it's important to at least know how to quickly get the information needed about how the network adapter is configured. You may need to know the IP address, MAC address, interface name, or other extended properties. Get-NetAdapter is a PowerShell cmdlet that can provide a trove of this information for the local adapters. Though Microsoft Docs claims this cmdlet, "Gets the basic network adapter properties," the amount of information it gathers doesn't seem so basic.

When Get-NetAdapter is input by itself in a PowerShell console without any parameters or switches, it gathers just a few pieces of information about all the installed physical and virtual network adapters, and formats the columns as such:

Name          InterfaceDescription  ifIndex        Status  MacAddress        LinkSpeed

——   ——————————  ———-  ———  —————    ————-

These six pieces of information are just the default format and items Get-NetAdapter returns. To see all the information about all the installed adapters, just pipe the cmdlet to a Select-Object * and you will see everything it has to offer for each installed adapter:

Get-NetAdapter | Select-Object *

To get the properties of just one of the adapters after running the standalone Get-NetAdapter cmdlet to get the quick listing, filter to the desired adapter by name or ifIndex like so:

Get-NetAdapter -ifIndex 15 | Select-Object *

Just a few of the properties that may be of use when running Get-NetAdapter:

• MAC Address

• Status

• LinkSpeed

• DriverDescription

• MediaConnectionState

Some of these will certainly be useful when it comes to ensuring that the local workstation can properly communicate with other network devices in order to accomplish the work at hand.

2. Ways to Utilize Test-NetConnection

Now that homage has been properly paid, how can PowerShell be used to gather information from the underlying layers in order to accomplish a task? Test-NetConnection, according to Microsoft Docs, "Displays diagnostic information for a connection." A very short and simple description, but the cmdlet is filled with many layers of information. It should be understood that Test-NetConnection evaluates the network communication between the local host and another host. Run by itself with no parameters or switches, it will essentially send and echo request (ping) to a default server, most likely a Microsoft Edge server on the internet:

ComputerName           : internetbeacon.msedge.net

RemoteAddress          : 13.107.4.52

InterfaceAlias         : Local Area Connection 3

SourceAddress          : 10.125.127.10

PingSucceeded          : True

PingReplyDetails (RTT) : 54 ms

To run the diagnostics against a remote host on the local network, just use the -ComputerName parameter and use the DNS name, FQDN, or IP address as the value and the diagnostics will run against that remote host and return the results and information. It is also possible to get some more or less detail of the connection by using the -InformationLevel parameter. To get some more details, use -InformationLevel "Detailed". The output will be just a tad more information about the connection. -InformationLevel "Quiet" will return a Boolean (True/False) output on whether the local station can ping the remote host. This line alone would be very helpful when attempting to run actions against remote hosts in that it can be used to ensure a host is online before attempting to run the actions.

3. Using Test-Path for Validations

Shifting gears a bit and moving to another layer of the OSI stack, when it comes to using PowerShell to validate the existence of an object, Test-Path will be an important part of making these validations. Ultimately, the output of the Test-Path cmdlet is very humble. It will simply always return a Boolean (True/False) value. Though the output isn't much, the usefulness of Test-Path is exponential.

Think of Test-Path as asking the question, "Does this exist?" This not only applies to files on a local computer, but also files, folders, registry keys, and many other objects on the local and remote hosts. To check for a file named MonthlyReport-August.pdf, on the share Reports on the server FS01:

Test-Path -Path \\FS01\Reports\MonthlyReport-August.pdf

This outputs either a True or False value depending on if that file exists. Not only does Test-Path help in scouting the existence of that particular file, it also is testing the existence of each part of the -Path value. If, for some reason, the Reports share doesn't exist on FS01, this command would return a False output. Therefore, it's worth knowing that a True output is not just validating the file in this case, it is also validating the entire path that was given.

To verify the existence of a folder, whether local or a network share using the input would be:

Test-Path -Path \\FS01\Reports

Test-Path -Path C:\Applications

This can also be used to validate the existence of registry keys. This could be used especially for checking specific configurations on a local computer. For instance, to check for the registry key:

 Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell

Test-Path -Path “HKLM:\Software\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell”

According to Microsoft Docs, they note that Test-Path can be used to find registry keys, but not registry entries. There are other ways to find entries and their respective values, but that is outside the scope of this post. It should also be noted that Test-Path works well locally, but there are some added layers and other cmdlets to find these same keys and entries on remote computers.

This said, Test-Path can be very useful when designing scripts and automated workflows utilizing PowerShell. Coupled with if/then statements, the output of Test-Path can be used to determine the flow of a script or scheduled task based on the desired outcome of the task at hand. One example that could be used is checking for the existence of an installed application. If the application you are checking for creates a specific folder in a predictive location, using Test-Path to check for that folder could be a quick and dirty way of making this validation.

Final Thoughts

Though the OSI model is quite aged, its relevance is as important today as it was when it was conceived. We tend to think about only what we see in front of us. But as we all know, the more we understand about the layers beneath what we manage the more efficient and productive we can become in our specific roles.

Test-Path isn't nearly as useful if your local station cannot communicate with the other hosts on the network. The communication layers beneath the GUI allow us to do all the fancy things we do on the surface. Get-NetAdapter and Test-NetConnection are just a small slice of peering beneath the GUI to see the inner-workings of how computers communicate.

Knowing even the fundamentals of these cmdlets and their outputs can give immediate returns in supporting any environment. They are certainly worth the small up-front investment to gain those returns.