Zero-Touch Windows Provisioning with Intune and Windows Autopilot

A factory-sealed laptop lands on a new hire’s desk in another city. They peel the shrink-wrap, lift the lid, pick a Wi-Fi network, type their work email, approve an MFA prompt — and then they wait. Twenty minutes later the machine is Microsoft Entra joined, BitLocker-encrypted, enrolled in Microsoft Intune, carrying the security baseline, the line-of-business apps, the VPN client and the corporate certificate, and the user is sitting at a desktop that can already reach email and the apps they need. No technician touched it. No golden image was applied. No domain-join script ran over a VPN. That is Windows Autopilot with Intune doing what it was built to do: turn an OEM-fresh device into a managed, compliant, Zero-Trust endpoint from a single sign-in.

The promise is simple to state and easy to get subtly wrong. Autopilot does not image the device — the Windows that ships from Dell, Lenovo or HP stays put. Autopilot redirects the out-of-box experience (OOBE) so that instead of setting up a personal PC, the machine recognises it belongs to your tenant (by its hardware hash), pulls down a deployment profile, runs the Enrolment Status Page (ESP) to install everything that must be present before first login, and joins your identity and management plane. Intune is the engine behind every one of those steps: it stores the device records, evaluates the profile assignments, pushes configuration and compliance policy, delivers apps, and feeds the device’s posture to Conditional Access so that access to corporate data can be made to require a managed, compliant machine. Get the pieces in the right order and the experience feels like magic; get the ESP blocking list, the dynamic group rule, or the join type wrong and you get a half-provisioned laptop that drops the user to an unmanaged desktop — and a support ticket that says “my new computer isn’t set up.”

This guide builds the whole pipeline end to end, the way a senior endpoint engineer wires it: registration and the hardware hash, deployment profiles option-by-option, the ESP and what to block on (and what never to), Entra join versus Hybrid Entra join, the new Autopilot device preparation flow, configuration/compliance/app policy, Win32 packaging into .intunewin, the Conditional Access grant that makes the device a trust signal, Autopilot reset and repurpose, and a full enrolment-troubleshooting playbook. Everything is concrete: real PowerShell, real Microsoft Graph, the exact portal paths, the real error strings, and tables you can keep open while you build.

What problem this solves

Before Autopilot, standing up a corporate Windows device meant imaging: an IT technician wiped the OEM Windows, applied a custom WIM/golden image with apps and settings baked in, joined it to on-prem Active Directory, ran a pile of scripts, and shipped it. That model has three expensive failure modes. It does not scale to remote work — you cannot domain-join a laptop sitting in a home office unless it can reach a domain controller, which means VPN gymnastics during OOBE. It rots — the golden image is stale the day after you build it, so every device drifts from day one and patching has to catch up. And it is touch-heavy — every device passes through IT hands, which is fine for fifty machines a year and ruinous for five thousand.

Autopilot collapses imaging, domain-join, app packaging and hardening into a cloud-driven OOBE the user triggers by signing in. The device records live in Intune/Entra, not on a build bench; the “image” is just OEM-clean Windows plus your policies applied live, so there is no golden image to maintain. Because the join is to Entra ID over the internet, a device can provision from anywhere with Wi-Fi — no line of sight to a domain controller. The build is reproducible (all policy, versioned and assigned), and the device’s compliance posture becomes a live security signal rather than a point-in-time snapshot.

Who hits the pain without this: any organisation past the point where a person can touch every device, anyone supporting remote staff, and anyone implementing Zero Trust who realises they cannot reliably tell “managed corporate laptop” from “personal machine with the password typed in.” What breaks without Autopilot done right is not provisioning per se — you can hand-enrol devices — it is consistency at scale and the trust signal at the end. A 400-laptops-a-month rollout with a two-person team isn’t viable manually, and “require a compliant device” is meaningless if devices were never enrolled into compliance management in a controlled way.

Here is the whole field on one screen — every stage of the zero-touch pipeline, what it does, and where it lives, so the rest of the article has a spine:

Learning objectives

By the end of this article you can:

• Register devices with Autopilot four ways — OEM/CSP at purchase, the Get-WindowsAutopilotInfo hardware-hash CSV, the Microsoft Store for Business, and via Microsoft Graph — and explain when each fits.
• Build a user-driven deployment profile end to end: deployment mode, join type, OOBE hide-and-skip settings, device-name templates, and the assignment to a dynamic device group.
• Choose correctly between Entra join and Hybrid Entra join, and articulate why cloud-only is the default and Hybrid is a legacy bridge.
• Configure the Enrolment Status Page so it blocks on the right things (the small set that must precede login) and never on heavy, network-bound apps that blow the timeout.
• Stand up the new Autopilot device preparation experience and explain how it differs from classic Autopilot (no hardware-hash registration, device-prep groups, a 90-minute SLA).
• Author configuration profiles (Settings Catalog, LAPS, security baseline), a real compliance policy with graduated noncompliance actions, and deliver Microsoft 365 Apps, store apps and Win32 apps packaged into .intunewin with correct detection rules.
• Wire Conditional Access so corporate access requires a compliant, managed device, turning the endpoint into a Zero-Trust signal.
• Reclaim a device with Autopilot reset and repurpose/wipe, and run a structured enrolment-troubleshooting playbook against the real error codes (0x80180014, 0x80180018, 801c03ea, ESP timeouts and more).

Prerequisites & where this fits

You should already have a working Microsoft Entra ID tenant with Intune licensing (Microsoft 365 E3/E5, EMS E3/E5, or standalone Intune Plan 1) assigned to the users who will enrol — Autopilot itself needs no separate license. You need the Global Administrator or Intune Administrator role to configure enrolment, and enrolling users must hold an Intune license or enrolment fails at the MDM step. Be comfortable in the Intune admin center and Entra admin center, able to run elevated PowerShell, with a test device (a VM works for the lab, though TPM/Secure Boot differ from real hardware) or an OEM hardware-hash CSV.

