Category: Intune

Driver & firmware update management via Intune

image

Walk into most MSP-managed Windows fleets and the update story stops at quality and feature rings.

Drivers? “Windows Update grabs those.” Firmware? “The OEM utility does that.”

That’s not a strategy. That’s three different cooks in the same kitchen, and you’re praying none of them serves up a bad BIOS on a Friday afternoon.

Here’s the real win. Intune has had a dedicated approval surface for driver and firmware updates for a while now. And almost nobody’s switched it on.

What is a driver update policy, really?

It’s a separate Intune profile that sits alongside your existing update rings. It shows you every driver and firmware update Windows Update has queued for your managed devices, and lets you decide — one at a time — whether to ship it.

Approve, pause, defer, hold back the one dodgy NIC driver while the rest go through. All in the portal.

Critically, it’s the same pipeline Windows Autopatch uses for drivers. Five-laptop accounting firm on Business Premium or 500-seat shop on M365 E3 — same surface. You need Intune Plan 1 and a Windows licence that includes the Autopatch entitlement (Business Premium and M365 E3/E5 both have it), devices must be Entra joined or Entra hybrid joined, and telemetry must be set to Required or higher. That’s the lot.

Step-by-Step: switching it on
Check your existing rings aren’t blocking drivers

This is the bit that catches people. If your existing Update Ring or Settings Catalog policy blocks drivers, the whole feature does nothing. In your update ring, set Windows driver to Allow. In the Settings Catalog, set Exclude WU Drivers in Quality Update to Allow Windows Update drivers.

Both default to Allow, but I’ve found plenty of older tenants where someone clicked Block years ago and forgot.

Open the right blade

Sign in to the Microsoft Intune admin centre → Devices → By platform → Windows → Manage updates → Windows 10 and later updates → Driver updates tab → Create profile.

Pick an approval mode

You get two:

  • Automatically approve all recommended driver updates — anything the OEM tags “recommended” gets approved on its own, with a deferral you set between 0 and 30 days.

  • Manually approve and deploy driver updates — every driver lands as Needs review and waits for you.
Approval method:   Automatically approve all recommended driver updates
Make updates       7
available after:

Notice what’s missing? There’s no per-vendor split and no per-device override. One policy, one device — stack two driver policies on the same machine and you’ll fight yourself.

Assign and stage

Pilot group of around 10% — your own laptops, IT, one tolerant power user. Watch it for a fortnight. Then 25%. Then the rest. The per-driver pause button is your friend the first time something breaks.

Why this actually changes behaviour

Most clients have never had a driver controlled by anyone other than Windows Update itself. The first time a Lenovo BIOS update bricks a laptop at 4pm on a Friday, that’s the conversation you do not want to be having with the owner.

With a policy on, you see the update before it hits anyone. You pause it. The rest of the fleet still ships. The client doesn’t even know it happened — and that’s the point.

“But surely Windows Update already knows what’s safe?”

Windows Update knows what applies. It doesn’t know your fleet. You do.

One last wrinkle. The policy doesn’t honour the OEM’s Computer Hardware ID targeting — so managed devices can pick up a newer “recommended” driver even when the OEM reserved a CHID-matched build for that exact model. My recommendation? Use manual approval on hardware you don’t have a spare of in a drawer to test against.

Driver update policies aren’t there to give you more buttons to click. They’re there to take the OEM utility, the random Windows Update behaviour, and the 4pm Friday surprise off the table completely.

If you’re not running one on every managed tenant, you’re outsourcing your hardware change control to luck.

Windows Update for Business rings via Intune

image

Most of the Windows patching pain I see at SMB sites isn’t a Windows problem. It’s a governance problem.

Devices are enrolled. Updates are technically arriving. But there’s no ring. No pilot. No deadline. Patch Tuesday lands, somebody’s accounting machine reboots in the middle of a BAS run, the partner blames “Windows”, and the whole patching conversation gets put off for another quarter.

That’s not a tooling gap. That’s a configuration gap.

