Intune Patching Part 1: Human Translation

I helped implement Intune at work (Recast Software) which was a great opportunity to dig into the patching side of things. In this first part I’m going to try and cover the technical details and make sense of some of the docs. In the second part I’ll talk more about what I like, what I don’t, and generally try to outline where I think this solution fits in the buffet of patching solutions.

Intune Patching = WUfB

The first thing to get straight is that Intune doesn’t really have a patching solution. At least not in the way that ConfigMgr has a patching solution. Instead, with Intune you can manage the endpoint’s Windows Update for Business (WUfB) configuration. When WUfB was first announced back in 2015 there was a fair amount of confusion about what it really was. It sounded a lot like a new product, maybe a successor the to cranky old guy who lives on the corner: WSUS. It’s not. WUfB is simply an evolution of the Windows Update configuration built into the Windows OS. Specifically, it’s a set of new Windows Update configuration options for Windows 10. Which leads to the first limitation of WUfB: it’s only for the Windows 10 operating system. If you still have Windows 7 or older operating systems then Intune patching isn’t for those devices. Heck, Intune as a whole really isn’t for them. If you have servers, this isn’t the solution you are looking for (I’ll get to that one at some point).

It’s important to note that since WUfB is part of the Windows OS instead of its own product that it isn’t exclusive to Intune. It can be configured via Intune, ConfigMgr, Group Policy, or heck … registry settings (please … don’t do that). In this post I’m going to focus on Intune because if you’re using stand-alone Intune then WUfB is your only option.

Which Of Dante’s Rings is This?

The first thing you do when configuring updates in Intune is to create Update Rings. The closest analog within ConfigMgr would be Win 10 Servicing Plans. Each ring contains a complete set of policies for configuring updates on a group of devices. These policies will dictate a reoccurring schedule of update installation. Unlike ConfigMgr deployments your rings represent a perpetual roll out strategy. A typical setup would include one or more pilot rings followed by your company-wide roll out ring(s).

To create a ring, open the Intune console, navigate to Dashboard > Software Updates > Windows 10 Update Rings, and click Create. Give it a name of some kind because that’s usually helpful.

Great, Now What?!

Now the real work begins. In each ring you will configure what, when, and how updates are installed on devices. Everything here is relatively well documented in various places. However, I found some of the documentation confusing and hope to provide more straight-forward explanations. To get started, click on Configure.

Update Settings

Servicing Channel: Keep in mind that the Targeted SAC channel is now dead so don’t pick it.
Microsoft Product Updates: Choose between only OS updates and all Microsoft updates. Unless you have some other patching mechanism you are going to want to select Allow here.
Windows Drivers: A nice feature that you don’t currently get in ConfigMgr outside of Surface drivers. Driver management is a big topic but if you’re currently not updating drivers post-OSD then this is a nice step forward. Until such time as it breaks everything.
Quality Update Deferral Period (0-30) : Refers to the sort of monthly updates you have come to love to hate. Use this setting to define the scheduling of your pilot and roll out rings.
Feature Update Deferral Period (0-365): Refers to feature updates that upgrade devices to the latest version of Windows 10. The equivalent of ConfigMgr’s Win 10 servicing plans. Again, this is where you would define your pilot and roll out strategy.
Set Feature Update Uninstall Period (2-60): The number of days to keep the Windows.old folder around to allow users to revert to the previous version of Windows 10.

These settings are the totality of options for selecting updates in Intune. To those of us that have been around a while and have used WSUS and ConfigMgr for a long time this feels wrong. We’re used to being able to pick and choose individual updates at the most granular level. As you transition to Windows 10 though I think there’s a strong argument for letting go of this. Windows 10 and Office 365 updates are cumulative whether you like it or not. If an update breaks something this month then next month’s updates will most likely break it again. You either decide to stop patching an impacted device permanently or you fix the underlying problem. Given Microsoft’s track record of flawless patches I can appreciate hesitation on this front. However, granularly selecting updates ceases to have value as we move forward into a cumulative update world.

Automatic Update Behavior

The Automatic Update Behavior setting determines how the client actually installs updates and whether or not you are going to force a restart. Before we dig into this though you need to understand a new Windows 10 feature called Automatic Maintenance. Automatic Maintenance is an attempt to automatically determine maintenance windows where the device is in a state suitable for maintenance. Things like being plugged in and idle; it can even wake the machine up. The goal being to minimize user disruption.