Two tenant switches must be on before anything works. Automatic MDM enrolment so an Entra-joining device hands itself to Intune: Entra admin center → Devices → Mobility (MDM) → Microsoft Intune → MDM user scope = All (or a pilot group). And enrolment restrictions permitting Windows corporate enrolment: Intune → Devices → Enrolment → Enrolment device platform restrictions. For Hybrid Entra join you additionally need Entra Connect, the Intune Connector for Active Directory on a domain-joined server, and DC line of sight during OOBE — exactly the constraint cloud-only Entra join removes.

This is the foundation of the endpoint management track — upstream of everything else you do with Intune. Once devices enrol cleanly you layer on Building Intune Configuration Profiles with the Settings Catalog and ADMX Ingestion for state, Packaging and Deploying Win32 Apps in Intune for app delivery, Mastering Intune Assignment Filters and Ring Deployment for who-gets-what, and Managing Windows Updates with Intune to keep them current. The payoff is the Zero-Trust gate — Gating Microsoft 365 with Endpoint Conditional Access and Zero Trust on Microsoft Entra: Conditional Access + PIM — and the new provisioning model is in Windows Autopilot Device Preparation.

Core concepts

Five mental models make every later decision obvious.

Autopilot redirects OOBE; it does not image. The Windows that ships on the device is what runs. Autopilot’s only job is to make the out-of-box experience recognise the device as corporate and run your setup instead of the consumer one. The “image” is OEM-clean Windows plus the policies and apps Intune applies live — which is why there is no WIM, no driver injection, no sysprep, and “the build” is entirely a set of versioned, assigned policies rather than a binary on a share.

The hardware hash is the device’s identity to Autopilot. Before a device can get a deployment profile, the tenant must know it — and it knows it by a hardware hash (a ~4 KB blob derived from TPM, firmware and hardware identifiers, also called the hardware ID or 4K HH). Registration is the act of uploading that hash so a record appears under Windows Autopilot devices. The classic flow lives or dies on this: no hash, no profile, normal consumer OOBE. (The new device preparation flow removes this requirement, which is its headline advantage — more on that below.)

Profiles are assigned to groups, and groups must be settled before enrolment. A deployment profile reaches a device because the device is in a group the profile is assigned to — typically a dynamic device group whose membership rule matches all Autopilot-registered devices (or a slice of them by Group Tag). The non-obvious trap: dynamic group membership is evaluated asynchronously, so a device can begin enrolling before it lands in the group, miss the profile, and fall through to consumer OOBE. Deterministic membership (assigned groups, or a Group Tag stamped at registration) is how you avoid the race.

The ESP is the “feels managed from first boot” gate. The Enrolment Status Page is what stands between OOBE and the desktop. It tracks three phases — device preparation (secure-boot/TPM, profile download), device setup (security policies, certificates, network, required device-context apps), and account setup (the user signs in, user-context apps and policies land) — and can block the desktop until the items you designate as required are installed. Block on the right small set and the user lands on a ready machine; block on a heavy, internet-pulled app and the ESP times out and dumps them to a half-built desktop.

Compliance is the trust signal; configuration is the state. Two policy types look similar and do opposite jobs. A configuration profile sets state — it turns BitLocker on, deploys LAPS, applies the security baseline, pushes Wi-Fi and certs. A compliance policy reports state — it evaluates whether the device meets your bar (encrypted, Secure Boot on, minimum OS, Defender healthy) and stamps the device compliant or noncompliant in Entra. That stamp is what Conditional Access reads. Configuration makes the device good; compliance proves it is good to the access-control plane. You need both, and you must not confuse “I deployed a BitLocker config profile” with “the device is reported compliant.”

The vocabulary in one table

Pin down every moving part before the deep sections; the glossary repeats these for lookup.

Registering devices: getting the hardware hash into the tenant

Everything in the classic flow starts with the tenant knowing the device. There are four routes to get a hardware hash registered, and the right one depends on your buying relationship and scale.

OEM / CSP registration at purchase is the gold standard for new hardware: buy Autopilot-enabled devices from Dell, Lenovo, HP or a CSP, supply your tenant ID, and they register the hashes directly into your tenant — devices appear under Autopilot devices before they ship, zero effort on your side. This is how you buy at scale; it removes manual collection entirely.

The Get-WindowsAutopilotInfo script registers devices you already own, or one-offs. Run it elevated; it can upload directly (interactive sign-in) or export a CSV for bulk import:

# On the device, elevated PowerShell. Allow the script and install the collector.
Set-ExecutionPolicy -Scope Process RemoteSigned -Force
Install-Script -Name Get-WindowsAutopilotInfo -Force

# Option A — upload straight to your tenant (interactive Entra sign-in, then MFA)
Get-WindowsAutopilotInfo -Online -GroupTag "KV-FIELD"

# Option B — export the 4K hash to CSV for bulk import via the portal/Graph
Get-WindowsAutopilotInfo -OutputFile .\AutopilotHWID.csv -GroupTag "KV-FIELD"

Import the CSV at Intune → Devices → Enrolment → Windows → Autopilot devices → Import. The CSV must carry the device serial number, the Windows product ID, and the 4K hardware hash; the optional Group Tag column is how you pre-stamp the deterministic group label.

Microsoft Graph is how you automate registration in a pipeline (e.g. a provisioning workstation that registers and tags devices in bulk). The relevant resource is windowsAutopilotDeviceIdentity:

# Modern: use the Microsoft.Graph PowerShell SDK
Connect-MgGraph -Scopes "DeviceManagementServiceConfig.ReadWrite.All"

# Import a hardware identity (hash truncated for illustration)
$body = @{
  serialNumber       = "5CG1234ABC"
  productKey         = "..."
  hardwareIdentifier = "<base64-4K-hash>"
  groupTag           = "KV-FIELD"
}
New-MgDeviceManagementWindowsAutopilotDeviceIdentity -BodyParameter $body

The Microsoft Store for Business / Intune sync path applies to certain reseller and store flows; in practice for most orgs it is OEM/CSP or Get-WindowsAutopilotInfo. The registration routes, side by side:

