Managing Windows Updates with Intune: Update Rings, Feature Update Profiles, and Driver Update Control

Patching Windows at scale is a release-management problem wearing the costume of a checkbox. The checkbox — “keep devices up to date” — hides the real question every endpoint team eventually has to answer at 09:00 on a Wednesday: why is a quarter of the finance floor stuck on last quarter’s build, why did a storage driver blue-screen forty laptops overnight, and how do I ship an out-of-band zero-day patch to 30,000 machines by end of day without waiting out a 7-day deferral I set myself? Windows Update for Business (WUfB) delivered through Microsoft Intune is the answer, but only if you stop treating “Windows Update” as one thing. It is at least four independent release trains — quality updates, feature updates, drivers, and expedited emergency patches — each with its own cadence, its own gate, its own rollback story, and its own way of going silently wrong.

Intune surfaces WUfB as a handful of policy types that each map onto a Configuration Service Provider (CSP) — the on-device settings interface the Windows Update Agent honours. Get the mapping right and you have deadline-driven compliance, ringed rollouts, per-driver approval, and one-click emergency patching, all reported centrally. Get it wrong — overlapping rings, a feature deferral fighting a feature profile, telemetry blocked so every report reads empty — and you get a fleet that looks patched on the dashboard while a compliance auditor finds machines eight cumulative updates behind. This guide walks the whole surface: designing the rings, configuring every ring setting that actually changes device behaviour, pinning feature versions, gating drivers, expediting zero-days, reading the reports, respecting safeguard holds, and unsticking updates when they wedge.

By the end you will treat Windows updating the way a release engineer treats a deployment pipeline: separate trains, gated rings from pilot to broad, deadlines that guarantee compliance without ambushing users mid-meeting, and a readiness check before every feature jump. You will know which of the four policy types owns each decision, which CSP setting each maps to, what the real defaults and valid ranges are, and — the part that separates a five-minute triage from a two-hour one — exactly where to look on the device and in the portal when an update refuses to install.

What problem this solves

Without a deliberate update strategy, one of two failure modes always wins. Either you leave Windows on its defaults and updates install and reboot whenever they please — users lose unsaved work to a surprise 3pm restart, a bad feature update rolls out to everyone at once, and a driver regression takes down a whole department before anyone notices. Or you clamp everything down “for safety” with long deferrals and pauses, and six months later a security audit finds thousands of devices months behind on cumulative updates, unpatched against actively-exploited CVEs, because nothing was ever forced to a deadline. Both are common. Both are avoidable.

The specific pains this solves: blast radius (a patch that bricks a driver should hit a 200-device pilot on day zero, not 30,000 endpoints simultaneously); compliance drift (deferrals without deadlines let updates slip indefinitely — “offered” is not “installed”); user disruption (forced reboots during active hours, no grace period, no warning); feature-version chaos (devices drifting to whatever build is current, hitting app-compat regressions Microsoft already knows about via safeguard holds); driver roulette (Windows Update pushing a GPU or storage driver that your OEM hasn’t validated); zero-day response (a critical out-of-band patch that your own 7-day deferral is now delaying); and invisible failures (updates stuck for weeks with no error surfaced, because the reporting depends on telemetry that another policy quietly blocked).

Who hits this: every organisation running managed Windows 10/11 through Intune — which since the retirement of on-premises WSUS as a strategic tool is most of them. It bites hardest on regulated fleets (healthcare, finance) where an unplanned reboot on a clinical or trading workstation is a business incident, on large fleets where “roll it to everyone” is not survivable, and on any team that migrated off WSUS by copy-pasting old deferral numbers into a modern feature-profile world and recreated the dual-scan conflict without realising it. The fix is discipline: four release trains, ringed rollout, deadline-driven compliance, telemetry flowing, and a readiness gate before every feature advance.

To frame the whole field before the deep dive, here is every WUfB policy type Intune offers, the release train it governs, and the one decision it owns:

Learning objectives

By the end of this article you can:

• Explain how Intune’s four Windows-update policy types map to WUfB CSPs and the Windows Update for Business deployment service, and why that distinction changes how you troubleshoot.
• Design a pilot → broad ring model in Entra ID security groups with the “critical exclusion” ring most teams forget, and enforce exactly one ring per device.
• Configure every update-ring setting that changes behaviour — quality/feature deferral, deadline, grace period, active hours, restart notifications, user pause access — with the correct defaults and valid ranges.
• Pin a target Windows version with a feature update profile (immediate, scheduled, or gradual rollout) and avoid the dual-mechanism conflict where a ring’s feature deferral silently fights the profile.
• Gate drivers with manual approval, run the applicable/recommended-driver workflow, and ship expedited quality updates for a zero-day in hours instead of days.
• Read the Windows update rings report, the feature update device readiness report, and the quality/feature update failure reports — and know why they read empty when diagnostic data is blocked.
• Recognise safeguard holds as signal not friction, decide when (almost never) to disable them, and pause/resume updates safely during an incident.
• Diagnose a stuck update on the device — UsoClient, the dsregcmd/Get-MpComputerStatus-adjacent update tooling, the PolicyManager registry, %windir%\WindowsUpdate.log, and the deployment-service state in Graph.

Prerequisites & where this fits

You should already have devices enrolled in Intune and Microsoft Entra joined or hybrid Entra joined — WUfB policy is delivered as MDM configuration to enrolled devices, so an un-enrolled or workgroup machine is out of scope. You should be comfortable creating Entra ID security groups (ideally dynamic ones) and assigning Intune policy to them, reading JSON from az rest/Microsoft Graph, and running elevated PowerShell on a Windows endpoint. Familiarity with the Windows servicing vocabulary — cumulative update (LCU), feature update, servicing channel, end of servicing — helps but this article defines each term as it appears.

This sits in the Endpoint Management track, downstream of enrolment and device identity. It assumes the provisioning story from Zero-Touch Windows Provisioning with Intune and Windows Autopilot and, for newer tenants, Windows Autopilot Device Preparation: Entra Join Provisioning and Migrating Off Legacy Autopilot. Ring targeting leans directly on the assignment mechanics in Mastering Intune Assignment Filters and Ring Deployment: Targeting Logic, Precedence, and Safe Rollouts. Update compliance is frequently a gate in Gating Microsoft 365 with Endpoint Conditional Access: Compliance Policies, Device Filters, and Require-Compliant Enforcement, because “device is up to date” is a compliance signal. It pairs with Building Intune Configuration Profiles with the Settings Catalog and ADMX Ingestion for the diagnostic-data and Delivery Optimization settings updating depends on.

