Validating Computer Lists with PowerShell
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.
- Related: Create Better Lists with PowerShell
- Related: Building Effective Lists with Active Directory and DNS
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:
I want to use Get-Service to check the status of the Windows Update service.
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: My Get-Service command now runs much faster.
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. 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. 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. Now my list is ready to use. 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.
Say Goodbye to Traditional PC Lifecycle Management
Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.