Revisiting the best user experience for Windows Update rings
Over two years ago, I wrote an article describing how to configure Windows 10 update rings for the best user experience. In that article, which continues to be one of the most popular ones on this blog, I talked about how users want to be informed and in control of when to update and how you can provide lots of notifications before an update is forced. Fundamentally I still believe in this experience – but now there are newer policies and settings we should be using! I’m basing this updated experience on a fantastic TechCommunity article: Why you shouldn’t set these 25 Windows policies – Windows IT Pro Blog (microsoft.com).
Let’s get started!
Go to endpoint.microsoft.com > Devices > Update rings for Windows 10 and later > + Create profile
Provide a name for the new update ring profile:
And then we can start configuring the settings. The first group of settings, Update settings, are mostly unchanged. We will leave Microsoft product updates and Windows drivers to Allow. For this policy, I will leave Quality and Feature update deferrals to a 0 day delay (if I had a second group, for feature updates I’d set it as 30, and then the next group as 60, etc.). Previously the first option was to configure a channel, but now we have the Enable pre-release builds option instead, which makes more sense. For our general group I will leave Enable pre-release builds to Not Configured and Update Windows 10 devices to Latest Windows 11 release to No.
The real fun stuff is in the User Experience settings. Here, we will continue to leverage Auto install at maintenance time with Active Hours of 8 AM to 5 PM. Restart checks are set to Allow. Option to pause Windows updates is set to Disable, and Option to check for Windows updates is left to the default of Enable. Those settings are also unchanged from the previous post.
What has changed is the new deadline compliance settings – the second half of user experience. Here, we no longer have the “require user’s approval to restart” or “remind user prior to auto-restart” settings. Instead, we will configure the Use deadline settings to Allow. Then we can configure Deadline for feature updates to 7, Deadline for quality updates to 3, Grace period to 1, and Auto reboot before deadline to No.
While the various days for deadlines can be subjective to your organization’s requirements, setting Auto reboot before deadline to No is really the key for getting a good experience for end users. Combined with Auto install at maintenance time, the user experience goes as follows: when an update is released, it will install after 5 PM or when the user clicks the Check for updates button. If a restart is required, the user will be prompted, but can delay for 3/7 + 1 days depending on the update. Even if the device goes to sleep, it will not auto restart until the deadline + grace period has been met. The user will receive native Windows notifications where they can choose to be reminded later, reschedule the reboot, or restart immediately, depending on how close the deadline is.
And with that, we have our new update ring settings! No restarting without the user’s consent until we have to, and we are using the latest features built into Windows. Just be sure to click Next, Assign the policy, and then click Create!
With those in place, the end user will see the following notifications when they have updates installed and waiting for a reboot:
In this case, the VM was sitting offline for two weeks, so the first update it installed was past the deadline date (but we still have that grace period!). If I select remind me later, there will be prompts in the system tray and power menu:
While we’re talking about updates, it’s worth calling out the other profiles you may have noticed in the console:
Feature updates for Windows 10 and later (Preview) and Quality updates for Windows 10 and later (Preview) work much differently then the Update rings. For Feature Updates, devices targeted by this profile will install and remain on that exact version – and will not update to a new Windows release version until you deploy a new profile (or remove the existing one). Leveraging that profile makes sense if you are looking to standardize on a certain version across the organization by a certain date, rather than work with the regular Windows Update cadence (if you wanted to stay on a certain feature update for 18months, as an extra example).
For Quality Updates (or Express Updates, as they’re called in the docs), the profile expedites the installation of security updates (but doesn’t “hold” to a certain patch level). If for example, you normally have a 7 day quality update compliance window but a new security update is available that you need to deploy immediately, then we just create the quality update profile and those settings will take precedence over the update rings:
That’s all there is to Update rings and profiles! Ideally, the Update rings will be used for monthly servicing and ensuring devices are kept up to date. And then for special cases – like an immediate security need or a device incompatibility issue with a certain Windows version, you can leverage the additional profiles for more granular control.
Now get those devices up to date! 🪟
Feature Updates (Preview) + FU vía Update rings at the same time, in the same environment… Not recommended? or, not an issue? What are your thoughts and experience?
And QU (preview) QU Update rings… comments?
I’ve been using QU (preview) as sort of a baseline with the idea to get up to date all new devices ASAP)… I’m not aware of any issues, I believe it’s working as I expect it.
Cheers!
Yep! No issues using both. I recommend still using the Update Rings to determine the user experience when you’re not deploying FU & QUs (if you skip a month of deploying quality updates for example). The FU preview & QU preview will always take precedence over the Rings settings.