A quick map of who owns what during an update incident, so you escalate to the right place:

Core concepts

Six mental models make every later decision obvious.

WUfB is policy, not a content source. Windows Update for Business is not a product you install and it is not a server you run. It is a set of policies telling the Windows Update Agent on each device how to defer, schedule, gate, and reboot for updates it pulls directly from the Microsoft Update service over the internet. Intune only delivers the policy; there is no on-premises content cache in the WUfB model unless you layer in Delivery Optimization (peer-to-peer) or Microsoft Connected Cache. If a device can’t reach Microsoft’s update endpoints, WUfB policy is irrelevant — nothing downloads.

Classic ring vs deployment service — two different engines. The update ring is the classic model: Intune writes Policy/Update CSP settings, and the device’s Update Agent decides everything locally based on them (“set policy, let the device drive”). Feature update profiles, quality update (expedite) profiles, and driver update profiles run through the Windows Update for Business deployment service — a cloud service that orchestrates the rollout, holds offers until your date, ramps gradual rollouts, and tracks rich per-device state. This matters at troubleshooting time: for a classic ring you read the device; for a deployment-service object you can also query Graph for per-device rollout state. The two must not fight over the same release train.

Four release trains, deliberately separate. A quality update is the monthly cumulative (LCU) — security and reliability fixes, cumulative so the latest supersedes all prior. A feature update moves you between Windows releases (Windows 11 23H2 → 24H2) and is the one that breaks app-compat. Drivers/firmware are their own catalog Microsoft and OEMs publish. Expedited updates are emergency out-of-band cumulatives forced past your normal deferral. Treating these as one policy is the original sin; each needs its own cadence and gate.

Deferral offers, deadline compels, grace protects. A deferral delays when an update is offered (0–30 days quality, 0–365 feature). A deadline is what actually guarantees compliance — N days after the offer, the device force-installs and reboots. The grace period is a minimum the user always gets even if the deadline has already elapsed (e.g. a device that was off for a month at enrolment). Deferral without a deadline is how fleets drift; the deadline is the whole point.

Diagnostic data is the reporting oxygen. Both the deployment service and Intune’s WUfB reports depend on Windows diagnostic data reaching Microsoft. If the diagnostic data level is set below Required (by an update ring, a Settings Catalog policy, or a GPO), the deployment service can’t act on the device and the reports read empty even when patching works fine. “Empty report” almost never means “patching failed”; it means “telemetry is blocked.”

A safeguard hold is Microsoft protecting the device. When Microsoft’s telemetry shows a specific hardware/driver/app configuration regresses on a new feature build, it places a safeguard hold blocking that feature offer to affected devices. This is not a bug — it is Microsoft refusing to break your machine. You can force past it, but you’re overriding known-bad telemetry to trade a deferred update for a likely support incident.

The vocabulary in one table

Before the deep sections, pin down every moving part; the glossary repeats these for lookup.

Designing deployment rings

Rings exist to bound blast radius. The entire discipline is: never let an update reach the whole fleet before a representative subset has run it on real workloads for long enough to surface breakage. You express rings as Entra ID security groups, then assign one update ring (and feature/driver profiles) per group with staggered deferrals and rollout dates. Design the population before you touch any policy.

A workable model runs pilot → broad with an explicit exclusion ring:

Ring 3 — the “critical exclusion” ring — is the one teams forget and then regret. These are devices where an unplanned reboot is a business incident: a clinical workstation mid-procedure, a trading desk at market open, a factory-floor OT panel. They still get patched — leaving them unpatched is worse — but on a deliberately longer leash: longer deferral, longer deadline, longer grace, and a feature version that only advances after the broad ring has proven the build for weeks.

The percentages matter less than the representativeness. Ring 1 must contain a genuine cross-section — not just the IT department, whose devices run IT’s software. If Ring 1 is all Surface laptops and the fleet is half Dell desktops, Ring 1 validated nothing about the Dells. Compose pilot rings by hardware model, business unit, and app profile, not convenience.

Dynamic membership so devices self-sort

Manual ring curation rots within a quarter. Use dynamic membership rules so a device lands in the right ring by attribute. Example dynamic rule for a pilot ring keyed off a device naming convention:

(device.deviceOSType -eq "Windows") and (device.displayName -startsWith "PILOT-")

Or by an extension attribute you stamp during provisioning:

(device.deviceOSType -eq "Windows") and (device.extensionAttribute1 -eq "ring1-pilot")

Dynamic groups have a processing lag — a newly-enrolled device can take minutes to hours to land in its group, during which it is in no ring. Account for that: either a broad default ring catches everything by fallback, or you accept new devices are briefly unmanaged for updates.

The one-ring rule

Assign exactly one update ring per device. If a device falls into multiple update rings, Intune resolves the conflict and the losing rings report a conflict state — the device silently ends up on a deferral you didn’t intend. Overlapping rings are the single most common cause of “why is this device on the wrong cadence.” Audit membership regularly for devices in two ring groups at once.

The ring-design settings that vary by ring, and the reasoning for the spread:

Configuring update rings: deferrals, deadlines, active hours, and restart behaviour

Create the ring under Devices > Windows > Update rings for Windows 10 and later > Create profile. The settings split into two blades — Update settings (deferral, servicing channel, restart) and User experience settings (deadline, grace, active hours, notifications). Only some of these change device behaviour meaningfully; here is the complete reference.

The Update settings blade:

The User experience blade — this is where compliance and disruption are actually decided:

Deadline-driven compliance beats the fixed schedule

The legacy model — “auto-install and restart at 3am” — is fragile: laptops are asleep at 3am, or in a bag, and miss the window repeatedly. The modern model is deferral + deadline + grace + active hours, and it is far more reliable. You say: offer this update after 7 days (deferral), give the user 3 days to reboot on their own terms (deadline), never inside active hours, but guarantee at least 2 days even if they were offline (grace). After deadline+grace elapses, Windows force-restarts outside active hours. Set these four and let Windows manage the timing; do not micromanage a fixed clock.

A worked timeline for a Broad-ring device with 7-day deferral, 3-day deadline, 2-day grace, active hours 08:00–18:00:

