Windows Update policies: deferrals, deadlines and restarts

The patching pillar explains why rings with deadlines are the backbone of a patch process. This guide is the configuration layer underneath it: the exact Windows Update client policies (formerly Windows Update for Business), what each value does on the device, how Group Policy and Intune map to the same Policy CSP, and how to prove a device is actually following the ring you think it is in.

Everything here applies to Windows 11 23H2, 24H2 and 25H2 and to Windows Server when it pulls updates from Windows Update rather than WSUS or Configuration Manager.

How the client decides when to install

Four values drive the whole behaviour, and it helps to see them as a timeline for each update:

1. Release. Microsoft publishes the cumulative update on Patch Tuesday.
2. Deferral. The device does not see the update until the deferral has elapsed (0-30 days for quality updates, 0-365 for feature updates).
3. Deadline. Counted from when the update is offered. Before it, the user can pick a restart time; at it, Windows installs and restarts outside active hours.
4. Grace period. If the device was off or offline and only learns about the update late, it still gets at least this many days before a forced restart.

Without a deadline, a downloaded update can wait for a restart indefinitely, and a device that says "restart required" is not patched. The deadline is the setting that turns a recommendation into a guarantee.

Step 1: clear legacy and conflicting settings

Before configuring rings, remove the settings that silently override them. Run gpresult /h C:\Temp\gp.html on a sample device and look for:

• Specify intranet Microsoft update service location (WUServer and WUStatusServer under HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate). If a WSUS server is configured, the device scans WSUS and your deferrals do not apply to it. On Windows 11, use Specify source service for specific classes of Windows Updates if you need to split classes (for example quality updates from Windows Update, drivers from WSUS).
• Anything in the Legacy Policies folder, in particular No auto-restart with logged on users for scheduled automatic updates installations. It fights compliance deadlines and is the most common reason devices never restart.
• Do not allow update deferral policies to cause scans against Windows Update (dual scan). It does not apply to Windows 11; replace it with the source-service policy above.
• Old registry values pushed by scripts or images under the same WindowsUpdate key. Policy values in that key always win over the Settings app.

Step 2: configure the Group Policy settings

On Windows 11 ADMX templates, the settings are under Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Update, split into Manage end user experience and Manage updates offered from Windows Update. Use the ADMX from the newest Windows release you run in the central store, so older templates do not hide settings.

Automatic Updates itself lives one level down, in the AU subkey. Microsoft's update-compliance guidance recommends not configuring Configure Automatic Updates once deadlines are in place, because the deadline drives installation. If you must set it, use 4 - Auto download and schedule the install (NoAutoUpdate = 0, AUOptions = 4).

Target release version and feature deferral are two ways to control feature updates. Pinning a version is more predictable: the device stays on 24H2 until you change the value, then moves as soon as you do. Don't use both for the same population.

Restart experience

Under Manage end user experience:

• Turn off auto-restart for updates during active hours with a realistic range, or leave active hours to the device's automatic detection.
• Specify deadlines... also has the option Don't auto-restart until end of grace period (ConfigureDeadlineNoAutoReboot = 1). Use it for knowledge-worker rings where a surprise restart would lose work; leave it off for kiosks and shared devices.
• Display options for update notifications: keep the default. Level 2 (UpdateNotificationLevel = 2) hides restart warnings too, which means users get restarted without notice at the deadline.

Step 3: build the same rings in Intune

Intune writes the same values through the Update area of the Policy CSP (./Device/Vendor/MSFT/Policy/Config/Update/..., with names such as DeferQualityUpdatesPeriodInDays, ConfigureDeadlineForQualityUpdates, ConfigureDeadlineGracePeriod and SetDisablePauseUXAccess). You rarely need raw OMA-URIs:

• Devices > By platform > Windows > Manage updates > Windows updates > Update rings: deferrals, deadlines, grace period, auto-restart before deadline, the pause option and the user experience settings. One profile per ring, assigned to a device group.
• Feature updates profiles pin a Windows version. When you use them, set the feature update deferral in the ring to 0 days, as Microsoft recommends, so the two delays don't stack.
• Quality updates profiles let you expedite a specific cumulative update to devices below a given build, overriding deferrals. This is the tool for an actively exploited vulnerability that can't wait for the normal cycle.
• Driver updates profiles give approval control over drivers and firmware offered by Windows Update.