And here’s the kicker — Microsoft renamed the whole thing in April 2025. Windows Update for Business is now Windows Update Client Policies, and the deployment service is folded into Windows Autopatch, which is now included with Microsoft 365 Business Premium. If you’re still hand-rolling rings on a Business Premium tenant and ignoring Autopatch, you’re doing more work than you need to.

What update rings really are

An update ring is a Windows Update client policy. It tells the Windows Update client on the device when to look, how long to wait, when to install, and when to reboot. Nothing more.

It’s not a patch repository. It’s not a scanner. It’s a set of timing instructions the device honours when it talks to Microsoft’s update endpoints.

Once you accept that, the rest gets simpler. You’re not pushing patches. You’re staging trust.

Step-by-Step: build a three-ring rollout in Intune

Portal only. No PowerShell.

Open the unified updates dashboard

Sign in to intune.microsoft.com, then go to Devices > By platform > Windows > Manage updates > Windows updates and click the Update rings tab. This is the new unified surface — Microsoft’s docs on managing update rings live here.

Create the Pilot ring

Click Create profile. Name it WUR – Pilot. Quality update deferral: 0 days. Feature update deferral: 0 days. Automatic update behaviour: Auto install at maintenance time. Deadline for quality: 2. Deadline for feature: 2. Grace period: 2.

Assign to a device group of 3-5 representative machines. Not user groups. Devices.

Create the Broad ring

Same shape. Name it WUR – Broad. Quality deferral: 3. Feature deferral: 7. Same deadline/grace as Pilot. Assign to the bulk of your fleet.

Create the Critical ring

WUR – Critical. Quality deferral: 7. Feature deferral: 30. Assign to the boss’s machine, the EFTPOS PC, the design workstation — whatever you can’t afford to surprise.

Three rings. That’s it. Don’t build five.

The deferral / deadline / grace mental model

People get this wrong constantly. Here’s the model in one block.

Deferral  → how many days AFTER Microsoft releases the update
            before the device is even offered it.
Deadline  → how many days AFTER the device sees the update
            before it's force-installed.
Grace     → how many days AFTER install before reboot is forced.

Notice what’s missing? Patch Tuesday as a reference point. The deadline counts from when that device scanned and saw the update — not the calendar. Microsoft moved to this model deliberately to make restart timing predictable across a fleet.

Set them. Don’t leave any of the three blank. Blank means forever on a sleepy laptop.

Why this actually changes behaviour

The mistake isn’t choosing the wrong deferral. The mistake is leaving the pause button in users’ hands.

In the ring settings, set Option to pause Windows updates to Disable. Otherwise a user can park their patches for 35 days, and you’ll find out at the next quarterly review.

Set automatic update behaviour to Auto install at maintenance time with active hours configured. The device patches itself. The user keeps their day. The MSP stops being the villain.

“Why do my updates keep nagging me?”

They don’t, anymore. You set active hours. The reboot finds its time, not yours.

Copilot doesn’t get tired. Neither does Windows Update. Use that.

A word on Autopatch

If the tenant is Business Premium, you now get the full Windows Autopatch service — rings auto-built, rollback on signal, 95% currency SLO. On those tenants, don’t assign hand-built rings to Autopatch-managed devices. They’ll fight each other.

My recommendation? Business Premium tenants → Autopatch. Everything else → three rings, the shape above, locked down so users can’t pause.

Update rings aren’t there to slow patching down. They’re there to remove the conversation about patching completely.

If your clients are still asking when their machines will reboot, you haven’t finished the job.

Endpoint Privilege Management in Intune: a deployment that actually sticks

image

Endpoint Privilege Management (EPM) is the cleanest answer Microsoft has shipped for the local-admin problem. Done well, it lets your tenants run as standard users while still installing approved apps and updating drivers — auditable, just-in-time, no helpdesk ticket. Done badly, you ship a half-configured agent that produces noise, breaks line-of-business apps, and convinces the customer that “least privilege” is somebody else’s problem. Here is how to make EPM stick at an MSP.

The licensing trap nobody warns you about

EPM is not included in Microsoft 365 Business Premium. It needs Microsoft Intune Plan 1 plus either the Intune Suite add-on or the standalone EPM add-on. If your customer is on BP only, you have a quoting conversation before you have a deployment conversation. Confirm assignments under Tenant administration → Intune add-ons before you create a single policy.

