Use PowerShell to Audit and Install Windows Patches
Summary: Learn how to use a free Windows PowerShell module to audit and install patches on Windows systems.
Microsoft Scripting Guy Ed Wilson here. Today, I am proud to present a guest blog post written by Boe Prox. Boe has written a really cool module to audit and install software patches on Windows systems.
Boe is currently a senior systems administrator with BAE Systems. He has been in the IT industry since 2003 and has spent the past three years working with VBScript and Windows PowerShell. He looks to script whatever he can, whenever he can. He is also a moderator on the Hey, Scripting Guy! Forum. You can check out his blog and his projects: PoshWSUS and PoshPAIG.
<BoeProxDisclaimer>This post does not contain any code in it. It does, however, show examples of what I have been able to put together using Windows PowerShell to create an application to manage the patching of servers in an enterprise environment. Tomorrow’s post will contain more code in it as I discuss some issues I ran into and how I resolved them.</BoeProxDisclamer>
Something that I have been working on for a little while as a work project is a way for other users in my shop to be able to patch our servers during a downtime without actually having to log into each server remotely to install the patches that have been downloaded from the local WSUS server.
Initially, I wrote two sets of Windows PowerShell scripts: one to audit for patches that were downloaded to each server and waiting to be installed, and another that would install those patches on the server remotely. Though this is a great solution for a couple other folks and me who are familiar with Windows PowerShell, it is not the “complete solution” that we were looking to use with everyone else in my shop. We needed something that would make it easy for anyone to use (a GUI) and still perform the same tasks as the original scripts I wrote.
Enter the PowerShell Patch Audit/Installation GUI (PoshPAIG).
Rather than go into a lot about how I built PoshPAIG and why I made it the way I did, I am going to go more into some of the new features that I implemented for the latest version, 1.6. If you wish to learn more about what I did to initially build this utility, go to this blog post. My next post tomorrow will also go into some issues I ran into during the build and what I was able to do to resolve them.
Running the utility
First download PoshPAIG. From there, unzip the file to wherever you wish. You can then open a Windows PowerShell console, navigate to the directory structure, and run the Start-PoshPAIG.ps1 script to start the utility.
No more double-clicking a system to run an operation
One of the first changes I made was the removal of double-clicking on a system in the server list to perform the specified operation. Instead of doing that, you can now right-click a system and bring up a shortcut menu to select a few different items, such as removing a server, viewing the WindowsUpdatelog.log, viewing installed updates and performing other operations against the remote system. Clicking Run in the shortcut menu will perform the specified operation that is designated below the server list (Audit, Install, Test Network Connection, or Reboot).
Adding multiple computers using the Add Server menu
Originally, the Add Server menu only let you add one system at a time. While this is okay, I felt that it needed the ability to add more than one system at a time. So with that, I’ve made it so you can add more than one computer by separating the names with a comma. Simply right-click the server list window, click Add Server, type each system name, and then click OK.
The following figure shows the UI before clicking OK.
After clicking OK, the servers are then added to the server list, as shown in the following figure.
Support for operations against multiple systems at a time
One of my most requested features was the ability to perform the operations (audit, install, etc.) against multiple systems at a time instead of against only one system at a time. Doing this allows for a much quicker process of completing whichever operation that you decide to do; otherwise, the operation could take a much longer time than you would expect.
As you can see from another new feature—the Notes column—all the systems are being audited for patches that have been downloaded from the WSUS server. As each system is finished, it will be updated accordingly on the server list with the number of patches found. Depending on the operation you choose, the Notes column and other columns will be affected as well based on the decision. During these operations, if the system is not reachable on the network, the Notes column will report it as being offline.
By default, the number of systems that will be run against at a time is 20. You can adjust this in the Start-PoshPAIG.ps1 script by modifying the $maxconcurrentjobs variable on line 37 to whatever you feel is an appropriate value.
Sort columns when clicked
Something that should have been in the first version but unfortunately was not as easy to implement as I would have thought (more on this in tomorrow’s post) was the ability to sort a column when clicked. So in this latest version, you can now sort a column by clicking it. The following figure shows sorting the Audited column so that the system with the most patches required is first.
Tracked reboot of systems
Another option I added was the ability to send a reboot command to the remote systems; it will continue to monitor the system until it is back online. To avoid having too many systems being rebooted at one time, I have hard-coded a limit of five systems at a time to be rebooted. If a machine has not been reported as being back online within five minutes, it will be registered as being offline and will need more investigation into the system to see why it has not came back online.
To do this, first select the Reboot option below the server list, and you can choose to run the command against every system by clicking Run. Or you can run the command against a specific computer or computers by selecting them from the server list, right-clicking the server list, and then clicking Run.
A warning is first presented advising the user that the computer will be rebooted if the user chooses to continue.
Clicking Yes will continue the reboot process. When completed, you will see the Completed note in the Notes column or the Offline note.
Another option implemented in version 1.6 is performing a “ping sweep” of all the systems in the server list. This is done by selecting the Test Network Connection check box, clicking Run or selecting the systems, and clicking Run from the menu when right-clicking the server list.
The Notes column shows that the network check is occurring.
As you can see, two systems are online and the rest are offline. Note that the total time to perform this was just less than 13 seconds.
View WindowsUpdate.log for troubleshooting
I thought that this would be a nice and obvious addition to this utility. One big caveat is that this can only be run against one system at a time. Parsing and using Out-GridView to display the output against a file that could possibly contain several thousand lines of information would slow things down quite a bit. Just right-click a system, click WindowsUpdateLog in the shortcut menu, and then click one of the four options (Last 25, Last 50, Last 100, and Entire Log) to have the utility grab the remote log and display it.
In this instance, I selected the last 50 lines from the WindowsUpdatelog.log to view.
Show currently installed updates
While not necessarily needed, I figured I would add an option to view the currently installed updates on one or more remote systems. Just select the systems, right-click Installed Updates, and then click View Installed Updates in the shortcut menu.
After all of the updates have been gathered, you can then view the installed updates on each system.
I hope everyone enjoyed this post displaying some of the new features of my latest project. This is a work in progress and will have more releases in the future. If you have any feature requests or any bugs that you find, be sure to log them in the Issue Tracker on CodePlex.
Tomorrow, I will address some issues I ran into while creating this utility and the steps I took to resolve them. I promise you will see some code in that post.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at firstname.lastname@example.org, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy