Windows Autopilot Deployment: A Practical Checklist for IT Admins
Windows Autopilot is the fastest way to get a new PC from the shipping box to a fully configured, compliant corporate device — without IT ever touching it. I’ve used it to cut manual setup time by roughly 40% across a 1,000+ device fleet. This is the practical checklist I wish I’d had on day one.
What Autopilot actually does
Autopilot isn’t imaging. The device keeps its factory Windows install; Autopilot customizes the out-of-box experience (OOBE), joins the device to Microsoft Entra ID, enrolls it into Intune, and lets Intune deliver your policies, apps, and security baselines. The user unboxes the laptop, connects to Wi-Fi, signs in with their work account, and the device builds itself.
Pre-flight checklist
- Licensing: Intune plus Entra ID P1 (or the bundles that include them, like Business Premium or E3/E5).
- Automatic enrollment: In Intune, confirm MDM automatic enrollment is enabled for your users.
- Hardware hash registration: The cleanest path is having your hardware vendor or reseller register devices to your tenant at purchase. For existing devices, collect the hardware hash and import it into Intune.
- Group strategy: Create a dynamic Entra ID group that automatically captures Autopilot devices, keyed off the Autopilot group tag. Every profile and app assignment hangs off this group.
Build the deployment profile
In Intune, go to Devices > Enrollment > Windows Autopilot and create a deployment profile:
- User-driven mode is right for most corporate laptops — the end user signs in and the device is assigned to them.
- Self-deploying mode suits kiosks and shared devices with no primary user.
- Hide the privacy and EULA screens, set the user account type to Standard (not Administrator — this matters for security), and apply a device naming template so machines land in inventory with predictable names.
Configure the Enrollment Status Page
The Enrollment Status Page (ESP) holds the user at a progress screen until critical apps and policies are installed. Use it deliberately: block only on the apps a user genuinely needs in the first hour (VPN client, endpoint protection, browser), and let everything else install in the background. An overloaded ESP is the number one cause of slow, failure-prone Autopilot experiences.
What to deliver at enrollment
- Security first: BitLocker enforcement, compliance policy, and your security baseline should apply immediately.
- Core apps as Win32 packages: Package line-of-business apps in the Win32 format rather than legacy MSI where possible — it gives you dependency ordering, detection rules, and reliable retries.
- Update rings: Assign Windows Update rings at enrollment so patch governance starts on day one, not after the first maintenance window.
Test like a user, not like an admin
Before rolling out, run the full experience on real hardware: factory reset, unbox, OOBE, sign-in, ESP, first desktop. Time it. If the end-to-end experience takes more than 45–60 minutes on office Wi-Fi, trim the ESP list or optimize your app packages. Test remote scenarios too — home networks and VPN-dependent apps are where Autopilot deployments usually stumble.
Common pitfalls
- Hybrid join temptation: If you can, go cloud-native Entra join. Hybrid Entra join with Autopilot adds connectivity dependencies that create fragile enrollments.
- Missing hardware hashes: A device that isn’t registered simply gets a normal consumer OOBE. Automate registration with your vendor so nothing slips through.
- Skipping the reset test: Autopilot Reset and reuse flows deserve the same testing as first deployment — device lifecycle doesn’t end at first boot.
The payoff
Done well, Autopilot turns device deployment from a per-machine IT task into a supply-chain process: devices ship directly from the vendor to the employee, and IT manages the experience through profiles instead of hands-on builds. Combined with Apple’s Automated Device Enrollment on the Mac side, you get true zero-touch provisioning across the whole fleet.