While you are there, validate the other prerequisites people skip: devices must be Microsoft Entra joined or hybrid joined, Intune-enrolled (or ConfigMgr co-managed), 64-bit only, and on supported builds — Windows 11 24H2/23H2/22H2/21H2 or Windows 10 22H2/21H2 with the listed cumulative updates. EPM also needs clear line of sight to its endpoints without SSL inspection — this single item kills more pilots than anything else.

See EPM deployment planning for the full prerequisite matrix.

Where to configure

Everything lives in the Intune admin center at Endpoint security → Endpoint Privilege Management. There are two policy types you need to understand:

  • Elevation settings policy — provisions the EPM agent on the device, sets the default elevation response, and turns on reporting. One per device-targeted persona.

  • Elevation rules policy — defines which binaries can elevate, how (Automatic, User confirmed, Support approved, or Elevate as current user), and using which signal (file hash, certificate, or metadata). Up to 100 rules per policy.

Do not configure rules first. The agent does not exist on the endpoint until the settings policy lands. See the EPM overview.

The rollout pattern that actually works

Three rings, audit-first — same as every other Intune deployment that survives contact with users:

  1. Audit ring (week 1–2). Deploy only an elevation settings policy to a pilot device group. Set Default elevation response = Require support approval, Send elevation data = Yes, Reporting scope = Diagnostic data and all endpoint elevations. No rules yet. Let it bake. EPM data is processed once every 24 hours, so resist the urge to declare it broken on day one.

  2. Pilot ring (week 3–4). Use the Overview dashboard and the Frequently unmanaged elevations and Frequently approved by support tiles to identify the real top 5–10 elevation candidates. Build rules for those — prefer publisher certificate + file path over file hash, because hashes change with every app update. Roll into a 20–30 user pilot.

  3. Production ring (week 5+). Widen progressively. Once managed-elevation coverage is high, deploy an account protection policy to remove standing local admin from the user group on those devices. That is the actual goal — the rules are just the bridge.

Build rules from Creating elevation rules. Watch coverage from EPM reports.

Top pitfalls

  • Certificate-rule sprawl. A certificate-only rule allows any binary signed by that publisher to elevate. Some vendors sign their entire catalogue — including tools you did not intend to elevate — with one cert. Always pair certificate with file name or path.

  • SSL inspection on the proxy. EPM telemetry travels over a pinned channel. Decrypt it and the device reports as “not applicable” with no useful error. Add an exclusion before you blame the agent.

  • Forgetting to remove local admin. Shipping rules without ever taking standing admin off the user group means EPM is theatre, not control. The whole point is the standard user.

Get those three right and EPM is a near-magical capability for an MSP. Get them wrong and it is just another agent on the box.

Shipping Intune App Protection Policies for BYOD: What Actually Works in Production

image

App Protection Policies (APP, sometimes called MAM) are the single highest-ROI control in Business Premium for BYOD. You get corporate data containerisation on an unenrolled iPhone or Android device in about an afternoon — if you avoid the usual landmines. Here’s the pattern I ship to MSP clients.

Prerequisites people miss

APP only protects apps that implement the Intune App SDK (Outlook, Teams, Word, Edge, OneDrive, etc.). That’s most of M365, but not every third-party app the user loves. Before you touch a policy:

  • Every targeted user must have an Intune Plan 1 licence (bundled in Business Premium and the E3/E5 stack).

  • Company Portal must be installed on Android. iOS doesn’t strictly need it for MAM-WE (without enrolment), but Authenticator is required for sign-in brokering.

  • For Android, you need the Play Integrity verdict configured if you plan to block rooted devices — and Play Store access, which rules out many China-market devices.

  • Decide now whether you’ll pair APP with a Conditional Access grant of Require app protection policy. If yes, your CA policy needs to exclude break-glass accounts and any service accounts that hit Graph from mobile.

See the App protection policies overview for the full support matrix.

Where to configure

