Before Autopilot, provisioning a new Windows device meant imaging, a technician touching the machine, and a two-day turnaround. With a well-designed Autopilot program, a device ships directly to the end user, they sign in with their corporate credentials, and it configures itself. No IT involvement, no pre-imaging, no delays.
That sounds simple. Getting it right at scale is a different story. This post covers what actually goes into building a reliable zero-touch deployment program for a large enterprise endpoint estate.
How Autopilot Works
Autopilot is a collection of technologies that pre-configure the Windows Out-of-Box Experience (OOBE) and automate enrollment into Intune. The flow looks like this:
- Hardware vendor pre-registers device hardware hashes with your tenant
- Device ships to user
- User powers on and signs in with Azure AD credentials
- Azure AD identifies the device as Autopilot-registered
- Deployment profile applies - OOBE is customised or skipped entirely
- Enrollment Status Page (ESP) runs - apps and policies deploy before the user reaches the desktop
The result is a fully configured, policy-compliant device from first boot.
Deployment Profile Options
Autopilot supports three main deployment modes:
User-Driven (Azure AD Join) The standard mode for most enterprises. User authenticates during OOBE, device joins Azure AD and enrolls in Intune. Best for hybrid workforces where devices are assigned to individuals.
User-Driven (Hybrid Azure AD Join) Device joins both on-premises Active Directory and Azure AD. Required if you have legacy apps that depend on Kerberos or on-prem Group Policy. More complex - needs the Intune Connector for Active Directory installed on a domain-joined server.
Self-Deploying Mode No user authentication during OOBE. Used for shared devices, kiosks, and meeting room hardware. The device enrolls automatically on network connection using the TPM device certificate for authentication.
Enrollment Status Page Configuration
The ESP is the progress screen users see during first boot. Configuring it correctly is the difference between a smooth rollout and frustrated users calling the helpdesk.
Key ESP settings:
Block device use until required apps are installed: Yes
Show error when installation takes longer than: 60 minutes
Allow users to collect logs: Yes
Only put truly essential apps in the ESP block list. If you add everything, users spend 45 minutes staring at a progress bar before they can do anything. The pattern that works:
- ESP phase (blocking): Security baseline, VPN client, certificate profiles, core productivity apps (M365)
- Post-ESP (background): Line-of-business apps, optional software, printers
Users reach the desktop faster, and the background installs complete while they're reading their emails.
Dynamic Group Strategy
Autopilot profiles and ESP configurations assign via Azure AD groups. Use dynamic device groups based on the enrollmentProfileName attribute - this ensures a device gets the right profile the moment it enrolls:
(device.enrollmentProfileName -eq "Autopilot-Corp-Standard")
Layer your groups:
AG-Autopilot-Corp-Standard- standard office workersAG-Autopilot-Corp-Developer- developers (different software set, fewer restrictions)AG-Autopilot-Corp-Kiosk- shared/self-deploying devicesAG-Autopilot-Corp-Executive- named executives (priority support SLA)
The profile name is set in the deployment profile configuration and stamped on the device at enrollment - reliable and doesn't depend on HR data syncing correctly.
Pre-Provisioning (White Glove)
For situations where IT wants to front-load the heavy configuration before the device ships to the user, Autopilot pre-provisioning (formerly "White Glove") lets a technician run the device-phase of ESP before boxing it back up.
When the end user receives the device and signs in, only the user-phase apps and policies need to deploy - dramatically reducing the user's wait time. This is particularly useful for developers who have large tool installs (Visual Studio, Docker Desktop) that would otherwise take 30+ minutes during OOBE.
Operational Lessons at Scale
Running 10,000+ devices through Autopilot leaves you with a set of hard-won lessons. A few that cost real time:
Hash registration latency Hardware hashes submitted by the vendor can take 24–48 hours to show up in the tenant. Don't assume they'll be there when the device arrives. Build a 48-hour buffer into procurement timelines or you'll have devices hitting OOBE without a profile.
Name templates
Set device name templates in the deployment profile (CORP-%SERIAL%) from the start. Fixing naming across thousands of devices post-enrollment is not a fun afternoon.
ESP timeout failures If an app install times out during ESP, the device reports a failure and blocks the user from getting to the desktop. Monitor failure rates by app via the Intune device install status report. Keep timeout thresholds realistic — 60–90 minutes for developer profiles, 30–45 for standard.
Remediation scripts Deploy a PowerShell remediation script via Intune that checks and corrects common post-enrollment issues: incorrect time zone, stale certificates, proxy misconfigurations. Running it daily costs almost nothing and prevents a category of helpdesk tickets entirely.
Compliance and Patch Velocity
With Autopilot handling enrollment and baseline policy, the compliance picture improves dramatically. In our estate:
- 98% patch compliance within 30 days of patch release - achieved through update rings with staged deployment (10% → 25% → remaining)
- Zero-day vulnerability response - critical patches promoted through rings in 48 hours
- Compliance reports generated automatically via Intune Compliance Policies and surfaced in Microsoft Defender for Endpoint
The combination of Autopilot, compliance policies, and update rings means security posture is maintained at the infrastructure level. It doesn't depend on individual users doing the right thing — which is the only version of security that actually scales.