Microsoft 365 Device Management

Zero-Touch Windows Provisioning with Intune and Windows Autopilot

Windows Autopilot turns a brand-new laptop into a fully managed, compliant corporate device with zero IT touch — the user unboxes it, signs in with their work account, and Intune does the rest. This guide wires up the full pipeline.

Prerequisites

Step 1 — Register devices (hardware hash)

Autopilot identifies devices by their hardware hash. OEMs (Dell, Lenovo, HP) can register at purchase; for existing devices, collect it yourself:

# On the device (elevated PowerShell)
Install-Script -Name Get-WindowsAutopilotInfo -Force
Get-WindowsAutopilotInfo -Online   # uploads directly to your tenant (interactive sign-in)
# or export to CSV for bulk import:
Get-WindowsAutopilotInfo -OutputFile .\AutopilotHWID.csv

Import the CSV: Intune → Devices → Enrollment → Windows → Devices → Import. Registered devices appear under Windows Autopilot devices.

Step 2 — Create a deployment profile

Intune → Devices → Enrollment → Windows → Deployment Profiles → Create:

Assign the profile to a dynamic device group so any registered Autopilot device picks it up:

Group type: Security, Membership: Dynamic Device
Rule: (device.devicePhysicalIDs -any (_ -contains "[ZTDID]"))

Step 3 — Enrollment Status Page (ESP)

The ESP is what makes Autopilot feel “managed from first boot.” Devices → Enrollment → Windows → Enrollment Status Page:

Step 4 — Configuration & compliance

Configuration profiles set state; compliance policies report state and feed Conditional Access.

A baseline compliance policy (Devices → Compliance → Create → Windows 10/11):

A configuration profile via the Settings Catalog (the modern way) to, say, disable local admin password reuse and deploy LAPS:

Devices → Configuration → Create → Windows → Settings catalog
  + Local Admin Password Solution (LAPS): Backup directory = Entra ID,
    Password age = 30 days, Complexity = large letters+digits+specials

Step 5 — Deploy apps

IntuneWinAppUtil.exe -c .\source -s setup.exe -o .\output
# then Intune → Apps → Windows → Add → Win32 app → upload .intunewin
#   install:   "setup.exe /quiet"
#   uninstall: "setup.exe /uninstall /quiet"
#   detection: registry/MSI product code/file version

Step 6 — Tie it to Zero Trust

The payoff: make corporate app access require a compliant device. In Conditional Access, add a grant control Require device to be marked as compliant (see the companion Zero Trust guide). Now only Intune-managed, compliant, BitLocker-encrypted devices can reach email and line-of-business apps.

Verify the end-to-end flow

  1. Wipe the test device → it boots to OOBE.
  2. Enter the corporate email → Autopilot branding appears → user authenticates (MFA).
  3. ESP runs: device prep → account setup → required apps install.
  4. Desktop unlocks fully managed. Confirm in Intune → Devices → Windows: compliant, Entra joined, profile assigned.
  5. Test a Conditional Access app from the device (allowed) vs. an unmanaged device (blocked).

Enterprise scenario

A retail org shipping ~400 Dell laptops/month to field stores hit a wall: the ESP kept timing out and dropping users to an unmanaged desktop. Root cause was twofold. First, their Win32 security agent was set as ESP-blocking but pulled its installer from an internet CDN — over a saturated store LTE link it routinely blew past the 60-minute timeout. Second, the dynamic Autopilot group used devicePhysicalIDs with a brittle rule, so a slice of devices enrolled before group membership evaluated and never got the profile.

Fix one: stop blocking on heavy apps. We moved the agent off the ESP blocking list and delivered it as required but non-blocking, gating only the lightweight cert + Defender config that genuinely must precede first login. ESP timeout dropped from 60 to 30 minutes and stopped tripping.

Fix two: harden the group rule and pre-create device records so membership is settled at enrollment:

# Dynamic device group rule (Autopilot-registered, all profiles)
(device.devicePhysicalIds -any (_ -eq "[OrderID]:KV-FIELD"))

# Stamp Group Tag at import so the rule is deterministic, not hash-order dependent
Set-AutopilotDevice -Id <ztdId> -groupTag "KV-FIELD"
Invoke-AzureADIntuneSync   # force Autopilot profile assignment refresh

We also flipped the ESP to “only show during first device prep” and enabled the Enrollment time grouping (Group Tags) so OOBE no longer waits on Entra dynamic-group churn. After rollout, first-boot success went from ~78% to 99.4%, and store staff stopped opening “my new laptop is unmanaged” tickets.

Checklist

Autopilot + Intune collapses imaging, domain-join, app packaging, and hardening into a single sign-in. Combined with compliance-gated Conditional Access, the device itself becomes a Zero Trust signal.

IntuneAutopilotDevice ManagementMDMComplianceEndpoint

Comments

Keep Reading