Everything lives in the Microsoft Intune admin center at intune.microsoft.com:

  • Apps → App protection policies → Create policy → pick iOS/iPadOS or Android. You create one policy per platform.

  • Target apps: start with “Selected apps” and pick the core Microsoft apps. Do not start with “All Microsoft Apps” — you’ll regret it the first time Teams Rooms or a hybrid meeting app trips the policy.

  • Data protection settings: align with Microsoft’s Level 2 enterprise enhanced framework as your default. Level 1 is too loose for anyone storing client data; Level 3 breaks copy/paste workflows most SMBs rely on.

  • Access requirements: PIN of 6 digits, biometric allowed, 30-minute offline grace.

  • Conditional launch: jailbreak/root = Block access, min OS version = current−1, max PIN attempts = 5 → Wipe data. Full reference at Conditional launch actions.

The rollout pattern that actually works

Three rings, two weeks each, no exceptions:

  1. Ring 0 — IT and champions (5–10 users). Assign to a dynamic security group. Set Conditional launch actions to Warn, not Block. Let it bake. You are looking for app conflicts, not policy correctness.

  2. Ring 1 — Pilot department (25–50 users). Flip conditional launch to Block. Enable CA “require app protection policy” in report-only mode. Watch sign-in logs for a week — you will find the one user still using the native iOS Mail app.

  3. Ring 2 — Everyone. Move CA to On. Decommission any “allow legacy auth” exceptions at the same time — clients will push back, hold the line.

Use assignment filters (not separate groups) to carve out corporate-owned devices from BYOD rules. It scales; groups don’t.

The three pitfalls that bite

1. Policy conflicts silently pick the most restrictive value. If a user is in two groups with different PIN lengths, they get the longer one — and no error surfaces. Run one policy per platform per persona. Document which group wins.

2. Selective wipe isn’t device wipe. Apps → App selective wipe removes corporate data from managed apps only — photos, personal iMessages, the user’s Spotify library all stay. Train your service desk to say this out loud when an employee leaves. Also: the wipe only fires the next time the user opens the app, and can take 30 minutes.

3. Conditional launch “Min OS version” will brick users overnight. When Apple ships iOS 19 and you’ve set “Min OS version = 18”, a user on 17 walks in on Monday and can’t open Outlook. Always pair Min OS version with a Warn action first, run it for a fortnight, then escalate to Block.

Get these three right and APP is genuinely boring — which, for mobile security, is exactly what you want.

Self-Service Password Reset with writeback: the rollout that doesn’t burn your helpdesk

image

SSPR is a box most MSPs tick on day one of a Business Premium tenant and then never look at again. That’s fine until a hybrid customer calls because Karen changed her password on My Sign-Ins, logged into her domain-joined laptop, and got rejected. SSPR without writeback is half a feature. Here’s how to deploy the whole thing properly.

Prerequisites people miss

The obvious ones — an Entra ID P1 license (included in Business Premium) and either Entra Connect Sync or Entra Connect Cloud Sync — aren’t where rollouts die. The misses are:

  • On-prem AD permissions for the sync account. The account running Connect (or the Cloud Sync provisioning agent) needs Reset password, Change password, Write lockoutTime, and Write pwdLastSet on the user OUs. The Connect wizard grants these if you let it; locked-down AD environments often don’t. Writeback fails silently if these are missing.

  • A matching on-prem password policy. Entra enforces its own complexity rules. If your on-prem policy is stricter (minimum length, history, banned words), a user’s new cloud password will be rejected by AD when it writes back, and the user will see a generic error. Align them before you enable, not after.

  • Combined registration actually enabled and enforced. Legacy SSPR-only registration still exists in old tenants. If users register methods for MFA but not SSPR, the reset flow blocks them.

See Microsoft’s writeback concept doc for the full supported-operations list: https://learn.microsoft.com/en-us/entra/identity/authentication/concept-sspr-writeback(opens in new window).

Where to configure it

Everything is in the Entra admin centre — no PowerShell required for a standard deploy.

The rollout pattern that works