Driving the ring as code with Graph

If you manage Intune as code, the update ring is a windowsUpdateForBusinessConfiguration resource under deviceManagement/deviceConfigurations. Create a Broad ring: 7-day quality deferral, 3-day deadline, 2-day grace, active hours 08:00–18:00, user pause disabled.

# Create the Broad ring via Microsoft Graph (beta). Uses your az login token.
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,
    "deferFeatureUpdatesPeriodInDays": 0,
    "qualityUpdatesDeadlineInDays": 3,
    "featureUpdatesDeadlineInDays": 5,
    "deadlineGracePeriodInDays": 2,
    "deadlineNoAutoRebootInDays": 0,
    "businessReadyUpdatesOnly": "businessReadyOnly",
    "automaticUpdateMode": "autoInstallAndRestartAtMaintenanceTime",
    "activeHoursStart": "08:00:00.0000000",
    "activeHoursEnd": "18:00:00.0000000",
    "userPauseAccess": "disabled",
    "driversExcluded": true,
    "allowWindows11Upgrade": false
  }'

Note deferFeatureUpdatesPeriodInDays: 0 and driversExcluded: true — the ring defers only quality updates and hands features to a feature profile and drivers to a driver profile. Assignment is a separate call; creation alone does nothing until assigned:

# Assign the ring to the Broad Entra group (creation != assignment)
az rest --method POST \
  --url "https://graph.microsoft.com/beta/deviceManagement/deviceConfigurations/<ringId>/assign" \
  --headers "Content-Type=application/json" \
  --body '{
    "assignments": [
      { "target": {
          "@odata.type": "#microsoft.graph.groupAssignmentTarget",
          "groupId": "<broad-ring-group-id>" } }
    ]
  }'

az rest reuses your az login token, so the signed-in identity needs an Intune admin role and consent for DeviceManagementConfiguration.ReadWrite.All. For unattended automation, use a service principal with that application permission instead of a delegated user token.

Feature update profiles: pinning the target Windows version

Feature updates are the dangerous ones — they change the OS build, and app-compat regressions live here. The correct posture is to pin the feature version explicitly with a feature update profile rather than letting devices drift to whatever is current. A pinned device below the target upgrades to the target and then stays there even when a newer release ships; a device already at the target holds.

Create the profile under Devices > Windows > Feature updates for Windows 10 and later. You choose a target version and a rollout strategy:

Gradual rollout is the safest for large fleets: you set a start date, an end date, and how many days between each batch, and the deployment service releases the offer to slices of the assigned population over that window. Even inside one broad ring you get a mini-ringed rollout for free.

The feature-profile fields and how to reason about each:

The dual-mechanism conflict — the classic silent stuck

A feature update profile and an update ring’s feature deferral must not both act on features. If you use a feature profile, set the ring’s feature update deferral to 0. The profile is authoritative via the deployment service; a non-zero deferral on the ring is a second mechanism negotiating the same offer, and the device appears stuck because two systems are fighting over one release train. This is the modern equivalent of the old WSUS “dual scan” problem, and it is the number-one cause of “feature update never arrives, no error shown.” Let one mechanism own each train: feature profile owns features, ring owns quality, driver profile owns drivers.

Advancing the fleet to a new feature version is a new profile, not an in-place edit for a major jump. Create the next profile pointing at the new version, assign it to Ring 0/1, validate, then expand assignment down the rings. Critically, tie the version pin to the servicing lifecycle — a pinned version that reaches end of servicing stops receiving quality updates entirely, so a “safe” frozen build silently becomes an unpatched liability.

Query existing feature profiles and their state via Graph:

az rest --method GET \
  --url "https://graph.microsoft.com/beta/deviceManagement/windowsFeatureUpdateProfiles?\$select=id,displayName,featureUpdateVersion,rolloutSettings,deployableContentDisplayName"

Quality update profiles and expedited updates for zero-day response

Rings deliberately slow quality updates down. That is correct 11 months of the year and catastrophic the month a zero-day cumulative lands and your own 7-day deferral is now delaying the patch against an actively-exploited vulnerability. Expedited quality updates solve this: they instruct the deployment service to install a specific named cumulative immediately, overriding deferral and most 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 pick the specific released cumulative (the catalog lists them by month/KB) and set how long the user has before the forced restart.

Behaviours you must understand before you rely on it in an incident:

Expedite is for emergencies, not your cadence. If you find yourself expediting every Patch Tuesday, your standard deferrals are too long — tune the rings, don’t lean on expedite. And even in an incident, target Ring 0 first for 30 minutes to confirm a clean install before broadening: a 30-minute pilot is cheap insurance against expediting a broken patch to 30,000 devices.

Driver and firmware update profiles with manual approval

Drivers are the release train most worth gating and the one that most reliably ruins a week when it goes wrong — a bad GPU, storage, or network driver from Windows Update can blue-screen a fleet in an afternoon. Driver update profiles (Devices > Windows > Driver updates for Windows 10 and later) offer two approval modes:

In manual mode the deployment service inventories the applicable drivers across the profile’s targeted devices and presents them as a catalog. Each entry shows the driver name, version, manufacturer, and how many devices it applies to. You approve (with a start date), decline, or leave pending each one. Microsoft classifies inventoried drivers:

The manual driver workflow in practice:

1. Create the manual driver profile and assign it to a ring group.
2. Wait for the deployment service to populate applicable/recommended drivers — this is not instant; it depends on devices checking in and reporting inventory (often 24–48 hours after assignment).
3. Review recommended drivers; approve the ones you want and set a future start date so you can stage per ring.
4. Decline drivers you never want offered — e.g. a GPU driver you manage out-of-band through your OEM’s own tooling. Declining is reversible; when in doubt, decline and revisit.
5. Monitor rollout state per driver in the profile.

This gives you the per-driver control WSUS driver classifications offered, without running WSUS, and it is per-driver rather than per-classification — finer-grained. Pair it with ExcludeWUDriversInQualityUpdate (the “Windows drivers = Block” ring setting) so drivers only come through the approved profile, never sneaking in via a quality scan.

Windows Autopatch: outsourcing the cadence

If operating rings by hand is more than your team wants to own, Windows Autopatch is Microsoft running the whole thing for you: it creates its own deployment rings (Test, First, Fast, Broad), moves devices through them automatically, applies quality/feature/driver/firmware updates on a managed cadence, halts and rolls back on detected problems, and surfaces its own reporting. It is included with the Windows Enterprise E3/E5 licensing many organisations already hold and is enabled from Tenant administration > Windows Autopatch.

