5 Device Pilot: Windows Autopilot Setup Runbook for Small IT Teams

5 Device Pilot: Windows Autopilot Setup Runbook for Small IT Teams

Windows Autopilot delivers zero-touch provisioning once three things are ready: your tenant licensing, automatic Intune enrollment, and device registration. Before unboxing a single laptop, confirm your subscriptions qualify, flip on automatic Intune enrollment in Microsoft Entra, and pick a device registration method, OEM auto-registration or a manual hardware hash. Get those three right and the rest of the setup falls into place.

---

TL;DR:

• Ensuring device registration at the point of sale through OEM auto-registration streamlines ongoing Autopilot deployment, reducing manual effort.
• Automatic Intune enrollment requires setting the user scope in Microsoft Entra and verifying licenses such as Entra ID P1 or P2 and Intune in the subscriptions.
• Using the correct deployment profile, whether user-driven, self-deploying, or pre-provisioned, aligns the device setup with the intended use case and simplifies standardization.
• Proper configuration of the Enrollment Status Page and choosing between device preparation and traditional Autopilot prevents setup stalls and ensures compliance policies deploy correctly.
• Small businesses benefit from managed support to coordinate OEM registration, build deployment profiles, and monitor the rollout, minimizing troubleshooting and saving time.

---

Table of Contents

• Prerequisites and requirements checklist
• How to enable automatic Intune enrollment and confirm licensing
• Registering devices and capturing the hardware hash
• Choosing and assigning the right deployment profile
• Configuring the Enrollment Status Page and why it matters
• Device preparation versus traditional Autopilot: picking one path
• A compact runbook for finishing setup in Intune
• Troubleshooting common Autopilot failures
• Why small businesses often bring in managed support for Autopilot
• Get hands-on help rolling out Autopilot
• Sources
• FAQ

Prerequisites and requirements checklist

Before touching a device, audit your tenant against the official baseline. Windows Autopilot requirements call for a supported Windows client build, network access to specific ports and URLs, and the right licensing and configuration groundwork in place first.

• Confirm devices run a supported Windows 11 release and are current on updates.
• Verify your subscription includes Intune and Microsoft Entra ID, since Microsoft 365 Business Premium bundles both for most small organizations.
• Open outbound access on ports 80, 443, and 123, and allow Delivery Optimization and Windows activation traffic to pass through your firewall.
• Create a custom Intune role scoped to Autopilot device preparation instead of handing out global admin rights.

The baseline is non-negotiable: Windows Autopilot requirements specify that supported Windows client versions and open access to required ports and URLs are mandatory, not optional, for provisioning to complete.

How to enable automatic Intune enrollment and confirm licensing

Automatic enrollment is the switch that connects a new device to your Intune tenant the moment it reaches the Microsoft Entra join screen. Set it up with these steps:

1. In the Microsoft Entra admin center, open Mobility (MDM) and Microsoft Intune settings and set the MDM user scope to All, or to Some if you want to pilot with specific groups first.
2. Add your pilot or production security groups to the enrollment scope so only intended devices and users are affected.
3. Check license assignment for every pilot user: Entra ID P1 or P2 and an Intune license, both typically included in Microsoft 365 Business Premium.
4. Note that self-deploying and pre-provisioned scenarios skip the usual first sign-in account requirements, since no user interacts with the device during provisioning.

Subscription activation lets a device step up from Windows Pro to Enterprise automatically once the signed-in user holds the correct license, which removes a manual OS upgrade step for your team.

Registering devices and capturing the hardware hash

Every device needs its hardware hash registered to your tenant before Autopilot recognizes it. Manually registering devices is one path, but it is not the preferred one for ongoing operations.