Don’t flip it on tenant-wide. The pattern that doesn’t generate tickets:

  1. Pilot group of ~10 — IT plus two friendly business users. Scope SSPR to that group only. Verify a reset from My Sign-Ins actually lands in AD (pwdLastSet on the DC is your proof).

  2. Registration campaign to the pilot for 14 days. Force them through combined registration. Watch the Registration report for stragglers.

  3. Broaden by department, not by “All users.” Finance first, then ops, then field staff. Each wave gets the campaign a week before the SSPR scope flips.

  4. Protect the registration step with Conditional Access. Use Register security information as the user action and require MFA (or a Temporary Access Pass for new starters): https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-all-users-security-info-registration(opens in new window). Without this, an attacker who phishes a password can register their own MFA method and own the account.

Top pitfalls

  1. Admins can’t use SSPR the same way users can. Privileged roles are locked to strong methods and can’t rely on Security Questions. Test with an admin-tier account before you cut over — and keep a break-glass account that is explicitly excluded from the CA registration policy.

  2. Writeback “works” but the user still can’t log in. Nine times out of ten this is cached credentials on a domain-joined laptop that hasn’t seen a DC since the reset. Tell the user to connect to the corporate network or VPN and lock/unlock. Bake this into your helpdesk script.

  3. Cloud Sync vs Connect Sync confusion. You can run them side-by-side, but writeback must be enabled on whichever one syncs that user’s domain. Audit first — we’ve seen tenants with both running where writeback was enabled on the wrong one and nobody noticed until a reset failed.

Enable it properly once, and SSPR moves from a compliance checkbox to a real helpdesk-deflection tool.

Intune Filters vs Assignment Groups: Stop Treating Them as Interchangeable

image

If your Intune estate has grown past a couple of hundred devices, you’ve probably built a forest of dynamic groups that only you understand. You don’t need another group. You need a filter. Here’s where each one earns its keep, and where MSPs keep getting the split wrong.

The mental model

Groups answer who the policy targets. Filters answer which subset of that assignment it actually applies to at evaluation time. A group is resolved at assignment and refreshed on Entra’s schedule. A filter is evaluated per device, per policy, at the point of applicability. That timing difference is the entire reason filters exist — and the reason swapping one for the other silently changes behaviour.

Use groups for ownership of the assignment (department, site, client tenant, pilot ring). Use filters for device traits that change underneath you: OS version, model, enrollment profile, personal vs corporate, join type.

Prerequisites people miss

  • Filters only work on managed devices and managed apps — the supported workload matrix matters. Not every policy type honours filters, and app assignment filters for MAM are a different object from device assignment filters. Check the reference before assuming your policy can be filtered.

  • Dynamic device groups require at least one Entra ID P1 licence in the tenant. Business Premium covers you, but confirm before promising dynamic membership to an M365 Standard client.

  • The “All users” and “All devices” virtual groups bypass normal targeting logic. If a client’s environment feels “haunted”, check whether a legacy assignment is hitting All devices with no filter.

Where to configure

In the Intune admin center, filters live under Tenant administration → Filters. Build the rule, pick the platform, and save — the filter itself has no targets. You apply it at assignment time on any supported policy (Devices → Configuration → your profile → Assignments → Edit filter).

Groups are managed in the same console under Groups, but remember these are Entra ID security groups — any change you make is tenant-wide, not Intune-only.

The rollout pattern that actually works

  1. Ring by group, scope by filter. Three device groups (Pilot, Early, Broad) assigned by user or device attribute. Apply the same policy to all three with different filters (e.g. deviceOwnership -eq "Corporate" plus osVersion -startsWith "10.0.22").

  2. Exclude filters beat exclusion groups. If you’re excluding kiosks from a CA-backed compliance policy, a filter keyed on enrollmentProfileName is faster to audit than a stale exclusion group nobody refreshes.

  3. Name everything for future-you. FLT-Win11-Corp-NotKiosk beats Filter1. Same for groups: prefix by purpose (INT- for Intune-only, SEC- for CA), include platform, include intent.

  4. Test in report-only. Every new filter goes onto one profile assigned to a lab group first. Confirm the Assignment status report matches expectation before widening.