Autopatch vs self-managed rings, so you choose deliberately:

Autopatch and hand-built rings are not either/or across the fleet — some organisations run Autopatch for the broad population and keep a hand-managed critical-exclusion ring for OT/clinical devices Autopatch shouldn’t touch. Whichever you pick, the discipline underneath is identical: separate trains, gated rings, deadline-driven compliance, readiness before feature jumps.

Monitoring: WUfB reports, readiness, and safeguard holds

Intune’s WUfB reporting lives in Devices > Monitor (and Reports > Windows updates), and all of it depends on diagnostic data reaching Microsoft. The reports you will live in:

Feature update readiness and safeguard holds

Before pushing a feature update, the feature update device readiness report surfaces devices that are not ready for the target version — flagging safeguard holds where Microsoft knows a specific driver or app breaks on the new build. This report is the gate before every feature jump. Safeguard holds are routinely misread as bugs; they are Microsoft blocking the offer to protect the device.

You can force past a safeguard hold by disabling safeguards in the feature-update path, but do not — barring a documented, Microsoft-sanctioned exception with a known workaround. The hold exists because Microsoft has telemetry showing the build breaks that configuration. Forcing past it trades a deferred update for a likely blue-screen and a support incident. Work the root cause — a patched vendor driver, an updated app — and let the held devices upgrade naturally once the hold clears.

Making the reports work

Empty reports are almost always a telemetry problem, not a patching problem:

Set diagnostic data via a Settings Catalog policy or the ring; the practical minimum for full WUfB reporting is Required with device name allowed.

Pause and resume — the safety valve

When something goes wrong mid-rollout, you pause. Pausing stops new offers for a class of update while you investigate, without ripping out policy. You can pause quality and feature updates independently, from the device (if user pause is enabled) or centrally via policy, for a bounded window.

Two rules: pause narrowly (the affected ring, not the whole fleet — pausing everyone stops security patches for a security scare that may not affect everyone), and remember pause has a hard 35-day ceiling after which Windows force-resumes and scans, so pause is a pressure valve, not a hiding place. Resume deliberately once the issue is understood; don’t let a pause quietly expire and surprise you with a flood of deferred updates.

Architecture at a glance

Picture the system as four release trains flowing left to right from Intune’s control plane, through the Windows Update for Business layer, to the device — with reporting flowing back the other way. On the left sits the Intune control plane: four policy authors (update ring, feature profile, quality/expedite profile, driver profile) each targeting Entra ID security groups that define the rings (Ring 0 Preview → Ring 1 Pilot → Ring 2 Broad → Ring 3 Critical exclusion). These are not four copies of one thing; they are four independent trains that must never fight over the same track.

In the middle, two engines carry the trains. The classic Policy/Update CSP path takes the update ring’s settings — DeferQualityUpdatesPeriodInDays, ConfigureDeadlineForQualityUpdates, ActiveHoursStart/End, ConfigureDeadlineGracePeriod — and writes them to the device, where the Windows Update Agent decides locally when to scan, download, and reboot within active hours against the deadline. In parallel, the Windows Update for Business deployment service — a Microsoft cloud orchestrator — carries the feature, expedite, and driver trains: it holds a feature offer until your gradual-rollout date releases the next batch, forces an expedited CU past deferral in an incident, and surfaces the applicable-driver catalog for manual approval. Both engines pull actual update content from the Microsoft Update service / CDN directly over the internet; Intune never touches the bits, only the policy. If you’ve added Delivery Optimization or Connected Cache, the content hop is served peer-to-peer or from a local cache to spare the WAN, but the decision logic is unchanged.

On the right is the device, running the Windows Update Agent under the resolved policy in HKLM\...\PolicyManager\current\device\Update. Two control signals flow back toward Intune. First, diagnostic data streams from the device to Microsoft — the oxygen for the whole right-to-left reporting path; cut it and the reports go dark. Second, safeguard holds flow from Microsoft to the deployment service and the readiness report: when Microsoft’s telemetry shows the device’s configuration breaks on a target feature build, it stamps a hold that blocks the offer and lights up the readiness report as “not ready.” The reporting plane — Windows update rings report, feature update readiness, quality/feature/expedite failure reports — aggregates all of this back in Intune. Read the architecture as: four trains, two engines, one content source, telemetry back for reporting, holds back for protection. Every troubleshooting move in the next section is “which train, which engine, is telemetry flowing, is a hold in play?”

Real-world scenario

Meridian Health runs ~28,000 Windows 11 endpoints across a hospital network and moved off WSUS to Intune update rings over a quarter. Two months in, the org-wide compliance dashboard looked healthy — 96% up to date on quality updates — but the clinical-workstation fleet (Ring 3, the “critical exclusion” group of ~1,400 devices at nursing stations and in theatres) was stuck on Windows 11 22H2 while every other ring had advanced cleanly to 23H2. No errors surfaced anywhere. The devices simply never received the feature offer. The endpoint team spent a week assuming it was a network or licensing issue before looking at the policy layer.

The cause was the textbook dual-mechanism conflict. The platform team had a feature update profile pinning 23H2 assigned to all rings including Ring 3 — correct. But Ring 3’s update ring also carried a non-zero deferFeatureUpdatesPeriodInDays of 35 days, left over from WSUS-era settings someone had copied wholesale when building the rings. The feature profile (via the deployment service) and the ring’s 35-day feature deferral (via Policy/Update) were both negotiating the same feature offer, and the ring’s long deferral kept winning silently — no error, no report row, just a device that appeared idle. Compounding it, a subset of those clinical devices ran a vendor imaging client that Microsoft had placed a safeguard hold against for 23H2, so even after the deferral was fixed, the readiness report correctly flagged them as not ready.

The fix was two-part and it mattered which part came first. First, they zeroed out the feature deferral on the Ring 3 update ring so the profile became the single authority for the feature train:

# Make the feature profile authoritative: zero the ring's feature deferral
az rest --method PATCH \
  --url "https://graph.microsoft.com/beta/deviceManagement/deviceConfigurations/<ring3Id>" \
  --headers "Content-Type=application/json" \
  --body '{
    "@odata.type": "#microsoft.graph.windowsUpdateForBusinessConfiguration",
    "deferFeatureUpdatesPeriodInDays": 0
  }'

