This is an update to my previous post about PSWindowsUpdate located here: https://lokna.no/?p=2132. The content is pretty much the same, but updated for PSWindowsUpdate 2.0.
Most of my Windows servers are patched by WSUS, SCCM or a similar automated patch management solution at regular intervals. But not all. Some servers are just too important to be autopatched. This is a combination of SLA requirements making downtime difficult to schedule and the sheer impact of a botched patch run on backend servers. Thus, a more hands-on approach is needed. In W2012R2 and far back this was easily achieved by running the manual Windows Update application. I ran through the process in QA, let it simmer for a while and went on to repeat the process in production if no nefarious effects were found during testing. Some systems even have three or more staging levels. It is a very manual process, but it works, and as we are required to hand-hold the servers during the update anyway, it does not really cost anything. Then along came Windows Server 2016. Or Windows 10 I should really say, as the Update-module in W2016 is carbon copied from W10 without changes. It is even trying to convince me to install W10 Creators update on my servers…
In Windows Server 2016 the lazy bastards at Microsoft just could not be bothered to implement the functionality from W2012R2 WU. It is no longer possible to defer specific updates I do not want, such as the stupid Silverlight mess. If I want Microsoft update, then I have to take it all. And if I should become slightly insane and suddenly decide I want driver updates from WU, the only way to do that is to go through device manager and check every single device for updates. Or install WUMT, a shady custom WU client of unknown origin.
I could of course use WSUS or SCCM to push just the updates I want, but then I have to magically imagine what updates each server wants and add them to an ever growing number of target groups. Every time I have a patch run. Now that is expensive. If I had enough of the “special needs” servers to justify the manpower-cost, I would have done so long ago. Thus, another solution was needed…
PSWindowsUpdate to the rescue. PSWindUpdate is a Powershell module written by a user called MichalGajda enabling management of Windows Update through Powershell. You can find it here: https://www.powershellgallery.com/packages/PSWindowsUpdate/184.108.40.206. In this post I go through how to install the module and use it to run Microsoft Update in a way that resembles the functionality from W2012R2. You could tell the module to install a certain list of updates, but I found it easier to hide the unwanted updates. It also ensures that they are not added by mistake with the next round of patches.
(See the following chapters for details.)
- You should of course start by installing the module. This should be a one-time deal, unless a new version has been released since last time you used it. New versions of the module should of course be tested in QA like any other software.
- Then, make sure that Microsoft Update is active.
- Check for updates to get a list of available patches.
- Hide any unwanted patches
- Install the updates
- Re-check for updates to make sure there are no “round-two” patches to install.
Installing the module using PowerShellGet
- Open an administrative PowerShell prompt
- Execute the following in PowerShell: install-module -Name PSWindowsUpdate -Repository PSGallery –Force –Verbose
- The –force option approves installation from PSGallery if it is not set as a trusted repository.
- You may get a warning prompting you to install the NuGet provider if it has not been used previously. Just press enter to continue.
Upgrading from a manually installed previous version
If you did like me and installed the module manually or used the included remote deployment options in previous version of PSWindowsupdate, you have to remove the old version manually prior to installing a new version.
- Remove the %WINDIR%\System32\WindowsPowerShell\v1.0\Modules\PSWindowsUpdate folder.
- Remove “Import-Module PSWindowsUpdate” from %WINDIR%\system32\WindowsPowerShell\v1.0\profile.ps1
- Close any open PowerShell prompts.
- Proceed with the steps for a new installation.
Upgrade to a new version
Execute Update-Module -Name PSWindowsupdate –Verbose in an administrative PowerShell prompt.
Make sure Microsoft Update is enabled
If it is not enabled, run this command to enable Microsoft Update as a WU Service:
Add-WUServiceManager -ServiceID "7971f918-a847-4430-9279-4a52d1efe18d" -AddServiceFlag 7
Check for updates from Microsoft Update
List the available updates from Microsoft Update
Filter out all driver updates:
Get-WindowsUpdate -MicrosoftUpdate -NotCategory "Drivers"
Hide unwanted updates
Hides an update and makes sure we do not install unwanted things like that pesky Silverlight stuff. You can hide any KB, and it should stay hidden until you un-hide it.
Add the KB IDs you want to hide to the array, and run the following command against that array:
$HideList = "KB4048953", "KB4049065" Get-WindowsUpdate -KBArticleID $HideList –Hide –Verbose
List hidden updates
Un-hide previously hidden updates
Let us say that you did not really want to hide the KB from the hide-example. No problem, just run the command again with the -WithHidden -Hide:$false option:
$HideList = "KB4048953", "KB4049065" Get-WindowsUpdate -KBArticleID $HideList -WithHidden -Hide:$false
When you have hidden any updates you do not want to install, just run this command:
Get-WindowsUpdate –Install -MicrosoftUpdate -AcceptAll
The X shows the progress. Step 4 is finished. If you want to reboot automatically, add -AutoReboot. Otherwise you will be presented with a reboot-prompt.
If a reboot is required prior to installation, installation will be halted with a message prompting you to reboot the server.
Again, you can filter drivers or any other category of updates with the –NotCategory option.