Get full control of Windows Update

  • Context

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.

  • Solution

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

  • Demo

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.


How to delete a single Applocker rule

  • Context:

A colleague of mine was working on Applocker rules and the installer he was working on was so badly designed that we thought it would easier to restore the worst and most dangerous default rule named “*” for the built-in administrators.

If you restore this evil rule, you cannot and should not leave it there. You also have to delete it after it has been used to install successfully that ugly software.

  • Problem:

I started looking around using my google fu but only found the following web page from Microsoft named delete-an-applocker-rule that tells you actually how to clear *all* the rules. It’s a dead end and really not what we want 😦

  • Solution:

Instead I wrote the following function. Before looking at its code, let me tell you the following:

If you specify the first parameter to indicate what type of rules you want to delete, a Exe, Script, Msi, Appx, Dll, it will be used in the dynamic parameters block to enumerate all rules names found for this type.

Let’s see this in action:

You may also notice in the body of the function that the XML representation of Applocker rules never touches the disk. The rule is removed from the XML and its result is directly merged/reimported.

The function specifies a ‘high’ ConfirmImpact and SupportsShouldProcess because it’s destructive. There’s no backup of the rules or the rule being removed.

Last but not least, the rule is deleted but the group policies (GPO) are not refreshed. You’ll see its impact once the GPO have been reapplied.

Here’s the function: