I’ve been invited to a strange meeting where 2 companies were talking about Windows Updates. The software manufacturer wanted to patch the computers once a year while the maintenance provider wanted to be never ever disturbed by an update or its reboot during a full week of production. I told the software company that this bad practice is called “patch and pray”. I told the maintenance company that’s hard to achieve nowadays due to “Windows Update as a Service” and that I’ll have a look.
While I understand the business needs of these companies, it seems that the behavior described by Brian Krebs in his recent blog post has already negatively impacted their subconscious mind.
Please allow me to quote his post:
Most Microsoft Windows (ab)users probably welcome the monthly ritual of applying security updates about as much as they look forward to going to the dentist: It always seems like you were there just yesterday, and you never quite know how it’s all going to turn out.
Nevertheless, it is frustrating when being diligent about applying patches introduces so many unfixable problems that you’re forced to completely reinstall the OS and all of the programs that ride on top of it.
So, three words of advice. First off, don’t let Microsoft decide when to apply patches and reboot your computer.
Secondly, it doesn’t hurt to wait a few days to apply updates.
Finally, please have some kind of system for backing up your files before applying any updates.
I usually recommend the same as Brian Krebs to any user who’s not involved in patch management.
To regain control on Windows Update (a.k.a. WU), the following solution allows you to turn WU on and off on demand.
All the screenshots below have been done on a Windows 10 Enterprise 1903 provisioned in Azure:
- How to install
Right-click the Start menu, select “Windows PowerShell (Admin)”,
Copy/paste in your browser the link to the above gist or click on it. Once you’re on the gist, you should use the ‘Raw’ button and then copy the content of the page and paste it in a PowerShell script file. I used a.ps1 as a name below:
Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope Process -Force notepad a.ps1 .\a.ps1
Let’s see what it looks like once it’s deployed.
You get 2 scripts on the desktop and the following settings in the system settings tiles:
The active hours are set to 6:00 AM to 11:00 PM.
It also defines a period of 185 days to defer upgrades and 25 days to defer updates. If that’s not what you want, you’ll need to modify the content of the script but that’s beyond the scope of this blog post.
If you use the Off.cmd script on the desktop, checking for updates fails (that’s expected)
If you use the On.cmd script on the desktop and hit “Retry”, checking for updates succeeds:
- Known limits
The above solution doesn’t work in a corporate environment where the above WU settings are controlled by an administrator.
The above solution works only for an Ethernet connection because it’s set as a metered connection. That will also stop Office 365 updates (it honors the metered flag). Unfortunately the above solution isn’t working for a wireless connection.