Two things bite people. First, registration is not instant — after import the device must finish processing (status moves from importing to registered/assigned) and profile assignment then waits on the dynamic group to evaluate, so allow several minutes and never re-image expecting the profile to already be there. Second, stamp a Group Tag at registration so the dynamic group is deterministic (the rule matches the tag, not hash-arrival order) — the single biggest defence against the “enrolled before the group evaluated” race. (You can set or change a tag after the fact via Graph; the call is shown in the Real-world scenario below.)

The deployment profile, option by option

A deployment profile is the object that redirects OOBE. Create it at Intune → Devices → Enrolment → Windows → Deployment Profiles → Create profile → Windows PC. Every setting has a real consequence; here is each one.

Deployment mode and join type

Deployment mode is the first fork. User-driven is the overwhelming default: the device personalises to the user who signs in during OOBE, who becomes the primary user. Self-deploying provisions with no user interaction — for kiosks, signage and shared devices — and needs hardware with a TPM 2.0 supporting device attestation (most VMs cannot self-deploy). Pre-provisioning (formerly White Glove) lets IT or an OEM run the heavy device-setup phase before the device reaches the user, so the user only does the quick account-setup phase — a near-instant first login while still shipping to the end user.

Join type is the second, larger fork, covered in its own section below. The profile’s OOBE settings then control what the user sees:

The user account type = Standard choice deserves emphasis: leaving it at Administrator silently makes every enrolling user a local admin, which is a posture you almost never want and is hard to claw back later. Set Standard and grant elevation surgically with Implementing Intune Endpoint Privilege Management: Elevation Rules, Approval Flows, and Audit.

Device name templates

The name template sets the computer name during provisioning: %SERIAL% injects the device serial, %RAND:x% injects x random digits. Names must be ≤ 15 characters (NetBIOS), so KV-%SERIAL% (→ KV-5CG1234ABC) can overflow on long serials while KV-%RAND:8% (→ KV-48291730) stays deterministic and in-bounds — safer for mixed fleets. A consistent scheme keeps your device list, dynamic groups and audit trails legible.

Assigning the profile to a group

The profile reaches devices through assignment to a group — almost always a dynamic device group that captures Autopilot-registered devices. The canonical rule catches all Autopilot devices; a Group-Tag-scoped rule catches a slice:

# Dynamic device group — ALL Autopilot-registered devices
(device.devicePhysicalIDs -any (_ -contains "[ZTDID]"))

# Dynamic device group — only devices stamped with a specific Group Tag (deterministic)
(device.devicePhysicalIds -any (_ -eq "[OrderID]:KV-FIELD"))

The [OrderID] token is how the Group Tag surfaces in devicePhysicalIds. Prefer the tag-scoped rule for production rings — it is deterministic, killing the most common Autopilot race condition. Profile/group/assignment as a checklist:

Entra join vs Hybrid Entra join: pick cloud-only

The single most consequential profile choice is join type, and the modern answer is almost always Microsoft Entra joined (cloud-only). Understanding why saves you from inheriting someone else’s legacy decision.

Entra join registers the device’s identity solely in Entra ID — no on-prem AD dependency, no domain-controller line of sight, provisioning from any internet connection, managed entirely from the cloud. This is the design Autopilot was built around and what Microsoft recommends for all new deployments.

Hybrid Entra join joins the device to both on-prem AD and Entra ID, to bridge organisations with deep on-prem dependencies (unmigrated Group Policy, Kerberos file shares, legacy domain-auth apps). It is materially more fragile during Autopilot: the device must reach a domain controller at OOBE (remote provisioning needs awkward VPN-during-OOBE), you must run the Intune Connector for Active Directory to create the AD computer object, Entra Connect must sync it back to Entra, and a timing dependency appears (the device waits for the synced object). Microsoft positions Hybrid as a transitional state, not a destination. If you are building something new, build Entra join.

If you are currently Hybrid and want to move, that migration — and the new provisioning model that makes it cleaner — is the subject of Windows Autopilot Device Preparation: Entra Join Provisioning and Migrating Off Legacy Autopilot.

The Enrolment Status Page: blocking on the right things

The ESP is the make-or-break component for user experience — the progress screen between OOBE and the desktop that can block the desktop until the items you mark required have installed. Configure it at Intune → Devices → Enrolment → Windows → Enrolment Status Page.

It runs in three tracked phases. Device preparation validates Secure Boot/TPM and downloads the profile. Device setup applies device-context items: security policies, certificates, Wi-Fi profiles, and any device-context apps you mark blocking. Account setup runs after the user signs in, landing user-context policies and apps. The crucial design decision is the blocking list — and the universal failure mode is blocking on too much.

The golden rule: block only on the small set of things that genuinely must exist before the user’s first login, and deliver everything else as required but non-blocking so it installs after the desktop appears. Blocking on a heavy, internet-pulled agent over a saturated link is how you get the classic ESP timeout that dumps the user to a half-built desktop. What belongs where:

The new Autopilot device preparation

Classic Autopilot’s biggest friction points are exactly the two this article keeps flagging: the hardware-hash registration step and the dynamic-group timing race. Windows Autopilot device preparation is Microsoft’s redesigned provisioning flow that removes both. It is configured at Intune → Devices → Enrolment → Windows → Device preparation policies and represents the direction of travel for Entra-join provisioning.

What changes: there is no hardware-hash registration — a device qualifies because the enrolling user is in scope of a device-preparation policy. Instead of a dynamic group that must evaluate, you name a device group (the device is added to it during provisioning) and user scope directly in the policy, removing the asynchronous-membership race. It targets a 90-minute SLA, surfaces clearer status, and is Entra join only.

When to use which: classic remains correct if your hardware comes OEM-registered, you run an established classic estate, or you still need Hybrid. For net-new Entra-join provisioning, device preparation is the cleaner build, and many organisations run both during transition. The deep mechanics, the device-prep group model, and migrating an existing estate are in Windows Autopilot Device Preparation: Entra Join Provisioning and Migrating Off Legacy Autopilot.

Configuration, compliance and app policy

With enrolment working, the device needs state (configuration), a posture verdict (compliance), and tools (apps). These three policy families are the substance of what “managed” means.

Compliance policy: the trust signal