If you use Windows Autopatch, Autopatch creates and manages these ring profiles for you. Edit them through Autopatch rather than creating parallel profiles, or the two will conflict.

Do not target the same device with a Group Policy and an Intune ring. On co-managed devices, move the Windows Update workload to Intune and remove the GPO from those OUs. Microsoft's Windows Update documentation states that Group Policy takes precedence over MDM for update settings; the MDMWinsOverGP setting described in the Intune baselines guide changes that only for policies it covers. For update policies, the cleanest answer is to have only one source.

Step 4: stop a bad update without breaking the model

Rings exist so that you can stop an update that breaks something. Keep the stopping mechanism with IT:

• In Intune, Pause quality or feature updates on a ring profile. Pauses expire after 35 days so they can't be forgotten indefinitely.
• With Group Policy, raise DeferQualityUpdatesPeriodInDays on the affected ring, or use the pause setting inside Select when Quality Updates are received with a start date.
• Uninstalling a cumulative update on devices already hit should be exceptional; check Microsoft's release health page first, since known-issue rollbacks often fix the problem without removal.

Always record why a ring was paused and when it will resume. A forgotten pause is the most common way a whole ring ends up a month behind.

Verify it

On a device, start with the Settings app: Settings > Windows Update > Advanced options > Configured update policies lists every policy in effect and whether it came from Group Policy or Mobile Device Management. Then check the values directly:

# Group Policy values
Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate' |
  Select-Object DeferQualityUpdatesPeriodInDays, ConfigureDeadlineForQualityUpdates,
    ConfigureDeadlineGracePeriod, SetDisablePauseUXAccess, TargetReleaseVersionInfo, WUServer

# Values delivered by Intune (Policy CSP)
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\PolicyManager\current\device\Update' -ErrorAction SilentlyContinue

# Current build and revision
$cv = Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion'
'{0}.{1}' -f $cv.CurrentBuild, $cv.UBR

Install history is in the System log from source Microsoft-Windows-WindowsUpdateClient: event 19 (installation successful), 20 (installation failure) and 43 (installation started). For deeper troubleshooting, Get-WindowsUpdateLog converts the ETW traces into a readable WindowsUpdate.log on the desktop.

Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-WindowsUpdateClient'; Id=19,20} -MaxEvents 20 |
  Format-Table TimeCreated, Id, Message -Wrap

At fleet level, Intune's Windows Update reports (and Autopatch reports) show per-ring compliance. Compare the number of devices on the current revision with the number assigned to each ring, not just the "succeeded" count of the profile.

What breaks

• Devices that never restart. Almost always a legacy restart policy, a missing deadline or UpdateNotificationLevel misuse. Fix the policy, not the user.
• Deferrals ignored. A leftover WUServer value sends the device to WSUS. Check the registry, not just the GPO you think applies.
• Feature update surprise. A device outside any feature-version pin moves to the next release when its deferral ends. Pin the version for every device group.
• Offline laptops restarting on first boot. That is the grace period working as designed; two days is a reasonable compromise.
• Servers patched by the wrong tool. Keep servers out of client ring policies and manage them as described in the hotpatch and cluster guide.

Windows Update client policies only cover Microsoft updates. Browsers, runtimes and other applications need their own process, covered in third-party patching, and the policies here belong in your security baseline documentation like any other setting. See the whole patching and updates area for the rest of the process.

Checklist

• Legacy restart policies, dual scan and stray WUServer values removed
• Current Windows 11 ADMX templates in the central store
• Quality deferral and deadline set per ring, grace period 2 days
• Feature version pinned with target release version or an Intune feature update profile
• Pause removed from the Settings app; central pause procedure documented
• One policy source per device (GPO or Intune), confirmed in Configured update policies
• Expedite process ready for exploited vulnerabilities
• Per-ring compliance measured on build revision, not profile status