The pitfalls that will bite you

  • Filter evaluation is not group membership. A filter excluding “personal” devices won’t retroactively remove a policy from a device that was previously “corporate” until the device checks in and the assignment re-evaluates. Plan for the delay during ownership changes.

  • Negation logic is deceptively literal. -notEquals treats a null property as “not equal”, so filters on sparsely populated properties (custom enrollment profile names, model on older hardware) can match devices you didn’t intend. Test with -eq plus include/exclude to lock it down.

  • Overlapping filters on the same assignment don’t AND. If you add a filter and also use include/exclude groups, precedence rules apply — exclude always wins, then filters, then includes. Map this out before complaining about “Intune not applying my policy.”

References

BitLocker Silent Enablement via Intune: The Deployment Pattern That Actually Sticks

image

Every MSP ends up doing BitLocker. Very few do it silently on the first attempt. Between TPM quirks, third-party encryption leftovers, and the three different Intune policy surfaces that all claim to configure BitLocker, the difference between “encrypted fleet with recoverable keys” and “2am call from a locked-out CEO” is a handful of settings. Here’s the pattern to deploy in production under Microsoft 365 Business Premium.

Prerequisites people skip

Silent means standard user, no prompts, no elevation — which is a higher bar than “BitLocker on.”

  • TPM 2.0, ready state, UEFI, Secure Boot on. If the TPM reports “not ready” or is owned by a prior OEM image, silent encryption aborts. Check with Get-Tpm before blaming policy.

  • Entra joined or Hybrid joined. Workgroup and AD-only devices have no key escrow target and will not silently encrypt.

  • No third-party encryption agent. McAfee DE, Sophos SafeGuard, legacy Dell Data Protection — all block BitLocker takeover until fully decrypted and uninstalled.

  • No startup PIN or startup key requirement. Silent mode and pre-boot authentication are mutually exclusive. Pick one.

  • WinRE present and healthy. BitLocker uses it for recovery.

If any of those are wrong, don’t touch policy yet. Fix the device first.

Where to configure it

Ignore the Settings Catalog for this one. Microsoft is explicit that the Settings Catalog does not expose the TPM startup authentication controls silent enablement depends on (docs).

Use the Endpoint security path:

Intune admin center → Endpoint security → Disk encryption → Create Policy → Platform: Windows → Profile: BitLocker.

The settings that actually matter for silent:

  • Enable full disk encryption for OS and fixed data drives: Yes
  • Hide prompt about third-party encryption: Yes
  • Allow standard users to enable encryption during Autopilot: Yes
  • Require device to back up recovery information to Azure AD: Yes (gates encryption on successful escrow — this is the setting that saves you)

  • Recovery password rotation: Enable on Entra and Hybrid-joined devices
  • OS and fixed drive: XTS-AES 256, TPM-only protector, no PIN

Full setting reference: Disk encryption profile settings.

The rollout pattern

Do not target All Devices. Ever.

  1. Pilot ring (5–10 devices): your own, one per client hardware family. Watch the Endpoint security → Disk encryption report for “Encrypted” status and a recovery key present in Entra. If the key isn’t there, the device isn’t safe, regardless of what Windows says.

  2. Early ring (10–20% by dynamic group): let this soak for a week. Check the encryption report daily. Anything stuck in “Waiting for response” usually means TPM readiness or a WinRE issue — remediate per device, don’t loosen policy.

  3. Broad rollout: remaining corporate devices via a dynamic group filtered on deviceOwnership eq "Company". Never include BYO.

  4. New builds: bake the policy into Autopilot so encryption completes during ESP. Standard-user silent enablement only works if “Allow standard users to enable encryption during Autopilot” is Yes — double-check before you cut a new image.

The help desk also needs the recovery-key retrieval flow documented before you go broad, not after the first lockout.

The pitfalls that bite

  • Silent and startup PIN are incompatible. If compliance demands pre-boot auth, you’re running standard BitLocker, not silent. Decide once.

  • Recovery key escrow failures hide in plain sight. Without “Require device to back up recovery information to Azure AD = Yes”, devices encrypt, keys never land in Entra, and you discover it the day a laptop gets stolen. Audit the encryption report monthly — the ground truth is “Recovery key: Yes/No” per device, not policy compliance.

  • Don’t mix endpoint protection + disk encryption profiles targeting the same devices. Conflicts resolve unpredictably. Pick the Disk encryption profile and delete the legacy Endpoint protection one (policy comparison).

