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 
Thanks for bloggin!
If I’m understanding this correctly, when using Autopilot v1 it’s best practice to keep a default ‘all devices’ ESP as a minimal blocking fallback. That way the mandatory baseline (Defender, BitLocker, canary app) always applies, even if dynamic group membership is delayed. Any additional ESP profiles or app assignments are effectively a bonus, they usually apply, but if they don’t, the fallback ESP ensures the device still completes enrollment safely and consistently. A proper design suggestion, it makes all sense!
LikeLike
Your understanding is solid and the pattern is well-reasoned, Robert. Let me validate each part of it against what the sources confirm.
Your design pattern is architecturally correct. The default ESP as a minimal blocking fallback is a legitimate and defensive design choice for Autopilot v1 — particularly in MSP environments where dynamic group membership delay is a documented real-world risk.
What the sources confirm
On the default ESP being the catch-all fallback:
Every Intune tenant has one default ESP profile that cannot be deleted. It applies to all Autopilot devices that do not match a custom ESP profile.
This directly validates your fallback logic — if a device misses its group tag or dynamic group membership hasn’t resolved in time, the default ESP is what fires.
On the dynamic group delay risk:
What happens if you enroll a device into Autopilot, but either do not tag it, make a typo in the tag, or simply don’t give the tag long enough to detect and apply the corresponding profile? Well, it’s not going to fall into a group tag group, so it’s not going to get assigned to all those things the group tag group should give (apps, policies, deployment profiles, etc).
That’s exactly the gap your fallback ESP is designed to cover.
On blocking being the critical control:
Block device use until all apps and profiles are installed — this is the most important security control in the ESP. Without this, all other settings are advisory only.
One important caveat — the default ESP does not block out of the box
This is the part most people get wrong:
Out of the box, the default profile shows the ESP screen but does not block device use. For most managed environments this is not sufficient, so you create one or more custom profiles targeted at your Autopilot device groups.
So your pattern only works as described if you’ve explicitly enabled blocking on the default ESP and configured the minimal app list (canary app, and ensured Defender/BitLocker configuration profiles are tracked). If the default is left at factory settings, it shows progress but lets the user straight through — your fallback has no teeth.
The “keep it minimal” part is exactly right
Too many required apps in the ESP is a common failure cause. Every app marked as “required” and assigned to the device or user must install before the ESP completes. If you have 20 required apps, each averaging 3 minutes to install, you are already at the timeout limit. Reduce the number of ESP-tracked apps to essentials only (security tools, VPN client, core LOB apps). Deploy everything else after the ESP completes.
Your canary app + security baseline approach is the right shape. Keep the blocking list short and fast.
Counter-perspective worth knowing
The “Azure to the Max” community (April 2026) argues for a different school of thought — essentially treating the default ESP as a known gap you should disable (make non-blocking or near-empty), and investing in operationally ensuring every device gets a group tag. Their reasoning: if a device falls through to the default, it’s in an ambiguous state, and it sets up Windows defaults — the user is a local admin, non-standard naming scheme — and the device is missing a ton of policies and apps, typically resulting in broken devices with names like LAPTOP-XXXXX.
Their argument is valid for environments with mature, reliable group tagging. Your approach is more defensive and better suited to MSP/SMB where human error (typos, timing) is more likely. For that audience, a minimal blocking fallback is the right call.
Summary
Your design pattern is sound. To make it bulletproof:
Element Recommendation
Default ESP Enable Show progress = Yes + Block device use = Yes + canary app in tracking list
Baseline apps in fallback Canary app only (Win32 silent install, minimal size); Defender/BitLocker as config profiles apply separately
Targeted ESP profiles Assign to specific device group tag groups; can carry more apps and role-specific settings
Timeout Raise to 90 min on the targeted profiles; 60 min is fine on the minimal fallback
Monitoring Watch Intune > Devices > Monitor > Enrollment failures for devices landing on the fallback ESP unexpectedly — that’s your signal that tagging is breaking down
Sources:
Set up the Enrollment Status Page — Microsoft Learn(opens in new window)
Autopilot ESP — Every Setting Explained (The Deployment Guy, May 2026)(opens in new window)
How and why you should disable the Default Autopilot ESP (Azure to the Max, April 2026)
LikeLike
Super! .. what a reply! . thanks again! ..
LikeLiked by 1 person