Deploying patches is a task many IT administrators must endure every month. There are many commercial tools out there to ease this process, but some are expensive, bloated or overkill for simple patching that a smaller company may need.
Using PowerShell, we can develop a patch deployment strategy and automate the process – just like the big tools – with little more than some sweat equity and time.
Prerequisites
To ensure you can start with everything configured as needed, you'll need a few things. First, you'll need PowerShell. We'll be using Windows PowerShell 5.1. I am assuming you've already got PowerShell Remoting available on all of your clients, you've got appropriate rights to query and install patches on systems, you're in an Active Directory environment, and you've got the Remote Server Administration Tools package installed.
Discovering the environment and testing
To ensure we test the most significant and most applicable sample of computers across our network, we first need to identify what systems are out there. Picking various configurations to test, such as Windows settings and software installed, across computers is an organizational choice, but typically, we'll need to find all of the operating systems we have to ensure patches don't break these systems when deployed to all systems.
We can use PowerShell to query our Active Directory environment to return all groups of computers with a specific operating system. For example, the below code will return two test systems by operating systems across all of your Active Directory computers.
The output will look like this:
Now that I have identified the different operating systems, I can either P2V the machines or perhaps build new virtual machines in your hypervisor of choice. That could be done with PowerShell but is outside of the scope of this article, so we'll assume you've got that handled.
Deploying updates
Once you've got your test systems defined, you'll need to deploy patches. But first, which patches should be deployed? There are a couple of ways to do this that are outside of the scope of this article, such as looking at an existing WSUS server or using the Get-LatestUpdate PowerShell script, but I'll leave that to you.
To deploy patches, one way to make that happen with PowerShell is to use a prebuilt community module called PSWindowsUpdate that handles the vast majority of tasks you'll have to deal with. You can install this module using Install-Module PSWindowsUpdate.
The PSWindowsUpdate module requires RPC connectivity to each remote system that is sometimes blocked by default on Windows firewalls. You can open this with a GPO or similar system management tool, but since we're in PowerShell, we might as well go ahead and do that too. You'll need to run this command on each remote system you intend to patch.
To ensure the PSWindowsUpdate tool can access a remote system, I use a simple command like Get-WUHistory to see if it returns an error. If it returns patch history, you're good to go!
We can now deploy our patches. For this article, I've found that I need to test patch KB4091664. I can deploy this patch to all of my test groups by first copying the module to each system and then running the Install-WindowsUpdate against each system specifying the KB I'd like to install and even scheduling the reboot for two hours from the time the patch is deployed.
This will start the patch installation on each computer. To monitor progress, we can use the Get-WUHistory command. Below you'll see an example output where one of my machines has started the installation.
Wrap up
Testing patches before production is a necessary task but can be prone to error. Using a commercial tool will work, but if you need a simple solution to get the job done and are low on funds, PowerShell is a great way to ensure your systems don't go belly up come time to deploy patches to production.