Get those three right and BitLocker becomes a checkbox — exactly what your clients are paying for.

Autopilot + ESP: The Deployment Pattern That Actually Survives Contact With Real Users

image

If you’re still PXE-booting laptops in the back room in 2026, you owe your techs a better life. Windows Autopilot with a properly configured Enrollment Status Page (ESP) is the MSP deployment pattern that scales — but only if you stop treating ESP as a tick-box and start treating it as the gate that enforces your security posture before the user ever sees a desktop. Here’s the deploy-it-well version.

Prerequisites People Miss

Business Premium gets you the licensing — Entra ID P1, Intune, and Windows 11 Pro/Enterprise entitlements. The bits that actually bite:

  • Automatic MDM enrollment must be on. Entra admin center → Mobility (MDM and WIP) → Microsoft Intune → MDM user scope = All (or a group). Miss this and the device joins Entra but never enrols into Intune, and the ESP just hangs.

  • Hardware hash registration path. For anything beyond a one-off, get the reseller to register devices to your tenant at purchase. Manual CSV uploads at OOBE are fine for a test VM; they’re a tax on your L1 team in production.

  • TPM 2.0 + device attestation are non-negotiable for self-deploying and pre-provisioning scenarios. VMs won’t cut it, and attestation needs outbound HTTPS to vendor-specific endpoints.

  • Cloud-native over hybrid join. Microsoft’s own guidance is explicit: deploy new devices as Entra-joined. If you’re still standing up the Intune Connector for AD in 2026, have a very good reason written down.

Full list: Windows Autopilot requirements.

Where To Configure

Everything lives in the Microsoft Intune admin center. Two paths you’ll wear out:

  • Deployment profile — Devices → Windows → Device onboarding → Enrollment → Windows Autopilot → Deployment Profiles → Create profile → Windows PC. User-driven, Entra-joined, Standard user account type, hide EULA and privacy settings, set a device name template, allow pre-provisioned deployment.

  • ESP profile — Devices → Device onboarding → Enrollment → Windows tab → Enrollment Status Page → Create. Do not edit the default “All users and all devices” profile — create your own and give it a higher priority.

References: Configure Windows Autopilot profiles and Set up the Enrollment Status Page.

The Rollout Pattern That Works

Three rings, same as your update rings. Don’t skip this.

  1. Pilot (IT / internal). Loose ESP — Block device use = No, timeout 90 minutes, log collection on. You want visibility, not gates.

  2. Early adopters. ESP enforced at the device phase only. Block device use = Yes, timeout 60 minutes, custom error message with your service desk number. Turn off the User / Account Setup phase — the overwhelming majority of ESP failures happen there, and device-targeted apps have already installed by that point.

  3. Production. Lock it. Required blocking apps = your EDR (Defender), BitLocker initiation, and one small “canary” Win32 app that proves apps are actually flowing. No more than five blocking apps total.

Assign both profiles to a dynamic device group filtered on (device.devicePhysicalIDs -any _ -contains "[ZTDId]") so Autopilot-registered devices land automatically.

Top Pitfalls

  • Too many blocking apps. Every blocking app is a potential ESP timeout. Keep it to security essentials; let the rest stream in post-desktop via required assignments.

  • User-phase ESP left enabled. User-targeted apps plus Known Folder Move plus OneDrive sync at first login is a timeout factory. Disable the account setup phase unless you have a specific, measured reason to keep it.

  • Dynamic group latency. Group membership can take minutes to evaluate and devices race ahead of policy. Mitigation: move to Autopilot device preparation (enrollment-time grouping) for new greenfield tenants, or accept the ring-one pilot friction as the cost of dynamic groups.

For the broader lifecycle picture, start at Overview of Windows Autopilot.

Deploy it once, deploy it tight, and your zero-touch goes from aspirational to boring — which is exactly what production should be.