#1 2020-09-13 22:53:47

From: Great Britain, Barnby In The W
Registered: 2020-09-12
Posts: 2

Intune Patching Part II: The Good

Dam Good  Admin                           Or at least not entirely useless                                                                                                Toggle mobile menu                                    Toggle search field.

Intune Patching Part 1: Human Translation

May 29, 2019                              11 Comments                                            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 system s 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.
Intune, Software Updates, Uncategorized           IntuneSoftware Updates                                 Previous post.
PSA: New Update Product Categories for 1903 Release                     Next post.
Intune Patching Part II: The Good, The Bad, The Ugly                                        10 Comments.
Yeswanth Kumar                     August 4, 2020 at 3:26 pm                                          Thank you Bryan for writing this blog.
I just wanted to know which registry keys are responsible for automatic update setting.
Reply                                                               bryandam                     August 4, 2020 at 3:38 pm                                          The corresponding reg keys are listed in the docs: https://docs.microsoft.com/en-us/windows/deployment/update/waas-configure-wufb                       Reply.
sjmckeeman                     February 5, 2020 at 10:48 pm                                          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.
Reply                                                               sjmckeeman                     February 5, 2020 at 11:01 pm                                          Also, when I scan it doesn’t see KB4532695, which was also released on 1-28 and would update the build to 18363.628.
Bram Maerevoet                     October 24, 2019 at 9:36 am                                          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                       Reply.
Jack                     August 14, 2019 at 3:54 am                                          What is the process for blocking an update using WuFB.
or rolling back an update that has been deployed like on WSUS.
Reply                                                               bryandam                     August 14, 2019 at 8:06 am                                          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.
Abhas                     August 6, 2019 at 3:12 pm                                          Brilliant.
thank you very much


Basketball Star Slot

Board footer

Powered by FluxBB