A Flexible Approach to Microsoft Update Deployments

So this isn’t the first time we’ve looked at improving the management of updates using Microsoft Intune, and probably won’t be the last time either, especially with declarative device management looming, for Apple and hopefully Windows devices, covering configuration of software updates.

But with the introduction of the Windows Autopatch service, and getting hands on with it recently, it prompted me to revisit my previous approach to phased update delivery, so I thought I’d share my findings, this time across not just Windows Updates.

Deployment Approach

#

Previously, we configured a set of four Update Rings, but now we’ll include an early adopters ring as a pre-production release, kind of a fail safe prior to your production deployment of updates; that final catch before you target the entire device estate:

• Test - This should be devices that are dedicated for testing, ~1% of your device estate.
• Pilot - This should be a stratified sample of either users or devices, ~5% of your device estate.
• Pre-Production - The early adopters deployment, ~15% of your device estate.
• Initial Production - The first production deployment, ~30% of your device estate.
• Final Production - The final production deployment, the remaining ~50% of the device estate.

The aim is tht the above groupings are reusable and can be used across not just Windows Updates, but Office Updates, and Driver updates too. Let’s look at the membership of these groups.

Deployment Groups

#

Despite Microsoft recommending to stop using the match operators in favour of startsWith there are times when you might have to ignore them, this could be one of those times when we look at how we split a device estate into the phased breakdowns we’re looking to achieve.

Inefficient Dynamic Groups

#

For the members of Test and Pilot groups, these should be targeted members, not just any old device, so ensure you populate these groups with true test devices, and suitable pilot devices for update testing.

You’ll notice that this time we’re using Dynamic Groups across all the pre-production and production groups, and using a new attribute of deviceId, which is a wonderful UUID associated with all Entra computer objects, and it being a UUID gives us a nice split of devices based on the queries used.

With the start of the deviceId only ever being in the range of 0-9 or a-f we’ve an easy way to split our devices across the three production level groups, and ensure that we are capturing all devices, using the match operator, and the regular expression similar to ^[0-9,a-f] to detect whether the deviceId starts with one of the values in the ranges provided.

Efficient Dynamic Groups

#

If you want to please Microsoft Daddy, then you could use these alternative queries for the groups, Test and Pilot are still assigned, so don’t forget to populate those members.

Much more efficient.

VIP Groups

#

What about those people who complain about when they’re getting updates, I mean you could tell them to jog on that you can’t change the behaviour, or you could cater for the more VIP user, and allow for their device to sit in a different update group.

So more assigned groups are required for each potential exception or change to production level deployment options.

See, we can please the senior members of the company with IT solutions.

Windows Update Rings

#

Now with suitable groups at our disposal, we can create our Windows Update Rings in Microsoft Intune for each of the five phases, and after reviewing and experiencing Windows Update Rings personally instead of just recommending them, I’ve decided to set zero-day installation deadlines, in favour of longer grace periods, still working within the National Cyber Security Centre 14-day window.

You see something else new? Yes, I’ve avoided device restarts on weekends following a chat with fellow lover of Microsoft Intune, Jonathan Fallis, meaning that for a weekday based ‘working week’, updates get installed and devices restarted when the device is actually on, not over a weekend when realistically the device is still in the office and powered off, or being used to watch Netflix in bed.

This also allows for our VIP users to pick which day they actually want their device to restart, based on whatever day they’re not playing golf 🏌️‍♀️.

Office Update Rings

#

Oooooh this one is new, and straight up robbed from Windows Autopatch, and although doesn’t exist as a dedicated blade in Microsoft Intune, we can use the glorious Settings Catalog profiles to configure Office Update Channels, deferral, and deadline settings for Microsoft 365 App updates.

To start, we need to configure some baseline settings. So go create yourself a new Settings Catalog profile, and throw the below settings into it, the settings exist under Microsoft Office 2016 (Machine) > Updates.

With the update channel configured to Monthly Enterprise, and a bit of a change to the user experience, let’s see what else we can borrow.

Phased Office Updates

#

With a similar approach to the Windows Update Rings, we can create corresponding Settings Catalog profiles for our five deployment phases, aligning as best we can the end result, which is installed updates, to the restart of the updates delivered as part of the Windows Update ring configuration.

All settings exist under Microsoft Office 2016 (Machine) > Updates.

As Office Updates are released with the same update cadence as our normal updates on a ‘Patch Tuesday’, then the installation time falls on the same days, meaning that all updates should be installed and the device restarted on the same day, reducing overall disruption to the users.

Update Ring Assignment

#

After creating the Windows Update Rings, and our faux Office Update Rings using the above settings, we cover how we assign our phased deployment groups to each suitable Update Ring.

I’m assuming here that you aren’t putting VIP user devices in Test and Pilot, because you don’t want to anger them, maybe do it on your last day 😅.

VIP Ring Assignment

#

To get the expected behaviour for our VIP groups, we need to consider what happens when we want to ensure a VIP device is in the correct Update Ring, which includes making sure there are no conflicts across the rings.

Changing the assignments of our Update Rings to the below, will allow for the manual assignment based on a devices VIP group membership.

For example if device name VIP-7wa7f4c35, with deviceId ec759183-4492-44f4-a2ec-dbc33470bf48 (which will captured by the ‘Final Production’ dynamic group), is added to group VIP Initial Production, it will exclude the device from the ‘Final Production’ Update Ring, and assign the Update Ring for ‘Initial Production’, with the device restarting after updates on a Friday.

Adding in not only new include assignments, but exclude assignments, will ensure that devices in these groups are assigned to the correct Update Ring.

Summary

#

All of this should give you the option to not only suitably phase Windows, Microsoft, and Office Updates, with each subsequent Update Ring starting only after the next, but also allow the shift of devices around without conflict, whether this is for VIP users or otherwise.

It also provides your end users with clear details of the days of when their device will not only get updated, but also restart, without too much of a headache, or interruption to their casual personal use of their corporate owned device.