Windows 10 update rings – the best user experience

To deploy updates for Intune-only managed devices, you have to use Windows Update for Business rings. This is a good thing – using update rings sets you up for proactively monitoring and managing Windows throughout the organization. They require that you create pilot users (who validate the update across the org) before you deploy broadly, ensuring that the update will succeed.

Today we’ll be going over configuring update rings in the MEM portal. Part of the reason I wanted to cover this was that users want to be in control.

Start by launching the MEM portal, then click Devices > Windows 10 update rings.

Windows 10 updater rings

Let’s create a new ring by click + Create. Provide a name and description as well (you’ll want to have a few rings in your org, so name them well!)

New Windows 10 update ring

Then we can select options for the update ring. First, let’s start with the Update settings. Channel wise, SAC-T no longer really exists (https://docs.microsoft.com/en-us/windows/release-information/ ), so for our general pilot group we’ll use Semi-Annual Channel. In this ring I’ll leave Quality and Feature updates to 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.).

Semu-Annual Channel settings

What we really care about is the User experience settings.

User experience settings

Here’s what Automatic update behavior means:

  • Notify download – Notify the user before downloading the update. Users choose to download and install updates.
  • Auto install at maintenance time – Updates download automatically and then install during Automatic Maintenance when the device isn’t in use or running on battery power. When restart is required, users are prompted to restart for up to seven days, and then restart is forced. This option can restart a device automatically after the update installs. Use the Active hours settings to define a period during which the automatic restarts are blocked.
  • Auto install and restart at maintenance time – Updates download automatically and then install during Automatic Maintenance when the device isn’t in use or running on battery power. When restart is required, the device restarts when not being used. (This is the default for unmanaged devices.) This option can restart a device automatically after the update installs. Use of the Active hours settings aren’t described in Windows Update settings but are used by Intune to define a period during which the automatic restarts are blocked.
  • Auto install and restart at scheduled time – Specify an installation day and time. If unspecified, installation runs at 3 AM daily, followed by a 15-minute countdown to a restart. Logged on uses can delay countdown and restart.
  • Auto install and reboot without end-user control – Updates download automatically and then install during Automatic Maintenance when the device isn’t in use or running on battery power. When restart is required, the device restarts when not being used. This option sets the end-users control pane to read-only.
  • Reset to default – Restore the original auto update settings on Windows 10 machines that run the October 2018 Update or later

So here’s my argument for why you should select Auto install at maintenance time and Require user’s approval to restart outside of work hours. This will install updates if 1) it’s past the Active hours time or 2) the user clicks Check for Windows updates. So we’re already not taking up bandwidth or hogging the CPU when it’s inconvenient for the user. Then, it will notify the user that they need to reboot to complete the update – but won’t, even if they sleep the device, unless they initiate the reboot!

Think of a scenario where a user stays late at the office and then plans to start early the next day to finish a critical project. Since they stayed after hours, the update is already installed in the background – just waiting for “when the user isn’t using the device” to complete the install. Normally, once they sleep the device that night it will automatically install the update! And when they wake up the device the next day, they’ll be presented with a blank desktop (potentially losing some data) or a screen completing the install and taking more of their time.

That’s why I recommend they should be given the option to delay – to prevent the scenario above. Selecting “Require user’s approval to restart outside of work hours” puts the user in control of when they update their device.

The best user experience for Windows Updates

Feel free to change the reminder times, too. Some organizations may work better with a 4 or 8 hour dismissible reminder. That way users are reminded during the same work day.

You may be thinking – but what if the users ignores the update, or doesn’t see it? Here are all the places the feature update shows up – it’s almost impossible to ignore!

Desktop notification
Action center notification (when desktop notification is swiped away)
Notification tray icon
Notification tray hover tip
Power settings

And if they do ignore the update for 7 days, then they’ll get a 60 minute (permanent) warning before it automatically reboots. More than enough time to save your work before the Feature update!

And for those looking at reporting, click on End user update status in the MEM portal to see which updates devices have applied:

End user update status

Have a different way to configure Update rings for your organization? Let us know below!

You may also like...