Auto Install at Maintenance Time: This option will attempt to install the update (but not restart) during the Automatic Maintenance window described above. When selected, you are able to define a window of time called Active Hours which will prevent a Automatic Maintenance window from happening. If a restart is required (and let’s face it, a restart is going to be required) then by default the user will be prompted for 7 days before the restart is forced.
Auto Install and Restart at Maintenance Time: This is exactly the same as its no-restart counterpart above but will attempt to restart the device automatically. Patching is rebooting so this is the setting I would recommend using.

Auto Install and Restart at Schedule Time: Dispenses with the niceties of trying to avoid user impact. This sets a hard deadline that ConfigMgr admins will be familiar with. You can schedule it to run every week or on X week of the month, on a specific day of the week, at a specific time of the day.
Auto Install and Restart Without End-User Control: This is similar to the Auto Install and Restart option above but without setting Active Hours and additionally disabling the update settings UI in the control panel to prevent the user from modifying any update setting.

User Experience Settings

Restart Checks: When an automatic restart occurs this will run some basic checks (battery power, presentation mode, is a game running) to make sure the device is in a state conducive to a restart.
Block Users from Pausing Windows Updates: By default users can go into the software updates control panel and pause update installation. This setting allows you to block/disable that control.
Block Users from Scanning for Windows Updates: Similar to the setting above this allows you to block the user from initiating a software update scan.

User Experience Settings – Restart Settings

Require user’s approval to restart outside of work hours: Outside of active hours does the user need to approve/interact with the restart prompt or can the device just approve it and restart automatically?
Remind user prior to required auto-restart blah blah blah: These two settings should be very familiar to any ConfigMgr admin and are otherwise self explanatory.
Change notification update level: This settings allows you to control which toast notifications the user will see.

Allow user to restart (engaged restart): This enables the Engaged Restart feature which attempts to handle restarts as non-intrusively as possible. An Engaged Restart is when the user is prompted to either restart immediately, schedule the restart, or snooze.

Transition users to engaged restart after an auto-restart (days): When a restart is required the system will automatically attempt to restart during the Automatic Maintenance window describe above. This setting configures how many days the system will attempt this automatic restart before transitioning to the Engaged Restart behavior shown above.
Snooze engaged restart reminder (days): When a user snoozes, how long to wait before remind them again.
Set deadline for pending restarts (days): Determine the maximum length that a user can snooze the restart before it is forced upon them:

I’m admittedly kinda geeked out about the restart feature set of Intune/WUfB. The team has clearly paid attention here and given us a very configurable user experience. Attempting to restart automatically and then transitioning to a user-driven restart before finally forcing a restart is a very compelling experience. Doubly so when all of that is configurable and the user experience matches the consumer experience that users are familiar with on their home PCs. For more information on deadlines and user experience head over to this doc: Enforcing compliance deadlines for updates.

That wraps up the Update Ring settings so click OK and then Create to create the actual update ring.

Assign Groups

Now that your rings are created it’s a simple matter of assigning them to groups of users or devices. You do this by clicking on Assignments and selecting Azure AD groups to include and/or exclude. Pretty simple stuff. Creating groups is a whole other topic that is outside the scope of this post.

Repeat everything above a couple of times and you’ll end up with something looking like this:

Update Rings: Wait, That’s Not All!

As mentioned, update rings serve as your perpetual plan for rolling out monthly quality updates as well as new versions of Windows 10. However, there’s a couple other tricks up their sleeves.

I know it’s un-possible but what if, and this is a big what-if, a quality update or feature upgrade didn’t go well. I know, I know, there’s no known instance of that ever happening. Humor me for a second and let’s imagine a world where failure was an option.

Intune’s Update Rings will allow you to pause the roll out and stop the bleeding. If you deem it necessary you can even uninstall the latest update or upgrade to revert to the previous, presumably working, behavior. These are very powerful capabilities that should help ease concerns about Intune’s lack of patch selection. While the lack of selection is concerning you at least can easily handle problems that arise which is a unique capability.

Enough Already, Leave Something for Part II

Ok, that’s all the technical stuff. If there’s anything that doesn’t make sense be sure to reach out and ask for clarification. As new features are released I’ll attempt to update this page to reflect them.