• OEM or reseller auto-registration is the better route for production purchases, since the hash gets uploaded at the point of sale with no technician involvement.
• Manual collection with the Get-WindowsAutopilotInfo.ps1 script works well for existing devices, repairs, or small batches: run it locally or remotely to generate an AutopilotHWID.csv file, then upload that file directly in Intune or through the Autopilot Diagnostics page.
• The CSV import accepts up to 500 rows per file, and a sync in Intune after upload confirms the devices appear in the Autopilot devices list.
• Remove retired or duplicate hardware hashes promptly, since orphaned Autopilot objects can cause a device to register against the wrong profile later.

Pro Tip: Reserve manual hash harvesting for exceptions. For new purchases, ask your reseller to register hashes at the time of sale so devices arrive ready to ship straight to the end user.

Choosing and assigning the right deployment profile

Picking the correct profile type shapes the entire out-of-box experience, so match it to how the device will actually be deployed.

1. Choose user-driven for devices going to name employees who will sign in with their own account during setup.
2. Choose self-deploying for kiosks, shared devices, or conference room hardware with no primary user sign-in required.
3. Choose pre-provisioned, also called white glove, when a technician needs to complete the heavy lifting before the device reaches the end user.
4. Set the join type to Microsoft Entra joined for most small business scenarios, set the default account type to Standard, and hide unnecessary OOBE screens like the privacy and end-user license pages to shorten setup time.
5. Assign the profile to a pilot device group first, confirm a clean run, then expand assignment in phases rather than pushing it to every device group at once.

Device naming conventions and branding, like a custom company logo on the sign-in screen, are worth setting here too, since they are far harder to standardize after devices are already in the field.

Configuring the Enrollment Status Page and why it matters

The Enrollment Status Page (ESP) is what turns a basic OS install into a fully provisioned, policy-compliant device before the user ever reaches the desktop. According to the ESP configuration tutorial, a custom ESP assigned to device groups can block sign-in until required apps and policies finish deploying.

• Device preparation mode runs an ESP phase during setup itself, while traditional Autopilot splits progress into device setup and account setup phases.
• Blocking sign-in until required security policies and apps install prevents employees from using an unprotected machine, which matters most for firms handling client data.
• Set a realistic timeout, long enough for your typical app set to finish, and enable the "show error when time limit is reached" option so technicians get useful diagnostics instead of a frozen screen.

Pro Tip: Turn on the "show app and profile configuration progress" setting during your pilot phase so you can see exactly which installs are slow before you roll out to the rest of the fleet.

Device preparation versus traditional Autopilot: picking one path

Device preparation and traditional Autopilot are related but separate systems, and running both against the same device group creates confusion. According to the device preparation FAQ, registered Autopilot device profiles take precedence over device preparation policies, so a device assigned to both will follow the traditional Autopilot path.

• Device preparation uses a lighter registration model and its own ESP phase, built for faster Entra-joined provisioning.
• Traditional Autopilot relies on pre-registered hardware hashes and deployment profiles assigned ahead of time.
• Pick one approach per deployment scenario, document it, and avoid assigning both policy types to the same device group to sidestep precedence conflicts.

A compact runbook for finishing setup in Intune

Once prerequisites are confirmed, the remaining work happens almost entirely inside the Intune admin center.

1. Create a device group and a user group for your pilot, keeping pilot membership small and easy to track.
2. Confirm automatic Intune enrollment is active for that group's scope, as configured earlier in Microsoft Entra.
3. Import your registered devices, whether via OEM registration, CSV upload, or the Diagnostics page, and sync to confirm they appear under Autopilot devices.
4. Assign your Autopilot deployment profile and your custom ESP to the pilot device group.
5. Assign at least one required app and one required policy to both the device and user groups, since Microsoft's own self-deploying tutorial notes this is necessary for ESP to run correctly during testing.
6. Set critical line-of-business apps to install in the System context if they must be present before the first user sign-in, otherwise ESP may show them as skipped.

Run your pilot on a small number of devices before expanding further. Watch the ESP progress screen for stalls, confirm every required app lands on the desktop, and check that conditional access and compliance policies, covered in more depth in our Intune device compliance guide, apply correctly once the user signs in.