Within 48 hours, roughly 1,100 of the 1,400 devices picked up the 23H2 offer through the profile’s gradual rollout and upgraded during off-shift active-hours windows without a single unplanned reboot on a live workstation — because the deadline+grace+active-hours settings did exactly their job.

Second — and this is the discipline lesson — they did not disable the safeguard hold on the remaining ~300 devices running the vendor imaging client. Forcing past it would have shipped a known-broken imaging experience to devices used in clinical procedures. Instead they opened a case with the imaging vendor, got a patched client, validated it on Ring 0, deployed it via a Win32 app, and let the held devices upgrade naturally once Microsoft’s telemetry saw the fixed client and cleared the hold. Total time to full 23H2 compliance on the clinical fleet: three weeks, zero clinical incidents.

The scenario as a timeline, because the order is the lesson:

Advantages and disadvantages

The WUfB-through-Intune model — policy-driven, cloud-orchestrated, content pulled from Microsoft — is a large upgrade on WSUS for most fleets, but it has sharp edges. Weigh it honestly:

The model is right for standard managed Windows fleets that can reach the internet and want to stop operating patch infrastructure. It bites hardest on air-gapped or heavily network-restricted environments (where the internet dependency is a wall), on teams that migrate from WSUS by copying old numbers (recreating dual-scan conflicts), and on anyone who blocks telemetry for privacy without realising it blinds their own compliance reporting. Every disadvantage is manageable — but only if you know it exists, which is the point of this article.

Hands-on lab

Build a complete ring — an Entra group, an update ring with deadline-driven compliance, a pinned feature profile with the feature deferral correctly zeroed — validate the policy on a device, then tear it down. Runs against a test tenant; use one or two pilot devices you don’t mind rebooting. Commands use az rest against Microsoft Graph beta (run az login first as an Intune admin).

Step 1 — Create the pilot Entra security group.

GROUP=$(az rest --method POST \
  --url "https://graph.microsoft.com/v1.0/groups" \
  --headers "Content-Type=application/json" \
  --body '{
    "displayName": "WUfB-Ring1-Pilot",
    "mailEnabled": false,
    "mailNickname": "wufb-ring1-pilot",
    "securityEnabled": true
  }' --query id -o tsv)
echo "Group id: $GROUP"

Expected: a GUID printed. Add a test device’s Entra object ID as a member via the group’s members/$ref endpoint (or in the portal).

Step 2 — Create the Pilot update ring (2-day quality deferral, 3-day deadline, 2-day grace, feature deferral 0).

RING=$(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 1 - Pilot",
    "deferQualityUpdatesPeriodInDays": 2,
    "deferFeatureUpdatesPeriodInDays": 0,
    "qualityUpdatesDeadlineInDays": 3,
    "deadlineGracePeriodInDays": 2,
    "businessReadyUpdatesOnly": "businessReadyOnly",
    "automaticUpdateMode": "autoInstallAndRestartAtMaintenanceTime",
    "activeHoursStart": "08:00:00.0000000",
    "activeHoursEnd": "18:00:00.0000000",
    "userPauseAccess": "disabled",
    "driversExcluded": true
  }' --query id -o tsv)
echo "Ring id: $RING"

Expected: a GUID. deferFeatureUpdatesPeriodInDays: 0 is deliberate — the feature profile in Step 4 will own features.

Step 3 — Assign the ring to the pilot group.

az rest --method POST \
  --url "https://graph.microsoft.com/beta/deviceManagement/deviceConfigurations/$RING/assign" \
  --headers "Content-Type=application/json" \
  --body "{\"assignments\":[{\"target\":{\"@odata.type\":\"#microsoft.graph.groupAssignmentTarget\",\"groupId\":\"$GROUP\"}}]}"

Expected: HTTP 200 and an assignment object echoed back. Creation without this call does nothing.

Step 4 — Create and assign a feature update profile pinning the target version. Replace the version string with a currently-serviced release.

FEAT=$(az rest --method POST \
  --url "https://graph.microsoft.com/beta/deviceManagement/windowsFeatureUpdateProfiles" \
  --headers "Content-Type=application/json" \
  --body '{
    "displayName": "Feature - Pin Win11 23H2 - Pilot",
    "featureUpdateVersion": "Windows 11, version 23H2",
    "rolloutSettings": { "offerStartDateTimeInUTC": null,
                          "offerEndDateTimeInUTC": null,
                          "offerIntervalInDays": null }
  }' --query id -o tsv)
az rest --method POST \
  --url "https://graph.microsoft.com/beta/deviceManagement/windowsFeatureUpdateProfiles/$FEAT/assign" \
  --headers "Content-Type=application/json" \
  --body "{\"assignments\":[{\"target\":{\"@odata.type\":\"#microsoft.graph.groupAssignmentTarget\",\"groupId\":\"$GROUP\"}}]}"

Expected: two GUIDs and a 200. Null rollout dates mean “as soon as possible.”

Step 5 — Force a policy sync and validate on the device. On the enrolled test device (elevated PowerShell), trigger an MDM sync and read the resolved policy the Update Agent is honouring:

# Force an Intune (MDM) sync so the new policy lands promptly
Get-ScheduledTask | Where-Object { $_.TaskName -like "*PushLaunch*" } |
  Start-ScheduledTask

# Resolved WUfB policy the Windows Update Agent is actually honouring
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\PolicyManager\current\device\Update" |
  Format-List DeferQualityUpdatesPeriodInDays, DeferFeatureUpdatesPeriodInDays,
              ConfigureDeadlineForQualityUpdates, ConfigureDeadlineGracePeriod,
              ActiveHoursStart, ActiveHoursEnd, TargetReleaseVersion, ProductVersion

Expected (after the sync lands): DeferQualityUpdatesPeriodInDays = 2, DeferFeatureUpdatesPeriodInDays = 0, ConfigureDeadlineForQualityUpdates = 3, active hours 8/18, and TargetReleaseVersion / ProductVersion reflecting the pinned build.

Step 6 — Check installed updates and trigger a scan.

# Recent cumulative updates, newest first
Get-HotFix | Sort-Object InstalledOn -Descending |
  Select-Object -First 5 HotFixID, InstalledOn

