The minimal sequence is this: verify licences and enable automatic Intune enrollment, decide between Autopilot v1 and v2, register or prepare devices, create your device and user groups with deployment profiles, configure the Enrollment Status Page with at least one app and one policy per target, then run out-of-box experience (OOBE) and validate. Use v2 (Device Preparation) for new Windows 11 devices joining Microsoft Entra ID directly. Stick with classic Autopilot for hybrid join, pre-provisioning, or self-deploying kiosks. Your first move today: confirm subscription eligibility and switch on automatic Intune enrollment.
TL;DR:
- Use Autopilot v2 for deploying new Windows 11 devices with straightforward Entra ID join and faster app delivery, but avoid it if hybrid join or Windows 10 support are needed.
- Confirm tenant eligibility with Microsoft Entra ID P1 or P2 and assign individual licenses to pilot users before beginning device registration or enrollment.
- Ensure devices can reach key endpoints like ztd.dds.microsoft.com and login.live.com, and whitelist necessary URLs and ports to prevent provisioning hangs.
- Properly assign and verify deployment profiles in Intune, and make sure the Enrollment Status Page has the required device- and user-targeted policies before testing.
- Log and troubleshoot issues using diagnostic logs from the device and Event Viewer, focusing on common failure points like profile assignment, network access, and TPM attestation errors.
Windows Autopilot is Microsoft’s zero-touch provisioning system. It orchestrates three things at once during a new device’s first boot: joining Microsoft Entra ID, enrolling into Intune, and customizing the out-of-box experience so a user never sees a generic Windows setup screen. The device shows up branded, policy-compliant, and app-ready before the user finishes signing in.
There are now two generations of the technology, and picking the wrong one wastes a pilot cycle.
Classic Autopilot (v1) relies on a hardware hash collected from each device and registered in your tenant ahead of time. It supports the widest range of scenarios: hybrid Microsoft Entra join, pre-provisioning (white glove), self-deploying kiosk-style setups, and Windows 10 devices.
Autopilot Device Preparation, generally called v2, removes the hardware hash requirement entirely. Devices register dynamically at first boot and get assigned to a device group through what Microsoft calls Enrollment Time Grouping, which sidesteps the delay of waiting on a dynamic group query to catch up. That means faster app and policy delivery and near real-time reporting during OOBE.
The trade-off: v2 currently supports only Windows 11, and only Microsoft Entra join. It does not support hybrid join or white-glove pre-provisioning.
Here’s how to decide quickly:
Skipping this step is the single most common reason a pilot stalls in week one. Before you touch the Intune admin centre, confirm three things: licensing, operating system support, and network access.
1. Confirm your tenant has an eligible subscription. Windows Autopilot needs Microsoft Entra ID P1 or P2 paired with Microsoft Intune. Eligible bundles include Microsoft 365 Business Premium, Enterprise E3/E5, F1/F3, Academic A1/A3/A5, or EMS E3/E5. A tenant-level subscription is not enough. Every pilot user needs a licence assigned individually, or enrollment fails silently at the sign-in screen.
2. Check OS eligibility against your chosen deployment path. Device Preparation (v2) requires Windows 11. Classic Autopilot still supports Windows 10, so if you have older hardware in the mix, that decision is made for you.
3. Confirm network access to the required endpoints. Autopilot devices need outbound access during OOBE, before any user policy exists to configure a proxy. Miss this and provisioning hangs with no obvious error.
Statistic Callout: Autopilot’s network requirements include specific URLs for the deployment service, Windows Update, Delivery Optimization, and TPM attestation, plus UDP 123 for time synchronization. If firmware TPM certificates can’t reach their vendor’s attestation URL, device registration and BitLocker provisioning both fail quietly.
Key endpoints and ports to whitelist:
ztd.dds.microsoft.com (the Autopilot deployment service itself)login.live.com and Entra authentication endpoints*.microsoftaik.azure.net and related TPM attestation URLstime.windows.com over UDP port 123 for clock sync (certificate validation fails on clock drift)Configure proxy exceptions at the network proxy server itself, not through an Intune policy. Policies don’t reliably apply early enough in the boot sequence to catch OOBE traffic, which is a common cause of devices that appear to hang on the “Just a moment” screen indefinitely.
Finally, confirm your admin account has the Intune Service Administrator or equivalent role, and that automatic Intune enrollment is switched on for the user groups you’re piloting with. Review your Microsoft 365 licensing structure now if you’re not certain every pilot user has the right SKU attached.
Matching the deployment mode to the actual use case prevents a lot of wasted pilot cycles. Four scenarios cover almost every real-world deployment:
For pilot design, keep the group small and deliberately separated from production. Build a dedicated device security group of five to fifteen machines, not a slice of an existing dynamic group that might pick up unrelated devices. Decide upfront whether you’re using assigned or dynamic membership: assigned groups give you precise control for a pilot; dynamic groups (based on device attributes) scale better once you’re confident in production but introduce query latency that v2’s Enrollment Time Grouping specifically avoids.
Phase the rollout in three windows: a one-to-two week pilot with close monitoring, a departmental rollout to validate at scale, and a full production wave once escalation patterns from the pilot are resolved, following best practices from the Automatic Meta Descriptions: A Practical Rollout Guide. Build in a validation gate between each phase, not just a calendar date.
Pro Tip: Keep a rollback plan ready before the pilot starts, not after something breaks. Have a spare, unregistered device on hand so you can troubleshoot registration issues without pulling a machine out of the pilot mid-test.
This is the part where sequence matters more than anything else. Skip a step or do them out of order and the device will boot into a generic Windows setup screen instead of your branded OOBE flow.
Step 1: Enable automatic Intune enrollment. In the Intune admin centre, go to Devices > Enrollment > Automatic Enrollment and set the MDM user scope to “All” or a specific group that includes your pilot users. This is the single setting most commonly missed, and its absence is the most frequent root cause of a device that joins Microsoft Entra ID but never shows up in Intune.
Step 2: Confirm users can join devices to Microsoft Entra ID. Under Entra ID > Devices > Device settings, check that the relevant users or groups are permitted to join devices. If this is restricted to a subset of staff, your pilot users need to be in that subset.
Step 3: Assign licences to pilot users. Every pilot user needs an active Entra ID P1/P2 and Intune licence assigned directly to their account, not just tenant-level availability.
Step 4: Create your groups. You need at minimum:
Step 5: Register or prepare your devices. For v1, import hardware hashes. For v2, no pre-registration is required; devices register dynamically at first boot.
Step 6: Create the Autopilot deployment profile. Navigate to Devices > Windows > Enrollment > Windows Autopilot > Deployment Profiles and configure:
IT-%SERIAL%)Tenants can create up to 350 deployment profiles, which is more than enough headroom for most organizations to separate profiles by department, region, or device type.
Step 7: Set company branding and choose which OOBE pages to skip. Under Entra ID > Company branding, upload your logo and colours. In the Autopilot profile itself, decide whether to hide the Privacy Settings, End User Licence Agreement, and Change Account Options pages. Hiding all three gives the cleanest user experience for a straightforward corporate rollout.
Step 8: Assign the profile and confirm the “Assigned” status. Assign the deployment profile to your device group, then check back in the Intune admin centre for a status of “Assigned” against each device before you attempt deployment. Profile assignment isn’t instant. Give it time to propagate, particularly for v1 devices registered via hardware hash, where sync intervals can run into hours rather than minutes.
Set up your conditional access policies for the pilot group before go-live, especially if MFA is enforced tenant-wide. An unexpected MFA challenge mid-OOBE, before the user has any context for it, is a common source of pilot confusion that has nothing to do with Autopilot itself.
Device registration is where classic Autopilot and Device Preparation diverge most sharply in day-to-day mechanics.
For v1, you need a hardware hash for every device, an alphanumeric string tied to that specific machine’s hardware. Collect it three ways: a PowerShell script run on each device before it ships (the Get-WindowsAutoPilotInfo script is the standard tool here), an OEM-provided CSV export at time of purchase, or a reseller who registers devices on your behalf as part of the order.
CSV import has predictable failure points:
If you’re working with an OEM or reseller, confirm the registration timeline (some take a few business days after purchase), verify serial numbers match your purchase order, and confirm the ownership flag is set to your tenant rather than left with the reseller.
v2 changes this entirely. There’s no hardware hash and no pre-registration step. The device registers itself dynamically the moment it reaches OOBE and checks in with the Autopilot deployment service, then gets slotted into an assigned device group through Enrollment Time Grouping. The trade-off is that some organizations still want a staging step, confirming a device is destined for the tenant before it ships, which some manage through purchase-order tracking rather than technical pre-registration.
One cleanup detail matters if you’re testing both generations side by side: a device with an existing v1 Autopilot registration can conflict with a v2 pilot. If you need to move a device from classic Autopilot to Device Preparation, deregister it from the Autopilot devices list, remove any stale Intune or Entra device object, and reset the device to a clean OOBE state before retrying.
The Enrollment Status Page is where most first-pilot failures actually surface, even when the root cause traces back to something you set up two steps earlier.
ESP runs in two distinct phases, and each one only executes assignments targeted a specific way:
This is the part that trips up nearly every first pilot: you need at least one device-targeted policy and app, plus at least one user-targeted policy and app, before you run a real test. Without both, the ESP phases can skip silently, and the device reaches the desktop half-configured with no error message telling you why.
Keep the app set small for a pilot. A single line-of-business app or a lightweight configuration policy is enough to prove the pipeline works. Save the full application catalogue for production rollout once you’ve confirmed the mechanics function correctly.
App and script limits differ slightly between v1 and v2, and system-context installs (which don’t require a signed-in user) generally complete faster during the device ESP phase than user-context installs do during the user phase. Where you have a choice, favour system-context deployment for anything that must complete before the desktop appears.
To monitor progress, check the Enrollment Status Page blade in the Intune admin centre, which shows real-time phase completion per device. Toggle “Show error when time limit is reached” only after your pilot succeeds cleanly at least once; leaving it off during the first attempts gives you time to inspect a stuck device before it fails outright.
An unassigned target on either the device or user side is the most consistent cause of an ESP phase that never triggers, according to community guidance widely echoed across Microsoft’s own Autopilot documentation, which structures the standard workflow around exactly this two-phase assignment model.
A pilot that “worked once” isn’t the same as a validated deployment. Run through this sequence deliberately and log the results at each step.
mdmdiagnosticstool.exe on the device) and the Autopilot event logs in Event Viewer are the first thing to pull for any support escalation.If any step fails, don’t patch it and re-run blindly. Note exactly which phase failed, roll the device back to OOBE with systemreset, and retry once you’ve confirmed the fix.
Most Autopilot failures fall into four recognizable patterns. Knowing which one you’re looking at cuts triage time dramatically.
Device not receiving its profile. Check the device’s assignment status in the Intune admin centre first: is the “Date assigned” field populated, or still blank? If it’s blank, confirm the device is actually a member of the group the profile is assigned to, especially for dynamic group queries, which can lag behind manual additions by a noticeable margin.
ESP stuck at a percentage that never moves. This almost always traces back to a missing assignment. Confirm you have at least one device-targeted and one user-targeted app or policy live. If assignments look correct, check network connectivity to the required endpoints from that specific device, and check proxy rules aren’t silently blocking traffic that a policy-based configuration hasn’t reached yet.
Hardware hash import fails. Re-check the CSV structure against Microsoft’s expected column format, look for duplicate serial numbers from a prior import attempt, and confirm the account running the import has write permissions to the Autopilot devices list. Vendor-supplied hash files occasionally ship with encoding issues that Excel introduces when the file is opened and resaved; import the original file directly instead.
TPM attestation or certificate errors. Confirm the device can reach its TPM vendor’s attestation URL from the network it’s provisioning on. Firmware TPM devices need a valid certificate available at boot; if that certificate can’t be issued because the attestation endpoint is blocked, both device registration and BitLocker encryption will fail with errors that look unrelated on the surface.
Pro Tip: Before escalating any Autopilot ticket, pull the device’s MDM diagnostic report and the Event Viewer logs under Applications and Services Logs > Microsoft > Windows > ModernDeployment-Diagnostics-Provider. Nine times out of ten, the actual error is sitting there already, well before you need to open a support case.
This guide was written by Geeshan, drawing on the operational patterns that show up repeatedly across enterprise and SMB Autopilot rollouts: the same handful of misconfigurations, the same ESP assignment gaps, the same v1-to-v2 migration snags.
NetFusion Designs Inc is a SOC 2 Type II–certified Managed IT Services and AI Enablement provider working with small and mid-sized businesses across Ontario and Canada. Autopilot deployment sits squarely inside that scope: planning device groups and profiles, running the pilot, writing the runbook your internal team inherits afterward, and handling the escalations that come up in week one of production rollout.
For teams that want deployment support without hiring for it, NetFusion Designs runs managed Autopilot pilots, Microsoft 365 onboarding, and structured 30/60/90-day handovers, so the knowledge stays in-house even when the initial heavy lifting doesn’t.
Most Autopilot guidance treats the deployment as a checklist problem: enable this setting, create that profile, done. What the documentation underplays is how much of a real deployment’s success rides on decisions made before anyone opens the Intune admin centre.
The v1 versus v2 choice gets treated as a footnote in a lot of guides, when it’s actually the decision that determines your entire troubleshooting surface for the next two years. Teams that default to v1 out of habit, when their whole fleet is new Windows 11 hardware joining Entra ID directly, are carrying hardware hash registration overhead for no reason. Teams that jump straight to v2 without checking their hybrid join requirements find out the hard way, mid-pilot, that it doesn’t support their scenario.
The other underestimated piece is the ESP two-phase assignment rule. It’s not exotic advice. It’s in Microsoft’s own workflow documentation. But it’s the single most common reason a pilot “doesn’t work” on the first attempt, and most troubleshooting time gets spent looking everywhere except the assignment list.
Prioritize the decision framework over the button-clicking. The clicks are the easy part.
— Geeshan
Running an Autopilot pilot correctly the first time means someone on your team has already made the v1-versus-v2 call, built the ESP assignments right, and knows what a stuck device’s logs actually mean. NetFusion Designs Inc gives you that experience without adding a permanent headcount. As a provider with certified compliance and continuous operations, the team can handle Autopilot planning, pilot execution, and provide a documented runbook for your internal staff to inherit once rollout is stable, all billed as one consolidated engagement instead of managing multiple vendors.
If your team would rather hand the pilot to specialists who’ve already worked through the registration and ESP failure modes covered above, our Managed IT Services team can scope your Autopilot rollout alongside your existing Microsoft 365 environment. Reach out to start a conversation about your device count, your current v1 or v2 readiness, and a realistic pilot timeline.
Bookmark these before you start; you’ll be referencing them constantly during setup.
The core sequence is enabling automatic Intune enrollment, confirming users can join Microsoft Entra ID, registering or preparing devices, creating device and user groups, configuring the Enrollment Status Page, and creating and assigning a deployment profile. Each step depends on the one before it, so skipping ahead to profile creation before enrollment is confirmed is a common source of failed pilots.
OOBE stands for out-of-box experience, the setup screens a Windows device shows on first boot. In an Autopilot deployment, OOBE is customized to skip generic Windows setup screens and instead present your branding, sign the user directly into Microsoft Entra ID, and trigger the Enrollment Status Page phases.
Pre-provisioning splits deployment into two phases: IT staff or a reseller run the device-targeted portion of ESP first, installing drivers and base apps before the device ships. The end user then completes only a lightweight user ESP phase, which speeds up the experience for the person actually unboxing the machine.
For classic Autopilot (v1), the device needs its hardware hash imported into your tenant beforehand, then it boots to OOBE, checks in with the Autopilot deployment service, and picks up its assigned profile automatically. For Device Preparation (v2), there’s no pre-registration step: the device registers dynamically the moment it reaches OOBE and connects to the network.
Choose v2 (Device Preparation) for new Windows 11 devices joining Microsoft Entra ID directly, since it removes hardware hash registration and delivers apps faster through Enrollment Time Grouping. Choose v1 if you need hybrid join, pre-provisioning, self-deploying kiosks, or you’re still supporting Windows 10 devices.
%20(1).avif){kind=logo}
%201.avif)