Pro Tip: Keep your pilot group small on purpose. Five devices surface most configuration mistakes without tying up your whole team if something needs a rebuild.

Troubleshooting common Autopilot failures

Most Autopilot failures trace back to one of a handful of causes, and the device preparation troubleshooting FAQ documents the most frequent ones along with their fixes.

• If a device never appears in the Autopilot devices list, recheck the hardware hash upload or OEM registration record before assuming a sync delay.
• If ESP never launches, confirm the device group assignment on the device preparation policy matches the group the device actually belongs to.
• A frequent and specific cause of silent failures: the troubleshooting FAQ notes that the Intune Provisioning Client service principal, AppID f1346770-5b25-470b-88bd-d5744ab7952c, must own the device security group referenced in the policy, or the policy can fail to save or deploy correctly.
• Rule out network blocks on Delivery Optimization, attestation endpoints, and time synchronization services, since any of these can stall provisioning partway through.

Capture diagnostic logs from the device during a failed run before rebuilding it. Those logs, combined with the RBAC and group ownership checks above, resolve the large majority of SMB Autopilot support tickets.

Why small businesses often bring in managed support for Autopilot

Autopilot setup is not difficult in theory, but coordinating OEM registration, Intune profiles, RBAC, and a clean pilot takes focused time that small IT teams rarely have to spare between other tickets. Some managed IT providers approach this with proactive monitoring and plain-language support, so issues during rollout get caught and explained without technical jargon standing in the way.

Outsourcing tends to make the most sense for supplier coordination with OEMs, managing the pilot phase itself, and the ongoing monitoring that catches a misconfigured profile before it affects a whole device shipment.

— Nicholas

Get hands-on help rolling out Autopilot

Some managed IT providers handle the parts of Autopilot setup that consume the most time: coordinating device registration with suppliers, building out Intune deployment profiles and ESP policies, running the pilot, and then monitoring the fleet continuously once it is live. Local businesses can often get same-day response if something needs attention mid-rollout, sometimes without long-term contracts.

If you want a clear picture of where your tenant stands before you start, request a free network assessment or book the 10-minute readiness audit to confirm your licensing, enrollment settings, and network access are ready for a smooth deployment.

Sources

• Windows Autopilot requirements | Microsoft Learn

For a small-business-specific walkthrough of Intune alongside Autopilot, Secure Techie's guide to Microsoft Intune for small business covers practical rollout considerations that pair well with the steps above.

FAQ

What are the known issues with Windows Autopilot?

The most common issues involve devices not appearing after registration, the Enrollment Status Page failing to launch, or policies not applying correctly. Many of these trace back to RBAC and ownership problems, such as the Intune Provisioning Client service principal not owning the assigned device group, as documented in the device preparation troubleshooting FAQ.

What is Windows Autopilot and do I need it?

Windows Autopilot is Microsoft's zero-touch provisioning system that configures new or existing Windows devices automatically using Entra ID and Intune, skipping manual imaging. It is worth adopting if your business regularly deploys new laptops or desktops and wants consistent setup without a technician handling every machine individually.

Is Windows Autopilot free to use?

Autopilot itself has no separate fee, but it requires licenses that include Intune and Microsoft Entra ID, such as those bundled in Microsoft 365 Business Premium. Without those underlying licenses, automatic enrollment and provisioning will not function.

Is Windows Autopilot the same as Intune?

No, they are different but connected services. Autopilot handles the initial zero-touch provisioning experience, while Intune manages the device afterward, pushing policies, apps, and compliance settings through its ongoing device management features.

Recommended

• SMB Microsoft 365 Security: Crawl, Walk, Run Checklist in 30–90 Days
• Small IT Teams: Start MFA for Microsoft 365 with Security Defaults
• Conditional Access Policies: 4 Phase Zero Trust Playbook for SMBs
• Proactive IT Management Explained for SMBs and IT Leaders