6 Responses

  1. shakeel says:

    Hi,
    Does this 7 days maximum period is still applicable?

    • Janusz says:

      Hello Shakeel – thanks for commenting. It looks like the deadline settings are now configurable! Previously that grace period was 7 days by default, and now it can be set from 0-7. I would recommend setting the deadline for feature updates to be 30 days, and the quality updates to the minimum your organization can handle. And leaving the grace period to 7 days to allow the user to decide when to reboot.

  2. Billy Cullen says:

    Hi,

    Thanks for really informative article, it looks like the option “Require user’s approval to restart outside of work hours” has been replaced with Require user approval to dismiss restart notification.

  3. Adam says:

    Trying to wrap my brain around this scenario and how the end-user experience would be. Would the device attempt to install and reboot at 10pm on the 4th Tuesday and if it wasn’t able to it would shift to the 2 day deadline? And if so, where does the “Require user approval to dismiss restart notification” come into play here?

    Servicing channel
    Semi-Annual Channel

    Microsoft product updates
    Allow

    Windows drivers
    Allow

    Quality update deferral period (days)
    7

    Feature update deferral period (days)
    90

    Set feature update uninstall period (2 – 60 days)
    30

    User experience settings
    Automatic update behavior
    Auto install and restart at a scheduled time

    Automatic behavior frequency
    Fourth week of the month

    Scheduled install day
    Tuesday

    Scheduled install time
    10 PM

    Restart checks
    Allow

    Option to pause Windows updates
    Disable

    Option to check for Windows updates
    Enable

    Require user approval to dismiss restart notification
    Yes

    Remind user prior to required auto-restart with dismissible reminder (hours)
    4

    Remind user prior to required auto-restart with permanent reminder (minutes)
    60

    Change notification update level
    Use the default Windows Update notifications

    Use deadline settings
    Allow
    Deadline for feature updates
    7

    Deadline for quality updates
    2

    Grace period
    0

    Auto reboot before deadline
    Yes

    • Janusz says:

      Easiest way to see would be to test with a VM with a previous version of Windows installed! I think you’re correct – from your policy, the “Require user approval to dismiss restart notification” won’t come into play. At 10pm on the 4th Tuesday it would install the update. Then it would perform a 15-minute countdown before it restarts the device. Since we’re performing a scheduled restart, I don’t think users would see the dismissible restart notification prompt.

      If you used the “Auto install at maintenance time” or “notify download” settings instead, then users are prompted to restart based on the deadline date. So in that scenario, at 10pm on the 4th Tuesday they would download/install the update. After it installs, they are prompted to restart, but can dismiss. Since the device will auto-restart in 48 hours (based on deadline), then in 44 hours they will receive the restart notification (assuming the device is being used – if no one is using it, it will auto reboot). After 3 more hours, they will see the permanent restart reminder. Once the 2 days are fully up, it will auto reboot (since there’s no grace period).

      • Adam says:

        Thanks for the insight! So I’ve since re-thought my choices on this and was wondering if I can get some insight again.

        -Quality update deferral days set to 14

        -I’d like to use the setting auto install and reboot during maintenance time but I don’t necessary want to define the active hours since the industry I’m in is healthcare and there’s a decent percentage of devices that are used overnight or 24/7. So far the only option I’ve found that lets the end user choose their active hours or have Windows decide the best active hours is “reset to default”

        -Using the “auto install and reboot during maintenance time” deployment setting, how does it determine to automatically reboot during maintenance time? And how long does it try that? So far in testing I feel like none of my devices actually automatically reboot and I’m always presented with the “2 days to reboot” prompt the next morning.

        -I’d still like to set a deadline of 2 days. Based on your description if I set a 2 day deadline, after 44 hours the end-user will see a restart notification (if being used, otherwise it will auto reboot correct?) and after 3 more hours (final 1 hour left of deadline) they’ll see a non-dismissible restart reminder. Does that sound correct?

        -I’ve tried testing the grace period setting but every device I’ve set it on Intune says the setting is “not applicable to this device” They are all on 20H2 if that matters. If it did work, would this add additional days to the deadline?

        Again, thank you so much for the insight on this.

Leave a Reply

Your email address will not be published. Required fields are marked *