imPC@ndo IT

Guides / intune

intune-from-zero · Chapter 6 of 11

Windows Update with Intune: rings, deadlines and active hours

Without deadlines the patches are downloaded and never active. Rings, quality tight and feature loose, and why pre-release builds stay switched off.

Updates were deliberately excluded from provisioning: the Enrollment Status Page in chapter 2 has Install Windows updates during OOBE set to No. That was not laziness. It was so they could be governed here, where you can decide when a machine is allowed to restart and what happens if nobody lets it.

What a ring is

You update a small pilot group first, wait, then extend to everyone else. If an update breaks something, you find out on three machines instead of three hundred.

In production the usual shape is:

RingDeferralWho
Pilot0 daysIT and a few volunteers
Broad7–14 daysThe bulk of the fleet
Critical30 daysServers, machines that must not stop

A lab has one ring, which makes the mechanism easy to see: the deferral is what staggers them, and everything else stays identical.

The configuration

Intune → Devices → Windows updates → Update rings → Create profile.

SettingValue
Microsoft product updatesAllow
Windows driversAllow
Quality update deferral0 days
Feature update deferral0 days
Upgrade Windows 10 devices to Windows 11No
Feature update uninstall period20 days
Enable pre-release buildsNot configured

Microsoft product updates set to Allow is worth noticing: it extends Windows Update to Office and the other Microsoft products on the machine, which otherwise update on their own schedule.

The uninstall period is a rollback window. Twenty days is the room you have to reverse a feature update that turned out badly.

User experience

SettingValue
Automatic update behaviourAuto install at maintenance time
Active hours08:0017:00
Option to pause Windows updatesDisable
Option to check for Windows updatesEnable
Change notification update levelDefault
Use deadline settingsAllow
‣ Deadline for feature updates5 days
‣ Deadline for quality updates2 days
‣ Grace period2 days
‣ Auto reboot before deadlineYes

Why these values

Deadlines are the whole policy

Quality tight, feature loose

Two days for quality updates, five for feature updates. That is not a typo, and the asymmetry is deliberate.

Quality updates are the monthly security patches. They close vulnerabilities that are, by definition, already public — often with proof-of-concept code available the same week. Every day of delay is a day of exposure to something known.

Feature updates are the major releases. They change behaviour, occasionally break drivers, and are rarely urgent from a security point of view. More room to discover a problem before the whole fleet has it.

Grace period

Two days during which nobody can be forcibly restarted, regardless of the deadline. It exists for the person coming back from two weeks off, whose machine is behind on six updates and whose first action would otherwise be an unrequested reboot.

Pause: disable

The pause button is the most abused feature in Windows Update. Left available, it turns a patching policy into a suggestion.

Note that Option to check for Windows updates stays enabled. Taking away the pause is reasonable; taking away the ability to ask for updates is just annoying.

Auto install at maintenance time

This installs but does not restart on its own. What forces the restart is the deadline. It is the gentler of the two variants — the alternative, auto install and restart, does exactly what it says at a moment nobody chose.

Combined with active hours of 08:00 to 17:00, a restart never happens during the working day.

Pre-release builds

Assignment and verification

Assign the ring to the device group. Then, on a device:

  1. Settings → Windows Update — the update history should be filling in.
  2. Settings → Windows Update → Advanced options — active hours should show the configured range, greyed out because policy governs them.
  3. The Pause updates option should be absent.
  4. In Intune, Devices → Windows updates → [ring] → Device status, to catch the machine that reports an error rather than the fleet-wide view.