# Current OS build / feature version
Get-ComputerInfo -Property WindowsProductName, OsVersion, OsBuildNumber

# Trigger a Windows Update scan (the agent then follows your deferral/deadline)
UsoClient StartScan

Expected: a short list of KBs, the current build number, and a scan kicked off. The device now honours the ring’s deferral and deadline for future quality updates and the profile’s pin for features.

Validation checklist. You created a ring group, an update ring with real deadline-driven compliance, and a feature profile with the feature deferral correctly zeroed, assigned all of it, and confirmed the resolved policy on the device via PolicyManager. The single most important validation is that DeferFeatureUpdatesPeriodInDays = 0 while TargetReleaseVersion is set — proof the profile owns features and the ring owns quality, with no dual-mechanism conflict.

Teardown. Remove the assignments and delete the objects so nothing lingers:

az rest --method DELETE --url "https://graph.microsoft.com/beta/deviceManagement/windowsFeatureUpdateProfiles/$FEAT"
az rest --method DELETE --url "https://graph.microsoft.com/beta/deviceManagement/deviceConfigurations/$RING"
az rest --method DELETE --url "https://graph.microsoft.com/v1.0/groups/$GROUP"

Cost note. Everything here is Intune/Entra configuration — no per-object charge. The only “cost” is a test device reboot; do the lab on a machine you can restart.

Common mistakes & troubleshooting

The failure modes are predictable and most are silent — an update that never arrives with no error is the norm, not the exception. First the scannable playbook, then the confirm-detail for the ones that bite hardest.

The expanded detail for the entries that cause the most wasted time:

1. Feature update never arrives, no error, dashboard healthy. The dual-mechanism conflict — the single most common WUfB stuck-update cause. A feature profile (deployment service) pins TargetReleaseVersion, but the ring also carries a non-zero feature deferral (Policy/Update). Two systems negotiate one offer; the ring’s deferral wins silently with no error row. Confirm: on the device, Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\PolicyManager\current\device\Update" shows both DeferFeatureUpdatesPeriodInDays > 0 and TargetReleaseVersion populated. Fix: deferFeatureUpdatesPeriodInDays: 0 on the ring — one owner per train.

2. All reports empty despite patching working. Reporting is telemetry-fed; if diagnostic data is below Required (a Settings Catalog policy, a GPO, or the ring’s own setting), Intune’s WUfB reports and the deployment service both go dark even while the Update Agent patches fine locally. Confirm: reports read empty; check the telemetry level under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\DataCollection or your Settings Catalog policy. Fix: set diagnostic data to Required and allow device name — full reporting typically appears within a day.

4. Feature update “not ready”, won’t install — safeguard hold. Microsoft has telemetry that this device’s driver/app config regresses on the target build and has blocked the offer. Confirm: the feature update device readiness report shows the device with a safeguard-hold reason. Fix: address the root cause (patch the driver/app), then let the device upgrade once the hold clears. Do not disable safeguards to force past it — you’re overriding known-bad telemetry.

5. Update stuck downloading / pending for days. The Windows Update Agent itself is wedged, or the component store is corrupt. Confirm: read %windir%\WindowsUpdate.log (generate it with Get-WindowsUpdateLog on modern Windows, which merges the ETL traces) for the failing phase; try UsoClient StartInteractiveScan. Fix: repair the component store, restart the orchestrator, re-scan:

# Repair the Windows component store, then reset the update pipeline
DISM /Online /Cleanup-Image /RestoreHealth
Restart-Service -Name UsoSvc -Force        # Update Orchestrator
Restart-Service -Name wuauserv -Force      # Windows Update
UsoClient StartInteractiveScan

12. Feature update fails with 0xC1900101 (rollback). A 0xC1900101-family error means Windows Setup rolled back the upgrade during the SafeOS or first-boot phase — almost always a driver incompatibility. Confirm: read the setup logs under $WINDOWS.~BT\Sources\Panther\setuperr.log; the 0xC1900101 is paired with an extended code pointing at the phase. Fix: update the offending driver (storage and graphics are the usual culprits), retry the upgrade; if Microsoft’s telemetry catches the pattern, a safeguard hold may follow, which is the system working.

Best practices

• One owner per release train. Feature profile owns features (ring feature deferral = 0), ring owns quality, driver profile owns drivers (ring drivers = Block). Never let two mechanisms touch one train — that’s the dual-scan trap.
• Always set deferral + deadline + grace + active hours, not just an install schedule. The deadline is what turns “offered” into “compliant”; grace protects offline devices; active hours keeps reboots out of the workday.
• Assign exactly one update ring per device. Audit for devices in multiple ring groups; overlapping rings silently put devices on the wrong cadence.
• Define the critical-exclusion ring first. The clinical/OT/exec devices where a reboot is an incident need a longer leash — longer deferral, longer deadline, longer grace — but they still get patched.
• Make pilot rings representative, composed by hardware model + business unit + app profile, not by convenience. An unrepresentative pilot validates nothing.
• Keep diagnostic data at Required (device name allowed) so the reports and deployment service work. Verify no other policy silently downgrades it.
• Pin feature versions and tie the pin to the lifecycle. A frozen build past end of servicing stops getting quality updates — advance the pin deliberately before servicing ends.
• Gate drivers manually on managed endpoints, with a named owner for the approval queue, and block drivers in the ring so nothing sneaks in via a quality scan.
• Test the expedite process before you need it. Run a dry-run expedite to Ring 0 so the muscle memory (and the 30-minute pilot habit) exists before a real zero-day.
• Treat safeguard holds as signal. Fix the root cause and let the hold clear; forcing past it trades a delayed update for a support incident.
• Pause narrowly and remember the 35-day ceiling. Pause the affected ring, not the whole fleet, and resume deliberately before Windows force-resumes.
• Read the feature-readiness report before every feature advance. It surfaces held and not-ready devices before you push the offer, not after they fail.

Security notes

