Or at least not entirely useless

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:

The notification users get for an impending quality update deadline

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.

14 Comments

  1. nandudittoNandu Ditto

    So. I need to observe the pilot deployment which for a week and deploy to production later.
    I will set automatic install behavior on every second week and to Production on 4th week .
    Is that the right way for that ?

    • nanduditto

      Pilot – SAC – Auto install at 2nd week of every Month
      Production – SAC – Auto install at 4th week of every Month

  2. Franco

    hi Pete, great job i am diging in this WUfB world due to my job, but if cllient side are not updated how can i fix it? i mean with WSUS i can fix
    SoftwareUpdate folder
    Catroot2
    restart WUAUSERV

    but to fix WUFB in those clients how can i do?

    thanks in advance

    • Bryan Dam

      WUfB isn’t really different on the client side; it’s just pointed directly at Microsoft Update instead of a WSUS server like it would be in stand-alone WSUS or ConfigMgr. The client will get updated the same way: via Servicing Stack Updates (which in the latest release of Win 10 will get rolled into the monthly CU).

      In terms of fixing client-side issues: it’s again the same stuff. In Intune you’d write some PoSH to do it and assign it to the devices using the scripts feature.

  3. Yeswanth Kumar

    Thank you Bryan for writing this blog. I just wanted to know which registry keys are responsible for automatic update setting?

  4. sjmckeeman

    Great article, Bryan! For the quality deferral period, is the period from the date the update is actually released, or say, the period after the usual Patch Tuesday?

    Issue I’m seeing on our pilot ring (0 deferral days for quality updates) is that KB4534132 was released on 1/28, but it’s now 2/5 and they have not received the update. The systems show “You’re up to date” when I log in and check. If I click Check for Updates, they find it and install it without issue.

    • sjmckeeman

      Also, when I scan it doesn’t see KB4532695, which was also released on 1-28 and would update the build to 18363.628.

  5. Bram Maerevoet

    Hi Bryan,

    I have a question. I paused the Feature Update for one Windows Update Ring, now I resumed it, but guess what? It doesn’t resume… the Windows Updates on my devices are all paused – there is no “Check for Updates” button, only a “Check online for updates from Microsoft Update” button. The device is running 1709 at the moment.

    I checked the reg keys:

    – FeatureUpdatesPaused = 1
    – FeatureUpdatePausePeriodInDays= 35
    – PauseFeatureUpdatesEndTime: 2019-11-28
    – PauseFeatureUpdatesStartTime: 2019-10-24

    The update ring is clearly resumed: I checked the MDM Diagnostic Report

    – PauseFeatureUpdates = 0 -> so means it’s not paused right? BUUUT
    – PauseFeatureUpdatesStartTime = 2019-10-24

    I tried manually altering the dates in registry but as soons I click “check online for updates from Microsoft Update” the keys change back.

    I guess that when you pause a update ring, it’s pause for minimum 35 days even if you resume it.

    Can you confirm? Have you tested this too?

    Kind regards,

    Bram

  6. Jack

    What is the process for blocking an update using WuFB? or rolling back an update that has been deployed like on WSUS?

    • bryandam

      Short answer: you don’t. You can pause updates, for a maximum of 35 days, but you cannot outright block them. See part 2 for the second part, rolling back updates.

  7. Abhas

    Brilliant! thank you very much 🙂

  8. Andrew John Porter

    Very nice write up Bryan. Thanks!

  9. Gareth

    Super-handy stuff. I like your style, thank you!

Leave a Reply to bryandamCancel reply

© 2024 Dam Good Admin

Theme by Anders NorenUp ↑