Patching Windows at scale is a release-management problem, not a checkbox. Intune gives you four distinct policy types that map to Windows Update for Business (WUfB) CSPs, and using them well means treating quality updates, feature updates, and drivers as separate release trains with their own cadence, gates, and rollback story. This guide walks through designing rings, configuring each profile type, wiring up expedited patches for zero-day response, and monitoring the result.
1. Windows Update for Business architecture and how Intune maps to CSPs
Windows Update for Business is not a product you install. It is a set of policies that tell the Windows Update Agent on each device how to defer, schedule, and gate updates pulled directly from the Microsoft Update service. The device talks to Windows Update over the internet; Intune only delivers the policy. There is no on-premises content cache unless you layer in Delivery Optimization or Connected Cache.
Intune surfaces four policy types, each backed by a Configuration Service Provider (CSP):
| Intune policy | Backing CSP | Controls |
|---|---|---|
| Update rings | Policy/Update (e.g. DeferQualityUpdatesPeriodInDays, ActiveHoursStart) |
Quality update deferral, deadlines, active hours, restart behavior |
| Feature update profiles | Policy/Update/TargetReleaseVersion |
Pins a device to a specific Windows feature release (e.g. 23H2) |
| Quality update profiles (expedited) | Policy/Update via WUfB deployment service |
Force a named cumulative update fast, bypassing deferral |
| Driver update profiles | WUfB deployment service driver approvals | Per-driver approve/decline, automatic or manual |
The newer profile types (expedited quality, feature, and driver profiles) run through the Windows Update for Business deployment service, a cloud service that orchestrates the rollout. The classic update ring is “set policy and let the device decide.” This distinction matters when you troubleshoot, because deployment-service objects show richer per-device state.
Two non-negotiable prerequisites: devices must be Microsoft Entra joined or hybrid joined and enrolled in Intune, and the Microsoft Account Sign-In Assistant service plus telemetry (diagnostic data) must be allowed. The deployment service and reporting both require diagnostic data set to Required or higher, and Windows must be allowed to collect it. If telemetry is blocked by another policy, your reports will be empty even when patching works.
2. Designing deployment rings
Rings exist to limit blast radius. A patch that bricks one driver should hit a pilot group on day zero, not 40,000 production endpoints. Map your population into Entra ID security groups (ideally dynamic groups) before you touch any policy.
A workable four-ring model:
| Ring | Population | Quality deferral | Feature strategy | Purpose |
|---|---|---|---|---|
| Ring 0 - Preview | IT and volunteer testers (~1%) | 0 days | Latest | Catch breakage immediately |
| Ring 1 - Pilot | Cross-section of business units (~5-10%) | 2 days | Pinned, current | Validate on real workloads |
| Ring 2 - Broad | Everyone else | 7 days | Pinned, current | Bulk of fleet |
| Ring 3 - Critical exclusion | Servers-as-workstations, lab kiosks, exec/clinical devices | Long deferral or paused | Pinned, frozen | Slowest, most controlled |
The “critical exclusion” ring is the one teams forget. These are the devices where an unplanned reboot is a business incident. They still get patched, but on a deliberately longer leash with longer deadlines and grace periods.
Use dynamic membership rules so devices land in the right ring without manual curation. Example dynamic rule for a pilot ring keyed off a custom device attribute or naming convention:
(device.deviceOSType -eq "Windows") and (device.displayName -startsWith "PILOT-")
Assign exactly one update ring per device. If a device falls into multiple update rings, Intune applies the ring with the lowest policy conflict outcome and the rest report a conflict. Overlapping rings are the single most common cause of “why is this device on the wrong deferral.”
3. Configuring update rings: deferrals, deadlines, active hours, and restart behavior
Create the ring under Devices > Windows > Update rings for Windows 10 and later. The settings that actually drive behavior:
- Quality update deferral (days): 0-30. How long after release before the device is offered the monthly cumulative update.
- Feature update deferral (days): 0-365. Leave this at 0 if you control feature versions with a feature update profile (recommended) - mixing both causes confusion.
- Deadline settings: this is what guarantees compliance. Set a deadline (days after the update is offered) and a grace period (minimum days the user gets even if the deadline already passed at enrollment). After the deadline plus grace expires, the device will force the restart.
- Active hours: the window during which Windows will not auto-restart. You can let users set their own (within a max range) or enforce a fixed window.
- Auto-restart and notifications: control how aggressively the device nags before a forced restart.
Deadline-driven compliance is far more reliable than the legacy “auto-install and restart at a scheduled time” model. Set deferral plus deadline and let Windows manage the timing within active hours.
If you prefer infrastructure-as-code, drive the same CSP via the Microsoft Graph beta endpoint. The resource is deviceManagement/deviceConfigurations of type windowsUpdateForBusinessConfiguration:
# Create a Broad ring: 7-day quality deferral, 3-day deadline, 2-day grace
az rest --method POST \
--url "https://graph.microsoft.com/beta/deviceManagement/deviceConfigurations" \
--headers "Content-Type=application/json" \
--body '{
"@odata.type": "#microsoft.graph.windowsUpdateForBusinessConfiguration",
"displayName": "WUfB - Ring 2 - Broad",
"deferQualityUpdatesPeriodInDays": 7,
"qualityUpdatesDeadlineInDays": 3,
"qualityUpdatesWillBeRolledBack": true,
"deadlineGracePeriodInDays": 2,
"deadlineForFeatureUpdatesInDays": 5,
"businessReadyUpdatesOnly": "businessReadyOnly",
"automaticUpdateMode": "autoInstallAndRestartAtMaintenanceTime",
"activeHoursStart": "08:00:00.0000000",
"activeHoursEnd": "18:00:00.0000000",
"userPauseAccess": "disabled"
}'
az restreuses youraz logintoken, so the signed-in identity needs the Intune admin role and consent forDeviceManagementConfiguration.ReadWrite.All. For unattended automation, use a service principal with that application permission instead.
After creating the policy, assign it to the ring’s Entra group via the assign action on the configuration object. Assignment is a separate call; creation alone does nothing until assigned.
4. Feature update profiles for pinning target Windows versions
Quality updates are monthly security and reliability fixes. Feature updates move you between Windows releases (22H2 to 23H2 to 24H2) and are the ones that break things. The right posture is to pin the feature version explicitly rather than letting devices drift to whatever is current.
Create the profile under Devices > Windows > Feature updates for Windows 10 and later. You pick a target version (for example, “Windows 11, version 23H2”) and a rollout option:
- Make update available as soon as possible - all assigned devices start moving immediately.
- Make update available on a specific date - the deployment service holds until your date.
- Gradual rollout - the service ramps the offer across a start/end window with a configurable cadence, which is the safest option for large fleets.
Once assigned, the profile sets TargetReleaseVersion so devices will not go past the pinned release even when newer versions ship. Devices below the target are upgraded to it; devices already at the target stay put.
Feature update profiles and the update ring’s feature deferral must not fight. If you use a feature update profile, set the ring’s feature update deferral to 0. The profile is authoritative; a non-zero deferral on top of it leads to devices that appear stuck because two mechanisms are negotiating the same offer. This is the modern equivalent of the old dual-scan problem.
When you are ready to advance the fleet, you do not edit the live profile in place for a major jump. Create the next profile (pointing at the new version), pilot it on Ring 0/1, then expand assignment. Keep the version pin current with your support lifecycle - a pinned version that reaches end of servicing stops getting quality updates entirely.
5. Driver and firmware update profiles with manual approval
Driver updates are their own release train and the one most worth gating. A bad GPU or storage driver from Windows Update can blue-screen a device fleet. Driver update profiles (under Devices > Windows > Driver updates for Windows 10 and later) let you choose between two approval modes:
- Automatic - recommended drivers are approved automatically after a deferral you set (0-30 days). Good for low-risk fleets.
- Manual - nothing installs until you explicitly approve each driver. This is the right default for managed enterprise endpoints.
In manual mode, the WUfB deployment service inventories the applicable drivers across the devices the profile targets and presents them as a catalog. You review each entry (driver name, version, manufacturer, the number of devices it applies to) and approve, decline, or pause it. On approval you set the date the rollout begins.
The workflow in practice:
- Create the manual driver profile and assign it to a ring group.
- Wait for the deployment service to populate applicable and recommended drivers (this is not instant - it depends on devices checking in and reporting inventory).
- Review recommended drivers. Approve the ones you want; set a future start date so you can stage them per ring.
- Decline drivers you never want offered (for example a vendor driver you manage out-of-band through your OEM tooling).
- Monitor rollout state per driver.
“Recommended” drivers are the ones Microsoft and the OEM flag as broadly suitable. “Other” drivers also appear in inventory but are not surfaced as recommended - approve those only with a specific reason. Declining is reversible, so when in doubt, decline and revisit.
Manual approval gives you the same control as WSUS driver classifications without running WSUS, and it is per-driver rather than per-classification.
6. Expedited quality updates for zero-day response
Rings deliberately slow updates down. When a zero-day cumulative update lands and you need it on every device in hours, deferrals work against you. Expedited quality updates solve this: they instruct the deployment service to install a specific named update immediately, overriding deferral and pause settings on the targeted devices, then force a restart within a short, configurable grace window.
Create it under Devices > Windows > Quality updates for Windows 10 and later. You select the specific monthly update (the catalog lists released cumulative updates by month) and set how long the user has before a forced restart (for example, 2 days, 1 day, or immediate).
Key behaviors to understand:
- Expedite overrides quality update deferrals and most pauses, so an expedited patch reaches paused devices.
- It does not override a feature update in progress - finish or pause feature rollouts during an incident.
- It uses the latest applicable cumulative for the device, so a device that is several months behind still lands on the chosen month’s rollup, not a partial state.
- Target it narrowly first if you can (Ring 0), confirm it installs cleanly, then broaden - even in an incident, a 30-minute pilot is cheap insurance.
Expedite is for emergencies, not your normal cadence. If you find yourself expediting every Patch Tuesday, your standard deferrals are too long. Tune the rings instead.
7. Verify
Confirm policy is actually landing on devices and that the deployment service sees them.
On a target device, check the client-side picture with PowerShell. The WUfB-relevant policies are written under the PolicyManager registry path, and the update history is queryable:
# Confirm WUfB deferral/deadline policy is present on the device
Get-ChildItem "HKLM:\SOFTWARE\Microsoft\PolicyManager\current\device\Update" |
Select-Object PSChildName
# Show the resolved Update policy values that the agent is honoring
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\PolicyManager\current\device\Update" |
Format-List DeferQualityUpdatesPeriodInDays, ActiveHoursStart, ActiveHoursEnd,
ConfigureDeadlineForQualityUpdates, TargetReleaseVersion, ProductVersion
Check the actual installed quality updates and confirm the target feature build:
# Installed cumulative updates, most recent first
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5 HotFixID, InstalledOn
# Current OS build / feature version
Get-ComputerInfo -Property WindowsProductName, OsBuildNumber, OsHardwareAbstractionLayer
For the deployment-service view of feature, driver, and expedited profiles, query Graph for the device’s update categories or read the report directly:
# List feature update profile assignment + rollout state objects
az rest --method GET \
--url "https://graph.microsoft.com/beta/deviceManagement/windowsFeatureUpdateProfiles?\$select=id,displayName,featureUpdateVersion,deployableContentDisplayName"
In the portal, confirm three things:
- Devices > Monitor > Windows expedited update failures / Feature update failures show low or zero failures for the ring.
- The update ring shows a per-device deployment status of Succeeded for the pilot group.
- Driver profile shows your approved drivers in the expected rollout state and declined drivers as declined.
If diagnostic data is flowing, the Windows update reports (next section) populate within a day or so.
8. Monitoring with Windows update reports and feature update readiness
Intune’s reporting for WUfB lives in two places and both depend on diagnostic data reaching Microsoft.
- Windows update rings report (per-ring, per-device status: up to date, in progress, error) - your day-to-day compliance view.
- Feature update device readiness report - before you push a feature update, this surfaces devices that are not ready for the target version, flagging known compatibility holds (a “safeguard hold” that Microsoft places when a driver or app is known to break on the new build).
Safeguard holds are important and frequently misread as bugs. When Microsoft knows a specific configuration regresses on a new feature release, it blocks the offer to protect the device. The readiness report tells you which devices are held and why, so you address the root cause rather than forcing past the hold.
To enable rich reporting, ensure devices send the required Windows diagnostic data and that the Enable Windows diagnostic data processor configuration prerequisite is met for tenant-attached reporting. Without diagnostic data set to at least Required, the reports stay empty.
You can force the offer past a safeguard hold by disabling safeguards in the feature update path, but do not. The hold exists because Microsoft has telemetry showing the build breaks that configuration. Forcing past it trades a deferred update for a likely support incident.
Enterprise scenario
A healthcare provider running ~28,000 Windows 11 endpoints moved off WSUS to Intune update rings. Within two months their compliance dashboard looked great, but the clinical workstation fleet (Ring 3, the “critical exclusion” group) was stuck at 22H2 while everyone else advanced to 23H2 cleanly. No errors surfaced - the devices just never got the offer.
The cause was a classic dual-mechanism conflict. The platform team had a feature update profile pinning 23H2 assigned to all rings, but Ring 3’s update ring also carried a non-zero deferUpdatePeriod (35 days) left over from the WSUS-era settings someone copied. The profile and the ring deferral were negotiating the same feature offer, and the ring’s long deferral kept winning silently. Compounding it, those clinical devices ran a vendor imaging client that had a Microsoft safeguard hold against 23H2 - so even after the deferral was fixed, the readiness report flagged them as not ready.
The fix was two-part. First, zero out the feature deferral on the ring so the profile became authoritative:
az rest --method PATCH \
--url "https://graph.microsoft.com/beta/deviceManagement/deviceConfigurations/<ringId>" \
--headers "Content-Type=application/json" \
--body '{"@odata.type":"#microsoft.graph.windowsUpdateForBusinessConfiguration","deferFeatureUpdatesPeriodInDays":0}'
Second, they did not disable the safeguard hold. They worked the vendor for a patched imaging client, validated it on Ring 0, and let the held devices upgrade naturally once the hold cleared. Lesson: let one mechanism own each release train, and treat safeguard holds as signal, not friction.
Checklist
Pitfalls and next steps
The recurring failure modes are predictable. Overlapping update rings silently put devices on the wrong deferral - audit ring membership regularly. Mixing feature deferral on a ring with a feature update profile recreates a dual-scan-style conflict where the device appears stuck; let the profile be authoritative. Empty reports almost always mean diagnostic data is blocked by some other policy, not that patching failed. And a pinned feature version that ages past end of servicing stops receiving quality updates entirely - tie your version pin to the lifecycle calendar and advance it deliberately.
For next steps, layer in Delivery Optimization or Microsoft Connected Cache to cut WAN bandwidth for large feature updates, and consider autopatch if you want Microsoft to manage the ring cadence and reporting for you rather than operating it by hand. Either way, the discipline is the same: separate release trains, gated rings, deadline-driven compliance, and a readiness check before every feature jump.