• Update compliance is a security control, not a convenience. Devices behind on cumulative updates are exposed to actively-exploited CVEs; wire “device is up to date” into your device compliance and Conditional Access gating so out-of-date devices lose access to sensitive resources until they patch.
• Least-privilege the automation identity. The service principal or admin driving WUfB policy via Graph needs DeviceManagementConfiguration.ReadWrite.All and an Intune admin role — not Global Admin. Scope it tightly and audit its use.
• Expedite is your zero-day muscle — the security value of WUfB is largely in being able to force a critical patch fleet-wide in hours. Keep the process documented and tested; a zero-day is the wrong time to learn the workflow.
• Balance telemetry against privacy deliberately. Reporting needs diagnostic data at Required; if a privacy policy blocks it, you blind your own compliance visibility. Make that trade-off consciously, document it, and know which reports go dark.
• Don’t disable safeguards as standing policy. A blanket “disable safeguard holds” setting removes Microsoft’s protection against known-bad builds across the fleet — it’s a foot-gun, not a convenience.
• Protect the driver approval queue. Approving a driver ships kernel-mode code to the fleet; treat approvals as a privileged, reviewed action with an owner, and decline anything you don’t recognise.
• Secure the content path where you cache it. If you deploy Connected Cache or lean on Delivery Optimization peering, make sure the cache/peers are on trusted networks — update content is a high-value tampering target.

Cost & sizing

WUfB through Intune has effectively no per-update licensing cost beyond the Intune/Entra licences you already hold — there is no WSUS server to run, no content storage to provision, no update-infrastructure VMs to patch and back up. That alone is the headline saving versus a WSUS estate. The costs that do exist are indirect:

• Bandwidth. Feature updates are multi-gigabyte; 28,000 devices each pulling a 4 GB feature update directly from Microsoft’s CDN is a serious WAN event. Delivery Optimization (peer-to-peer within a site) and Microsoft Connected Cache (a local cache, either on a Windows server or via an ISP) cut the WAN egress dramatically — often the single most impactful cost lever for large fleets on constrained links. Quality updates are far smaller (hundreds of MB) but monthly.
• Windows Autopatch licensing. Autopatch is typically included with Windows Enterprise E3/E5; if you’re already on those SKUs it’s a “free” operational upgrade, and the real saving is staff time — Microsoft runs the ring cadence instead of your engineers.
• Staff time is the biggest hidden cost of self-management. Designing rings, curating groups, reviewing driver queues, reading readiness reports, and unsticking updates is real ongoing work. For a small team, Autopatch trades some control for a large reduction in that toil.

A rough sizing picture: a self-managed model for ~28,000 devices is one or two endpoint engineers’ part-time attention plus the WAN cost of feature updates (mitigated by DO/Connected Cache to a fraction of naive egress). Autopatch removes most of that engineering time at the cost of the E3/E5 licence (which such an org typically already has) and reduced fine-grained control. There is no free tier to speak of — WUfB is a capability of the Windows + Intune licences, not a metered service — so “cost” here is really “engineering time vs Autopatch, and WAN bandwidth vs caching.”

Interview & exam questions

1. How do Intune’s Windows-update policy types map to WUfB, and which use the deployment service? Update rings write classic Policy/Update CSP settings the device’s Update Agent honours locally. Feature update profiles, quality (expedite) profiles, and driver update profiles run through the Windows Update for Business deployment service, a Microsoft cloud orchestrator that holds offers, ramps gradual rollouts, and tracks rich per-device state. The distinction matters at troubleshooting time — deployment-service objects expose per-device rollout state in Graph; classic rings you read on the device.

2. Why does a feature update sometimes never arrive with no error shown? The dual-mechanism conflict: a feature update profile pins TargetReleaseVersion while the update ring also carries a non-zero feature deferral. Two systems negotiate the same offer and the ring’s deferral wins silently. Fix by setting the ring’s deferFeatureUpdatesPeriodInDays to 0 so the profile is the single authority for features.

3. Explain deferral vs deadline vs grace period. Deferral delays when an update is offered (0–30 days quality, 0–365 feature). Deadline forces installation and reboot N days after the offer — this is what guarantees compliance. Grace period is a minimum the user always gets even if the deadline has already elapsed (protecting long-offline devices). Deferral without a deadline is how fleets drift; the deadline turns “offered” into “installed.”

4. What is a safeguard hold and what should you do about it? When Microsoft’s telemetry shows a specific device configuration regresses on a target feature build, it places a safeguard hold blocking that offer to protect the device. It’s signal, not a bug. Address the root cause (patch the driver/app) and let the device upgrade once the hold clears; do not disable safeguards to force past it — you’d be overriding known-bad telemetry for a likely support incident.

5. How do you ship a zero-day patch to a whole fleet in hours despite a 7-day deferral? Use an expedited quality update profile: select the specific released cumulative and a short restart grace window. Expedite overrides quality deferrals and most pauses via the deployment service, so it reaches even paused/deferred devices. Target Ring 0 first for a short pilot, then broaden — even in an incident a 30-minute pilot guards against expediting a broken patch.

6. Why do all the WUfB reports read empty even though devices are patching? The reports depend on Windows diagnostic data reaching Microsoft. If diagnostic data is below Required — downgraded by a Settings Catalog policy, GPO, or the ring — the reports and the deployment service go dark even while the Update Agent patches fine locally. Set diagnostic data to Required with device name allowed.

7. When would you choose Windows Autopatch over self-managed rings? When you want Microsoft to run the ring cadence, deadlines, feature/driver management, and halt/rollback for you — trading fine-grained control for far less engineering toil. Autopatch is typically included with Windows Enterprise E3/E5. Self-managed rings win when you need maximum control (e.g. a bespoke critical-exclusion ring for OT/clinical devices) or aren’t on the E3/E5 SKUs.

8. How do driver update profiles protect a fleet, and what’s the recommended mode? Manual mode inventories the applicable drivers across targeted devices and installs nothing until you approve each one (with a start date) — per-driver control matching WSUS classifications without WSUS. Manual is the right default for managed enterprise endpoints. Pair it with blocking drivers in the update ring so drivers only arrive via the approved profile, never a quality scan.

9. What does the grace period protect against, and what’s its valid range? It guarantees a device a minimum number of days before a forced restart even if its deadline has already passed — protecting a device that was off for weeks and would otherwise be force-rebooted the moment it comes online. Valid range is 0–7 days; 2–3 is a sane default.

10. A pinned feature version silently stops receiving quality updates. Why? The pinned release reached end of servicing. A pinned version only gets quality updates while it’s within its servicing lifecycle; past that, cumulative updates stop. Tie the feature-profile pin to the lifecycle calendar and advance it before servicing ends.

