I’ve previously written about Windows Autopatch, and now that it’s included in Business Premium and EDU licenses, it made sense to write an updated post for MSPs to use to get their clients Cyber Essentials compliant in this area only.

One of the most time consuming things I’ve witnessed working at and with MSPs is how long they spend faffing about with Windows OS patching and third-party app updates. A few years back I’d wager a lot of MSPs didn’t even bother with third-party patching. Adobe Reader was installed as part of the build, and it remained until it either broke, or the user got a new laptop.

Cyber Essentials has forced businesses to get better at securing themselves, and MSPs play a crucial role in helping all their customers remain compliant. For third-party patching, my recommendation is to choose Patch My PC.

I am not paid, sponsored, affiliated with, or endorsed by PMPC.

Shilling slot over, let’s get on with it…

Windows Autopatch

Is a service that automatically handles Windows Update for you. As the MSP, the idea is you no longer have to dedicate resource to someone who Googles KB numbers and ends up on Reddit.

Autopatch is a ‘set and forget’ service included in Intune that will manage, stagger, and deploy OS/Driver/Office updates across your customer environments (although it is not centrally managed).

What about my RMM product?

If you leave the decision making to your RMM, it might work to rules like: “if CVSS > 8, push to all devices” etc. While RMM vendors market Windows OS patching as a main selling point for their products, you only have to go to /r/Intune or /r/MSP to see dozens of threads about how it simply isn’t working as expected. The problem, in-part, is sometimes down to the admins themselves who use the RMM as a modern vehicle to deploy their old jank via scripts, reg key hacks, or totally unnecessary scheduled task modifications.

In another common scenario, you have admins who for “reasons”, block all Feature updates or Quality updates until it has met their invisible satisfaction metrics – this worsens patch compliance across a whole customer base. Don’t be this admin. Windows Updates are nowhere near as scary as they used to be.

Sometimes though, even when the products are used as described, they just don’t perform as well at patch management as the native Microsoft tooling, so if you want patching success, you should make the switch.


It’s also okay to not know what to approve. I wouldn’t expect most MSPs to have full controls and processes around OS patching. If you are serious about it, it’s a full-time job.

I don’t care about it, or have time to do it, so I leave that to Windows Autopatch.

With hundreds of millions of devices enrolled into Intune, Microsoft have met the obligation to build a system which keeps them patched as they should be. Anything else customers attempt to use is entirely at their own risk, and in my experience, makes things worse.

If you’re replacing RMM with Autopatch, you might want to check/run this script to fix your Windows Update settings after you’ve disabled it.

Requirements

Licensing

We’re going to keep things as basic as possible, so for all endpoints we are going to have all updates delivered to 100% of devices in 14 days or under. The beauty of Autopatch is the service can make dynamic and randomised groups sized at your choice. And if something does go wrong, it’s only affecting a small bunch of devices and you can step in to manually pause things.

To date, I’ve never had to pause Autopatch. The service works well.

Step 1: Create your Dynamic Group

I need a group that will contain all devices, and one that isn’t confused with other groups I have in Entra.

We will use this “all devices” group as our device registration group; anything inside it will be subject to Autopatch Groups/Rings later on.

(device.deviceOSVersion -startsWith "10.0.1") or (device.deviceOSVersion -startsWith "10.0.2")

The query I am using is simply saying: All Windows 10 or All Windows 11 devices.

Creating the Autopatch Group

This is different to the Entra ID group. As a reminder, the Entra ID group is what we’re using to designate devices to the Autopatch service. The Autopatch group is Intune-specific and in our example it will sub-divide endpoints into different patching rings.

Go to Tenant Administration –> Autopatch Groups –> Create

Give it a name:

  1. Add your newly created Entra dynamic group
  2. Add as many deployment rings as you think you want
  3. Adjust the dynamic distribution to add to 100%
    • i.e, 20% of our devices are patched in Ring 1

You could also ignore the dynamic distributions and add devices into manual rings yourself. I do not recommend this. In my view, nobody is important enough in any business to have special patching treatment. Yolo that stuff across the whole org in random groups to get a more realistic idea of how future rings will go.

Select what you want Autopatch to do:

(I’ve unchecked M365 App Updates because I prefer to handle those via https://config.office.com – Link to MS Learn)

I’m leaving the below as default because I’m happy with the choice, although you may wish to select a different target Feature version.

Autopatch will maintain all devices on the minimum in-support version even if you never update this.

All I’ve done on the next page is make the final ring more strict so it actually falls in at 12 days.

I’ve also chosen to leave the notifications default, as I think that provides the best end-user experience:

For Ring 3, updates will install 7 days after release, then the end-user will have 5 days of warning before their machine will forcibly restart.

For Feature Updates, I’ve lengthened the deadlines so the deployment is staggered a bit:

Once done, click create.

Over the next few hours, devices will register with the Autopatch service. You can see which group they land in by going to Devices –> Monitor –> Autopatch devices:

(I’m using a screenshot from another tenant here, so don’t get thrown off by the name changes on the highlight)

What next?

Now you can wait and monitor!

If you get problems with the service, check out Microsoft Documentation or the “Autopatch Detected Issues” section of my other post. You will almost definitely see issues if an RMM previously managed Windows Updates since those tools (and some GPO settings) will add registry keys that interfere with what Autopatch is trying to do.

Other info

When you visit Devices –> Windows Update, you’ll see new things have been created depending on what you selected above. The releases view will show us what Autopatch is currently working on:

Reports –> Windows Quality Updates is also a good one to check out:

What about Hotpatch?

Even with Business Premium, you can now enable Windows Hotpatch. Hotpatch allows certain Windows updates to be applied to a device while it is in-use, without requiring a reboot.

Hotpatch does not mean devices never restart despite what you might have picked up from marketing materials! If you feed that info back to your clients, it’ll be on you to endlessly explain how Hotpatch actually works.

Hotpatch reduces the number of reboots an end-user has to do. I take a view that within a service desk environment, more reboots is probably better for reducing IT service incidents, but I don’t yet have stats on this.

Hotpatch = faster security patches

That’s the message I am happy with. Luckily it’s really easy once you have Autopatch enabled.

Go to Devices –> Windows Update –> Quality updates:

Create a “Windows Quality update policy”

Turn on the magic switch, and assign to your Autopatch Dynamic Group:

And wait…

You’ve done Hotpatch!

Be aware

The Windows build number for a fully updated Hotpatch device differs from a non-Hotpatch device.