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.
- Pilot (IT / internal). Loose ESP — Block device use = No, timeout 90 minutes, log collection on. You want visibility, not gates.
- 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.
- 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.
CIAOPS 