11. What are the pause limits and the risk of relying on pause? Quality and feature updates can each be paused independently for up to 35 days, after which Windows force-resumes and scans. The risk is a pause silently expiring and flooding devices with deferred updates, or pausing the whole fleet for a scare that affects only some devices. Pause narrowly (the affected ring) and resume deliberately.

12. A device shows 0xC1900101 on a feature update. What is it and how do you fix it? A 0xC1900101-family error means Windows Setup rolled back the upgrade during the SafeOS/first-boot phase — almost always a driver incompatibility (storage or graphics most often). Read $WINDOWS.~BT\Sources\Panther\setuperr.log for the phase, update the offending driver, and retry; a safeguard hold may follow if Microsoft catches the pattern.

These map primarily to MD-102 (Endpoint Administrator) — manage, maintain, and protect devices; deploy Windows client; manage updates — with the identity/compliance-gating angle touching SC-300 and the Autopatch/servicing strategy relevant to MS-102. A compact cert map:

Quick check

1. You use a feature update profile and set a 30-day feature deferral on the same ring. What happens, and what’s the fix?
2. Deferral is 7 days, deadline is 3 days, grace is 2 days. A device was powered off for the first 9 days after the CU released. Roughly when is it forced to install?
3. All your WUfB reports are empty but Get-HotFix on a device shows updates installing fine. What’s the most likely single cause?
4. A feature update readiness report flags a device as “not ready — safeguard hold.” What do you do, and what do you not do?
5. A zero-day cumulative is released. Your broad ring has a 7-day quality deferral. How do you get it installed today, and what’s the one safety step even in an incident?

Answers

1. The feature profile and the ring’s feature deferral both act on the feature offer — the dual-mechanism conflict — and the ring’s 30-day deferral wins silently, so the feature update appears stuck with no error. Fix: set the ring’s deferFeatureUpdatesPeriodInDays to 0 so the profile is the single authority for features.
2. The offer arrives at day 7 (deferral). Deadline is 3 days later = day 10. But the device was offline until day 9, so the grace period guarantees it at least 2 days from when it could act — effectively around day 11, and it’s force-installed outside active hours then. Grace protects the offline device from being rebooted the instant it comes online.
3. Diagnostic data is below Required — some policy (Settings Catalog, GPO, or the ring) downgraded telemetry, so the reports and deployment service go dark even though the Update Agent patches locally. Set diagnostic data to Required with device name allowed.
4. Fix the root cause — patch the offending driver or app Microsoft’s telemetry flagged — and let the device upgrade naturally once the hold clears. Do not disable safeguards to force past it; you’d be overriding known-bad telemetry for a likely blue-screen and support incident.
5. Create an expedited quality update profile for that specific released cumulative with a short restart grace window — expedite overrides the 7-day deferral and most pauses. The one safety step: target Ring 0 first for ~30 minutes to confirm a clean install before broadening, so you don’t expedite a broken patch fleet-wide.

Glossary

• Windows Update for Business (WUfB) — the policy-driven model where devices pull updates directly from Microsoft and Intune-delivered policy controls deferral, deadlines, and gating; not a server or content source.
• Update ring — the classic Intune policy writing Policy/Update CSP settings (deferral, deadline, active hours, restart) the device’s Update Agent honours locally.
• Feature update profile — a deployment-service policy pinning TargetReleaseVersion to a specific Windows release and controlling the rollout (ASAP/scheduled/gradual).
• Quality update / cumulative update (LCU) — the monthly security-and-reliability rollup; cumulative, so the latest supersedes all prior.
• Feature update — an update moving a device between Windows releases (e.g. 23H2 → 24H2); the app-compat-risky train.
• Expedited quality update — a deployment-service policy that forces a named cumulative immediately, overriding deferral and most pauses, for zero-day response.
• Driver update profile — a deployment-service policy approving/declining drivers per-driver, in automatic or manual mode.
• Deployment service (WUfB DS) — the Microsoft cloud orchestrator behind feature, expedite, and driver profiles; holds offers, ramps gradual rollouts, tracks per-device state.
• Deferral — days to delay when an update is offered (0–30 quality, 0–365 feature).
• Deadline — days after the offer before the device force-installs and reboots; the compliance guarantee.
• Grace period — a minimum number of days a user always gets before a forced restart, even if the deadline elapsed (0–7 days).
• Active hours — the window during which Windows will not auto-restart for updates.
• Safeguard hold — a Microsoft-placed block on a feature offer for a configuration its telemetry shows regresses on the target build.
• Windows Autopatch — Microsoft’s managed service that runs update rings, cadence, and reporting for you; typically included with Windows Enterprise E3/E5.
• Delivery Optimization — Windows peer-to-peer content sharing that cuts WAN bandwidth for large updates.
• Microsoft Connected Cache — a local (server or ISP) cache for update content, reducing WAN egress.
• Diagnostic data — Windows telemetry that must reach Microsoft (at Required or higher) for WUfB reports and the deployment service to work.
• PolicyManager registry — HKLM\SOFTWARE\Microsoft\PolicyManager\current\device\Update, where the resolved WUfB policy the Update Agent honours can be read on the device.
• 0xC1900101 — a Windows Setup rollback error family during feature upgrade, almost always a driver incompatibility.
• Critical-exclusion ring — the deliberately slowest ring for devices (OT/clinical/exec) where an unplanned reboot is a business incident.

Next steps

You can now design rings, pin features, gate drivers, expedite zero-days, and unstick updates. Build outward:

• Next: Mastering Intune Assignment Filters and Ring Deployment: Targeting Logic, Precedence, and Safe Rollouts — the assignment and filter mechanics that make ring targeting precise and conflict-free.
• Related: Zero-Touch Windows Provisioning with Intune and Windows Autopilot — get devices enrolled and stamped with the ring attributes your dynamic groups key off.
• Related: Windows Autopilot Device Preparation: Entra Join Provisioning and Migrating Off Legacy Autopilot — the modern provisioning path feeding your update rings.
• Related: Gating Microsoft 365 with Endpoint Conditional Access: Compliance Policies, Device Filters, and Require-Compliant Enforcement — turn “device is up to date” into an access-control gate.
• Related: Building Intune Configuration Profiles with the Settings Catalog and ADMX Ingestion — configure the diagnostic-data and Delivery Optimization settings updating depends on.
• Related: Packaging and Deploying Win32 Apps in Intune: .intunewin, Detection Rules, Dependencies, and Supersedence — ship the patched vendor client that clears a safeguard hold.