A compliance policy evaluates the device against your security bar and stamps it compliant or noncompliant in Entra — the verdict Conditional Access consumes. Create one at Intune → Devices → Compliance → Create policy → Windows 10 and later. A sensible baseline and the graduated actions that go with it:

The actions for noncompliance are where you tune the user experience versus the security gate. Grace periods matter: stamping a device noncompliant immediately on a transient blip can lock a user out mid-task, so graduate the actions:

The compliance verdict reaches Conditional Access through the device compliance integration; the policy and its filters are explored in depth in Gating Microsoft 365 with Endpoint Conditional Access: Compliance Policies, Device Filters, and Require-Compliant Enforcement.

Configuration profiles: setting state

A configuration profile applies state. The modern authoring surface is the Settings Catalog (the full breadth of CSP settings, searchable), supplemented by security baselines (curated Microsoft bundles) and templates for specific payloads (Wi-Fi, VPN, certificates). Three you will almost always deploy:

# 1) Windows LAPS via Settings Catalog — rotate the local admin password to Entra
Devices → Configuration → Create → Windows → Settings catalog
  Local Admin Password Solution (LAPS):
    Backup Directory   = Microsoft Entra ID
    Password Age (days)= 30
    Password Complexity= Large letters + small letters + numbers + specials
    Password Length    = 20

# 2) Security baseline — apply Microsoft's recommended hardening
Devices → Security baselines → Security Baseline for Windows 10/11 → Create profile

# 3) Wi-Fi / certificate profile (template) — push corporate Wi-Fi + root cert
Devices → Configuration → Create → Windows → Templates → Wi-Fi / Trusted certificate

Deeper authoring, ADMX ingestion and the order-of-precedence rules live in Building Intune Configuration Profiles with the Settings Catalog and ADMX Ingestion.

App delivery

Three app types cover almost everything. Microsoft 365 Apps is a built-in type — pick the channel (Monthly Enterprise), bitness (64-bit) and languages, and Intune deploys Office. Microsoft Store apps cover modern packaged apps; Win32 apps (next section) cover everything else as .intunewin packages. Each app is assigned Required (Intune installs it), Available (user installs on demand from Company Portal), or Uninstall.

Win32 app packaging into .intunewin

Most real-world apps are traditional Win32 installers (EXE/MSI), and Intune delivers them wrapped into a single .intunewin package built with the Microsoft Win32 Content Prep Tool (IntuneWinAppUtil.exe). The wrapping is mechanical; the part that bites is the detection rule — how Intune decides the app is installed.

# 1) Wrap the installer folder into a .intunewin package
#    -c source folder, -s the setup file inside it, -o output folder
.\IntuneWinAppUtil.exe -c .\Source -s setup.exe -o .\Output

# 2) In Intune → Apps → Windows → Add → Win32 app, upload the .intunewin and set:
#    Install command:   "setup.exe /quiet /norestart"
#    Uninstall command: "setup.exe /uninstall /quiet"
#    Install behaviour: System  (installs in device context)
#    Detection rule:    see below — this is the part that breaks

The detection rule is the single most common cause of Win32 grief: get it wrong and the app either reinstalls forever (detection never matches) or reports “failed” (detection matches the wrong thing). Pick the rule type that deterministically proves this version is present:

Two more mechanics matter for a clean first-login: install context (System for machine-wide apps present before sign-in; User for per-user) and return codes (map exit codes so a 3010 is “soft reboot” success, not failure). Mark only lightweight, must-have required Win32 apps as ESP-blocking. The full treatment — detection scripts, dependencies, supersedence and requirement rules — is in Packaging and Deploying Win32 Apps in Intune: .intunewin, Detection Rules, Dependencies, and Supersedence.

Tying it to Zero Trust with Conditional Access

The payoff of everything above is that the device’s compliance verdict becomes an access-control signal. In Conditional Access you add a grant that requires a managed, compliant device before corporate data is reachable — so only Intune-enrolled, compliant, BitLocker-encrypted machines open email and line-of-business apps, and an unmanaged personal PC with the right password is still turned away.

Create a policy at Entra → Protection → Conditional Access → Create new policy:

Two non-negotiables. Always exclude your break-glass/emergency-access accounts from device-based CA — a misconfiguration that locks out your only admin locks you out of the tenant; see Zero Trust on Microsoft Entra: Conditional Access + PIM, Step by Step. And start in report-only mode, watch the sign-in logs for unexpected blocks, then flip to On. The persona-based way to design these at scale is in Designing Conditional Access at Scale: A Persona-Based Policy Framework with Authentication Context and Filters, and pairing the compliant-device gate with Rolling Out FIDO2 Passwordless Authentication in Entra ID gives you phishing-resistant auth on a known-good device — the heart of Zero Trust for endpoints.

Autopilot reset, repurpose and the device’s second life

A device outlives its first user. Autopilot reset and wipe/repurpose are how you reclaim it cleanly without re-registering the hardware (the Autopilot record persists, so the device re-provisions on next sign-in).

Autopilot reset removes user data, user-installed apps and personal settings, keeps the device enrolled and Entra-joined, re-applies device-targeted policies, and returns the machine to a first-login state for the next user — without a full OS reinstall. It is the right tool for reassigning a laptop within the org. Trigger it remotely from Intune (Devices → select device → Autopilot reset) or locally on the lock screen (Ctrl+Win+R, then sign in with admin/Autopilot credentials).

Wipe does a fuller reset (optionally retaining enrolment), Fresh Start removes OEM bloat, and Retire removes the device from management (used at end of life or when handing a personal/BYOD device back). The reclamation options, side by side:

A subtle but important point: deleting the device from Intune or Entra does not delete the Autopilot record — the hardware hash registration is a separate object. If a device is being permanently decommissioned or sold, delete the Autopilot device record too (Autopilot devices → select → Delete), or the serial stays claimed by your tenant and the next owner cannot register it elsewhere.

Architecture at a glance

