Validating Computer Lists with PowerShell

Posted on October 29, 2015 by Jeff Hicks in PowerShell with 0 Comments

Over the course of a few articles, I’ve been demonstrating a number of techniques and tools for creating lists of computer names. If you are just jumping in, then I hope you’ll take a few minutes to get caught up, otherwise some of the material in this article might not make sense.

Once you’ve created your list of names, then you need to validate it. The assumption is that you want to run some PowerShell command against your list of remote computers, but there’s no guarantee that every name in the list is valid or even running. It’s quite easy to include error handling in a script with a try/catch statement, but let’s see what we can do to validate the list before we even get to that step.

I’m going to use an existing text file.

There are some potential issues, but using techniques I showed you previously, I can get a variable of computer names:

My clean list of computer names (Image Credit: Jeff Hicks)

My clean list of computer names (Image Credit: Jeff Hicks)

I want to use Get-Service to check the status of the Windows Update service.

Using the list (Image Credit: Jeff Hicks)

Using the list (Image Credit: Jeff Hicks)

In this particular example, PowerShell didn’t complain about computers in the list that are offline or can’t be resolved. But other commands might, and the command is also taking longer to run  after attempting to contact non-existent computers. So let’s validate the list first.

The obvious choice is to conduct a ping test, assuming your servers are configured to respond to pings.

In this command, I am filtering the list with Test-Connection by sending a single ping. The –Quiet parameter will provide a result fo $True or $False, which Where-Object uses to filter.

Now I have a valid list:

Online computers (Image Credit: Jeff Hicks)

Online computers (Image Credit: Jeff Hicks)

My Get-Service command now runs much faster.

Sponsored

Another option is to use Test-WSMan. This is especially useful if you will be running a command that takes advantage of PowerShell remoting.

Notice that I am setting the –ErrorAction parameter to SilentlyContinue. This is to suppress errors for offline computers or those that can’t be resolved. All I care about are those that can be reached so there’s no reason to see any errors. This would be even easier to use if Test-WSMan included the computer name in the output, but sadly it doesn’t.

A variation with this cmdlet is to filter machines based on their WSMan stack. Perhaps you want to run a command using Get-CimInstance, which will fail for a computer running PowerShell 2.0. Although Test-WSMan will work. To get the stack information, you can run Test-WSMan with the Authentication parameter.

Getting version information with Test-WSMan (Image Credit: Jeff Hicks)

Getting version information with Test-WSMan (Image Credit: Jeff Hicks)

The server CHI-DC02 is still running PowerShell 2.0, which could be problematic. It is a little tricky to get just the stack version because the ProductVersion property is a single string.

I can split the property into an array, knowing that the stack version number will be the last element of the array. The –As operator tells PowerShell to treat it as an integer.

Getting WSMan Stack Version (Image Credit: Jeff Hicks)

Getting WSMan Stack Version (Image Credit: Jeff Hicks)

Now that I have a technique, let’s revise my filtering command.

Normally I would never set an error action preference like this, but in this case I knowingly want to suppress errors for any name that is offline or can’t be resolved. This will also eliminate my v2 machine from the list.

No v2 computers (Image Credit: Jeff Hicks)

No v2 computers (Image Credit: Jeff Hicks)

Now my list is ready to use.

Using my v3 and later list (Image Credit: Jeff Hicks)

Using my v3 and later list (Image Credit: Jeff Hicks)

Sponsored

There really is no limit to how you can combine everything I’ve shown over the course of this short series. The most important thing to consider is how you are going to consume your list. If you spend a little time up front grooming your list, your commands and scripts will run smoother and hopefully with less errors.

Sponsored

Tagged with ,