Picture the zero-touch pipeline as a left-to-right line that begins before the device powers on and ends with the device acting as a Zero-Trust signal. On the far left sits registration: the device’s hardware hash is in your tenant (placed by the OEM, Get-WindowsAutopilotInfo, or Graph), so an Autopilot device record exists under Intune, optionally stamped with a Group Tag that makes the device a member of a dynamic device group to which a deployment profile is assigned. (In the newer device-preparation flow there is no hash and no dynamic group — a policy targets the user and adds the device to a named group directly — but the downstream stages are identical.) The user powers on and hits OOBE; because the device matches an Autopilot record, OOBE is redirected: it pulls the profile, the corporate branding appears, and the user signs in and approves MFA. At sign-in the device performs the Entra join and, because automatic MDM enrolment is on, enrols into Intune, and the ESP runs its three phases — device preparation, device setup, account setup — holding the desktop until the required blocking items land.

From there, Intune pushes the substance: configuration profiles apply state (LAPS, baseline, Wi-Fi, root certs), compliance policy evaluates the device and stamps it compliant in Entra, and apps install (M365 Apps, Win32 and store apps, the heavy ones non-blocking). Finally that compliant stamp flows to Conditional Access: a policy that requires a compliant device reads the signal, so this encrypted, managed laptop reaches email and corporate apps while an unmanaged machine is blocked. One continuous line from a serial number in a CSV to a Zero-Trust endpoint — Intune the engine at every stage, the ESP the gate that makes it feel managed from first boot.

Real-world scenario

Northwind Retail ships about 400 Dell laptops a month to field stores across the country, provisioned by a two-person endpoint team. They had classic user-driven Autopilot (Entra join) configured and it mostly worked — until a quarterly hardware refresh pushed volume up and the first-boot success rate cratered to ~78%. Store managers started opening tickets that all said the same thing: “my new laptop isn’t set up” — the machine had landed on a desktop, but unmanaged: no compliance stamp, no VPN, half the apps missing, and Conditional Access blocking it from the point-of-sale app it was supposed to run.

The on-call engineer’s first instinct was to blame the network, and store LTE was slow — but slowness alone did not explain devices reaching an unmanaged desktop. Two root causes surfaced under investigation. First, the team had marked their Win32 security agent as ESP-blocking, and that agent pulled its ~400 MB installer from an internet CDN. Over a saturated store LTE link the install routinely blew past the 60-minute ESP timeout, the ESP errored, and (because “allow users to use device if installation error occurs” was on) dropped the user to a desktop before the agent — and the policies gated behind it — had landed. Second, the dynamic Autopilot group used the broad [ZTDID] rule, and a slice of devices were beginning enrolment before the dynamic group had evaluated their membership — so those devices never received the deployment profile’s full policy set and fell through to a generic state. Two independent failures, both producing the same “unmanaged desktop” symptom.

The fix had two corresponding parts. Fix one — stop blocking on heavy apps. They moved the security agent off the ESP blocking list and delivered it as required but non-blocking, leaving only the lightweight items that genuinely must precede login as blocking: the agent’s certificate and config (a few KB), the root certificates, the Defender baseline, and the Wi-Fi profile. The ESP’s effective blocking time dropped from a flaky 60-minute wait to a reliable sub-15-minute one, and stopped tripping the timeout. Fix two — make group membership deterministic. They stamped a Group Tag (KV-FIELD) on every device at registration and switched the dynamic group to the Group-Tag-scoped [OrderID] rule, so membership no longer depended on hash-arrival order. They also set the ESP to “only show during device preparation” and verified the profile assignment with a forced sync.

# Stamp the Group Tag at import so membership is deterministic, not hash-order dependent
Connect-MgGraph -Scopes "DeviceManagementServiceConfig.ReadWrite.All"
Update-MgDeviceManagementWindowsAutopilotDeviceIdentityDeviceProperty `
  -WindowsAutopilotDeviceIdentityId $ztdId -GroupTag "KV-FIELD"
# Then the dynamic group rule keys on the tag:
#   (device.devicePhysicalIds -any (_ -eq "[OrderID]:KV-FIELD"))

After the rollout, first-boot success climbed from ~78% to 99.4%, the “my laptop isn’t set up” tickets effectively stopped, and crucially the time-to-productive-desktop fell from a flaky 50–60 minutes to a reliable ~15, because the user was no longer waiting on a CDN download to finish before they could log in. The lesson the team wrote on the wall: “The ESP should block on the few things that must exist before login — not on the biggest thing you want installed. And never let a dynamic group decide membership by luck.” The agent still installs on every device; it just installs after the user is already working, which is exactly where a 400 MB non-critical install belongs.

The incident as a timeline, because the order of moves is the lesson:

Advantages and disadvantages

Zero-touch provisioning trades imaging effort and on-prem dependency for cloud dependency and configuration discipline. Weigh it honestly:

The model is right for any organisation past a hand-touch scale, remote-first workforces, and anyone implementing Zero Trust who needs a reliable managed-device signal. It bites hardest on teams who block the ESP on heavy apps (the universal first mistake), who let dynamic groups decide membership by luck, who leave the user account type at Administrator, and who flip Conditional Access to enforce without report-only validation or break-glass exclusions. Every disadvantage is manageable — but only with the discipline this article is about.

Hands-on lab

Stand up a user-driven Autopilot profile, register a test device by hardware hash, watch it provision, and reset it — a VM works for learning the flow (it cannot self-deploy and differs on TPM/attestation, but user-driven Entra-join provisioning runs fine). You need Intune Administrator (or Global Admin) and a Windows 11 VM/device you can reset to OOBE.

Step 1 — Confirm the tenant switches are on. In the Entra admin center, verify automatic MDM enrolment scope is set, and in Intune confirm Windows enrolment is permitted.

Entra admin center → Devices → Mobility (MDM) → Microsoft Intune
   MDM user scope = All  (or a pilot group containing your test user)
Intune → Devices → Enrolment → Enrolment device platform restrictions
   Windows (MDM) → Allow

Step 2 — Collect and register the hardware hash. On the test device (elevated PowerShell):

Set-ExecutionPolicy -Scope Process RemoteSigned -Force
Install-Script -Name Get-WindowsAutopilotInfo -Force
Get-WindowsAutopilotInfo -OutputFile .\AutopilotHWID.csv -GroupTag "KV-LAB"

Import the CSV at Intune → Devices → Enrolment → Windows → Autopilot devices → Import. Expected: after a few minutes the device appears under Autopilot devices with Profile status: Not assigned (it will become Assigned once the group and profile catch up).

Step 3 — Create a dynamic device group keyed on the Group Tag.

Entra → Groups → New group → Security → Dynamic Device
Rule: (device.devicePhysicalIds -any (_ -eq "[OrderID]:KV-LAB"))

Expected: within a few minutes the imported device shows as a member.

Step 4 — Create the deployment profile and assign it to the group.

Intune → Devices → Enrolment → Windows → Deployment Profiles → Create profile → Windows PC
  Deployment mode: User-driven
  Join type:       Microsoft Entra joined
  OOBE: Hide EULA, Hide privacy, Hide change-account, User account type = Standard
  Device name template: KV-%RAND:6%
  Assignments: the KV-LAB dynamic group

Expected: back on the Autopilot devices list, your device’s Profile status turns to Assigned.

Step 5 — Configure a minimal ESP.

Intune → Devices → Enrolment → Windows → Enrolment Status Page → (default or new)
  Show progress: Yes
  Block device use until apps/profiles installed: Yes → Selected apps (none heavy)
  Timeout: 60 min
  Allow reset on error: Yes

Step 6 — Provision the device. Reset the VM to OOBE (or use a fresh device). Pick Wi-Fi, enter the test user’s corporate email, approve MFA. Expected: corporate branding appears, the ESP runs its three phases, and the device lands on a managed desktop.

Step 7 — Validate the result. In Intune:

Intune → Devices → Windows → (your device)
  Management: Intune | Ownership: Corporate | Join type: Microsoft Entra joined
  Compliance: Compliant (once a compliance policy applies)
  Primary user: the test user

Expected: the device is Entra joined, Intune-managed, named per your template, and (after a compliance policy applies) marked Compliant.

Step 8 — Reset for the next user. Trigger an Autopilot reset from Intune (Devices → select device → Autopilot reset) or locally (Ctrl+Win+R at the lock screen). Expected: user data/apps are removed, the device stays enrolled, and it returns to a first-login state — ready to re-provision for the next user without re-registering the hash.

Validation checklist — what each step proved:

Teardown. Remove the test artefacts so they don’t linger: delete the deployment profile, the dynamic group, and (if the device is truly leaving) the Autopilot device record. Autopilot devices → select → Delete removes the hash registration; deleting the device from Intune/Entra alone does not.

Common mistakes & troubleshooting

Enrolment failures cluster around a handful of root causes, each with a real error string and an exact place to confirm it. Logs to know: the OOBE/ESP writes to %ProgramData%\Microsoft\Windows\AutoPilot and the event log under Applications and Services Logs → Microsoft → Windows → ModernDeployment-Diagnostics-Provider and → DeviceManagement-Enterprise-Diagnostics-Provider; Shift+F10 during OOBE opens a command prompt; and mdmdiagnosticstool.exe -area Autopilot -cab C:\diag.cab (or the Intune Collect diagnostics device action) packages everything. The playbook:

Two of these dominate real incidents and deserve a closer word:

5 & 6 — ESP timeout → unmanaged desktop (the number-one production failure). A required blocking app (often a large security agent pulled from a CDN) takes longer than the ESP timeout; the ESP errors, and if “allow users to use device if installation error occurs” is on, the user lands on a desktop before the gated policies applied. Confirm via the ModernDeployment-Diagnostics event log (the app shows pending) and the ESP timeout value. Fix by moving heavy apps to required, non-blocking and blocking only on the lightweight must-haves (cert, baseline, Wi-Fi) — not by simply raising the timeout, which masks the smell.

2/3/4 — the license-and-permission trio. 0x80180014, 0x80180018 and 801c03ea almost always trace to: the user has no Intune license, the MDM user scope excludes them, Windows enrolment is restricted, or device-join is disallowed / the per-user device quota is hit. These are configuration problems, not device problems — confirm each in Entra/Intune and fix the specific gate.

Best practices

• Buy OEM-registered where you can. Devices registered by Dell/Lenovo/HP/CSP at purchase land in your tenant with zero collection effort — the cleanest classic-flow path at scale.
• Stamp a Group Tag at registration and key dynamic groups on it. Deterministic membership ([OrderID]:<tag>) is the single biggest defence against the group-timing race that silently drops devices to an unmanaged state.
• Block the ESP only on the small set that must precede login. Cert, baseline, root certs, Wi-Fi — yes. The 400 MB agent installer — no; deliver it required-but-non-blocking so it lands after the user is already working.
• Set user account type to Standard. Administrator makes every enrolling user a local admin; grant elevation surgically with Endpoint Privilege Management instead.
• Prefer Entra join; treat Hybrid as a bridge. Cloud-only removes DC line-of-sight, the Intune Connector, and a timing dependency. Migrate off Hybrid over time.
• Evaluate Autopilot device preparation for net-new Entra-join provisioning. No hash, no dynamic-group race, a 90-minute SLA — the friction-free path for new builds.
• Validate Conditional Access in report-only first, and always exclude break-glass. A device-compliance CA policy with no emergency-access exclusion can lock you out of your own tenant.
• Graduate compliance noncompliance actions. A grace period before “noncompliant” avoids transient lockouts; escalate (email → notify → lock) rather than hard-failing on a blip.
• Get Win32 detection rules right. Detect the specific installed version (registry DisplayVersion, file version, or a script that exits 0 and echoes) — wrong rules cause reinstall loops or false “failed.”
• Use rings for everything you assign. Pilot → broad, with assignment filters, so a bad profile/app/baseline hits a ring of test devices before the fleet — see the assignment-filters article.
• Delete the Autopilot record when a device truly leaves. Removing it from Intune/Entra doesn’t release the hardware-hash claim; delete the Autopilot device record too.
• Collect diagnostics early. mdmdiagnosticstool.exe -area Autopilot -cab (or the Intune Collect diagnostics action) packages OOBE/ESP logs — gather them before you reset and lose the evidence.

Security notes

• Standard users by default, surgical elevation. Never ship local admin to every user via the profile. Use Standard and Implementing Intune Endpoint Privilege Management: Elevation Rules, Approval Flows, and Audit for just-in-time elevation with audit.
• Rotate the local admin password with Windows LAPS to Entra. Back the local administrator password up to Entra ID, rotate every 30 days, enforce complexity and length — so a stolen/shared local admin password isn’t a fleet-wide skeleton key.
• Make compliance the gate, and require it in Conditional Access. Configuration sets posture; compliance proves it. Require a compliant device for corporate access so an unmanaged machine — even with valid credentials — is turned away.
• Protect the break-glass accounts. Exclude emergency-access accounts from device-based CA, store their credentials offline, and monitor their use; they are the recovery path if a policy locks everyone out.
• Encrypt and attest by default. Require BitLocker, Secure Boot and TPM in compliance; these are the hardware-rooted properties that make the device trustworthy, not just configured.
• Lock down enrolment. Restrict who can enrol (enrolment restrictions, MDM user scope), and cap personal-device enrolment so only intended corporate Windows devices join under management.
• Pair the managed device with phishing-resistant auth. A compliant device plus FIDO2/passkeys/Windows Hello for Business is the endpoint half of Zero Trust — Rolling Out FIDO2 Passwordless Authentication in Entra ID.
• Wipe before reassigning, delete the record before disposal. Autopilot reset for in-org reassignment; retire/wipe and delete the Autopilot record before a device is sold or scrapped, so corporate data and the tenant claim both leave with it.

Cost & sizing

The economics of Autopilot are mostly licensing plus the cost of getting it wrong, not infrastructure — there is no fleet of build servers to run.

• Licensing dominates. You need an Intune license per enrolled user — bundled in Microsoft 365 E3/E5 or EMS E3/E5, or standalone Intune Plan 1. Autopilot adds nothing; a 1,000-seat org on M365 E3 is already paying for Intune, so turning on Autopilot is free capability on a license you hold.
• Hybrid carries hidden infrastructure cost. Entra join needs nothing on-prem; Hybrid needs an Intune Connector server, Entra Connect, and the toil of keeping both healthy — a recurring money-and-hours cost cloud-only avoids.
• The real cost is provisioning failure. At 400 devices/month, a 22% first-boot failure rate is ~88 devices a month in the support queue — each a ticket plus a re-provision plus a frustrated user, far more than the design time to get the ESP and groups right.
• Bandwidth, not build hardware, is the variable. Heavy ESP-blocking apps over slow links waste time and trip timeouts. Delivery Optimization (peer caching), same-region content and a Microsoft Connected Cache cut the pull cost; keeping the blocking set tiny is the cheapest optimisation of all.

The honest floor is the M365/EMS license you already hold plus the engineering time to design profiles, ESP, groups and CA correctly. The expensive mistakes are running Hybrid you don’t need, and shipping a fragile ESP that turns provisioning into a ticket factory.

Interview & exam questions

1. What does Windows Autopilot actually do — does it image the device? No. Autopilot redirects the out-of-box experience so the OEM-installed Windows recognises the device as corporate (by its hardware hash), pulls a deployment profile, runs the ESP, and joins Entra + Intune. The “image” is OEM-clean Windows plus policies applied live — there is no WIM, sysprep or golden image to maintain.

2. How does Autopilot identify a device, and what are the registration methods? By its hardware hash (4K HH) — a ~4 KB blob from TPM/firmware/hardware. Register it via OEM/CSP at purchase (best at scale), Get-WindowsAutopilotInfo (online upload or CSV), or Microsoft Graph. The newer device preparation flow removes the hash requirement entirely.

3. Entra join vs Hybrid Entra join — which do you choose for a new deployment and why? Entra join (cloud-only): no DC line of sight, no on-prem infrastructure, provisions from any internet connection, Microsoft-recommended for all new builds. Hybrid joins on-prem AD and Entra, needs DC reach at OOBE, the Intune Connector and Entra Connect — it is a legacy bridge for deep on-prem dependencies, not a destination.

4. What is the Enrolment Status Page and what is the most common mistake with it? The ESP is the gate between OOBE and the desktop; it can block the desktop until required items install, across three phases (device preparation, device setup, account setup). The classic mistake is blocking on heavy, network-bound apps (e.g. a large agent over a CDN), which blows the timeout and drops the user to a half-built desktop. Block only the small must-have set; deliver the rest required-but-non-blocking.

5. Explain the dynamic-group timing race and how to avoid it. Profiles reach devices via membership in a dynamic group, but dynamic membership evaluates asynchronously — a device can begin enrolling before it lands in the group and miss the profile. Avoid it by stamping a Group Tag at registration and keying the dynamic rule on [OrderID]:<tag> (deterministic), or by using Autopilot device preparation, which removes the dynamic-group dependency.

6. Difference between a configuration profile and a compliance policy? A configuration profile sets device state (LAPS, baseline, BitLocker config, Wi-Fi). A compliance policy reports whether the device meets your bar and stamps it compliant/noncompliant in Entra — the signal Conditional Access reads. Configuration makes the device good; compliance proves it is good to the access-control plane. You need both.

7. How do you make device compliance enforce access, and what must you never forget? In Conditional Access, add the grant Require device to be marked as compliant on the target apps. Never forget to exclude break-glass accounts and to validate in report-only mode first — a device-compliance policy with no emergency exclusion can lock you out of the tenant.

8. What is the new Autopilot device preparation and how does it differ from classic Autopilot? A redesigned Entra-join provisioning flow that removes hardware-hash registration, replaces the dynamic-group race with a device group + user scope set directly in policy, targets a ~90-minute SLA, and is Entra-join only. It is the cleaner path for net-new provisioning; classic still fits OEM-registered fleets and Hybrid.

9. A freshly provisioned device reaches the desktop but is unmanaged. What happened? Most likely the ESP errored (a blocking app timed out) with “allow users to use device if installation error occurs” on, so the user landed before policies applied — or the device hit the dynamic-group race and never got the full profile. Confirm via the ModernDeployment event log and the device’s profile/compliance state; fix the blocking list or the group determinism.

10. What is Autopilot reset and when do you use it vs wipe/retire? Autopilot reset removes user data/apps and personalisation but keeps enrolment and Entra join, returning the device to first-login for the next user — ideal for in-org reassignment, no re-registration needed. Wipe is fuller (optionally keeps enrolment); Retire removes management (BYOD offboarding); delete the Autopilot record when the hardware truly leaves the estate.

These map to MD-102 (Endpoint Administrator) — deploy Windows client, manage identity and compliance, manage applications — most directly, with the identity/Conditional Access angle touching SC-300 (Identity and Access Administrator) and the broader M365 administration overlapping MS-102.

Quick check

1. Autopilot doesn’t image the device — so what does it actually do, and what is the “image”?
2. A device is registered but its Profile status is “Not assigned” and it runs consumer OOBE. Name the two most likely reasons and the deterministic fix.
3. Your ESP keeps timing out and dropping users to an unmanaged desktop. What is almost certainly on the blocking list, and what’s the fix (and the wrong fix)?
4. You’re building net-new Entra-join provisioning and want to skip hardware-hash collection and the group race entirely. What do you use?
5. Before you flip a “require compliant device” Conditional Access policy to enforce, what two things must you do?

Answers

1. Autopilot redirects OOBE so the OEM-installed Windows recognises the device as corporate (by hardware hash), pulls a deployment profile, runs the ESP, and joins Entra + Intune. The “image” is just OEM-clean Windows plus your assigned policies/apps applied live — no WIM or golden image.
2. Either the dynamic group hasn’t evaluated the device’s membership yet (so the profile isn’t assigned), or the profile isn’t assigned to that group at all. The deterministic fix: stamp a Group Tag at registration and key the dynamic rule on [OrderID]:<tag>, so membership doesn’t depend on hash-arrival order — then confirm Profile status flips to Assigned.
3. A heavy, network-bound app (e.g. a large security agent pulled from a CDN) is marked required and ESP-blocking, exceeding the timeout. Fix: move it to required-but-non-blocking and block only the small must-haves (cert, baseline, Wi-Fi). Wrong fix: just raising the ESP timeout — that masks the smell and leaves a fragile, slow first-boot.
4. Windows Autopilot device preparation — no hardware-hash registration, device group + user scope set in policy (no dynamic-group race), ~90-minute SLA, Entra-join only.
5. Validate in report-only mode first (watch sign-in logs for unexpected blocks), and exclude your break-glass/emergency-access accounts — otherwise a misconfiguration can lock you out of the tenant.

Glossary

• Windows Autopilot — a service that redirects the OOBE of an OEM-installed Windows so the device provisions itself into Entra + Intune, with no imaging.
• Hardware hash (4K HH / hardware ID) — a ~4 KB blob derived from TPM/firmware/hardware that identifies a device to Autopilot; uploading it is “registration.”
• Deployment profile — the Intune object that defines OOBE behaviour (mode, join type, hide/skip settings, name template) and is assigned to a group.
• Group Tag — a label stamped on an Autopilot device record, used to make dynamic-group membership deterministic (via the [OrderID] token).
• ZTDID — Zero-Touch Deployment ID, the per-device Autopilot identifier surfaced in devicePhysicalIDs and used in dynamic-group rules.
• Enrolment Status Page (ESP) — the screen between OOBE and the desktop that tracks device preparation, device setup and account setup, blocking the desktop until required items install.
• Microsoft Entra join — a cloud-only device join to Entra ID; the modern default, needing no on-prem AD or DC line of sight.
• Hybrid Entra join — a device joined to both on-prem AD and Entra ID; a legacy bridge needing DC reach at OOBE, the Intune Connector and Entra Connect.
• Autopilot device preparation — the newer Entra-join provisioning flow that removes hardware-hash registration and the dynamic-group race, targets a ~90-minute SLA, and is Entra-join only.
• Configuration profile — Intune policy that sets device state (Settings Catalog, security baseline, LAPS, Wi-Fi, certificates).
• Compliance policy — Intune policy that reports device posture and stamps the device compliant/noncompliant in Entra; the Conditional Access signal.
• Conditional Access — the Entra access-control engine that can require a compliant/managed device before granting access to corporate resources.
• .intunewin — the packaged Win32 app format produced by the Microsoft Win32 Content Prep Tool for upload to Intune.
• Detection rule — how Intune determines a Win32 app is installed (MSI code, file version, registry, or custom script).
• Windows LAPS — Local Administrator Password Solution; rotates the local admin password and backs it up to Entra ID.
• Autopilot reset — a device action that removes user data/apps/personalisation while keeping enrolment and Entra join, returning the device to first-login for reassignment.
• Company Portal — the Intune app users use to install available apps and view device compliance.
• MDM user scope — the Entra setting that controls which users’ devices auto-enrol into Intune on Entra join.

Next steps

You can now take a sealed laptop to a compliant, gated, Zero-Trust endpoint with no IT touch. Build outward:

• Next: Windows Autopilot Device Preparation: Entra Join Provisioning and Migrating Off Legacy Autopilot — go deep on the new flow and migrating an existing classic/Hybrid estate.
• Related: Building Intune Configuration Profiles with the Settings Catalog and ADMX Ingestion — author the state you push during provisioning.
• Related: Packaging and Deploying Win32 Apps in Intune: .intunewin, Detection Rules, Dependencies, and Supersedence — detection rules, dependencies and supersedence done right.
• Related: Mastering Intune Assignment Filters and Ring Deployment: Targeting Logic, Precedence, and Safe Rollouts — safe, ringed rollout of every profile and app.
• Related: Gating Microsoft 365 with Endpoint Conditional Access: Compliance Policies, Device Filters, and Require-Compliant Enforcement — the Zero-Trust gate the compliant-device stamp feeds.
• Related: Managing Windows Updates with Intune: Update Rings, Feature Update Profiles, and Driver Update Control — keep the provisioned fleet current and drift-corrected.