What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Some links on this page are affiliate links: if you buy through them we may earn a commission, at no extra cost to you.
Windows Autopilot is Microsoft’s cloud-based way to provision organization-owned Windows PCs without maintaining a custom disk image. It keeps the OEM’s Windows installation, identifies the device through an Autopilot registration, and uses Windows out-of-box experience (OOBE), Microsoft Entra ID, Intune, applications, and policies to prepare the PC for work. It can enable direct-to-user shipping and easier reuse, but it is not a free, preparation-free replacement for endpoint management: licensing, tenant configuration, hardware registration, application packaging, networking, testing, and lifecycle cleanup still matter.
This guide covers classic Windows Autopilot. Microsoft now documents the related Windows Autopilot device preparation experience separately at its Autopilot documentation hub.
What Windows Autopilot does
Traditional deployment often means building and maintaining an image, injecting drivers, and physically touching each computer. Autopilot normally uses the Windows client image supplied by the OEM instead. During OOBE, the device contacts Microsoft, recognizes that its hardware identity belongs to your tenant, and receives the assigned deployment profile. Intune then applies applications, configuration, security, and compliance settings.
Microsoft describes Autopilot as a collection of technologies for setting up, preconfiguring, resetting, repurposing, and recovering Windows devices (overview). It can coexist with Configuration Manager, co-management, OEM staging, and other management tools; it does not replace every operating-system deployment workflow.
#1 Best Overall
Registration, enrollment, and join are different
- Registration: the device hardware hash is associated with your tenant in the Windows Autopilot service.
- Enrollment: the device is added to Intune (or another compatible mobile-device-management service).
- Join: the Windows installation establishes its identity relationship with Microsoft Entra ID.
Microsoft Entra ID supplies identity and device join. Intune supplies mobile-device management, applications, policies, compliance, and reporting. Microsoft 365 may provide eligible licensing, while OOBE is the user-facing setup experience. The Enrollment Status Page (ESP) can hold the desktop until selected configuration is complete.
Who should use Autopilot?
Autopilot is a strong fit for organization-owned PCs purchased from supported OEMs, resellers, or distributors; remote employees who can receive a laptop directly; standardized Intune environments; and organizations that regularly reset or reassign devices.
It is a weaker fit for one-off personal computers, BYOD that the organization does not own, OOBE locations without dependable internet, or legacy environments that require on-premises-only identity and applications without a hybrid-join or co-management plan. A device registered to the wrong tenant can display the wrong organization’s setup, so ownership and supplier processes are critical.
Prerequisites and architecture
- A supported Windows client edition and version. Verify current requirements in Microsoft’s Windows enrollment guide rather than assuming every edition is eligible.
- A Microsoft Entra tenant and an Intune subscription, or a Microsoft 365 plan that includes the required Intune entitlement. Check the exact user/device licensing, region, and plan at Intune’s getting-started documentation.
- Automatic MDM enrollment configured in Intune, appropriate administrator and user permissions, and security groups for profiles and policies.
- Reliable internet access during OOBE and access to required Microsoft service endpoints.
- Applications packaged for unattended installation, with correct dependencies and detection rules.
- Hardware registration through an OEM, reseller, distributor, partner, or a manually imported hardware hash.
- A decision between Microsoft Entra join and Microsoft Entra hybrid join. Hybrid join retains on-premises dependencies and requires infrastructure such as the Intune Connector for Active Directory; cloud-native Entra join is generally simpler when legacy requirements do not require a domain join.
Choose a deployment scenario
| Scenario | User signs in during OOBE? | Best use | Important constraints |
|---|---|---|---|
| User-driven | Yes | Assigned employee laptop | User credentials are required and the device is associated with that user. |
| Self-deploying | No | Kiosk, shared device, signage | No user association; device-targeted policies are central. TPM attestation and other hardware requirements apply. |
| Pre-provisioned | User completes final stage | OEM or IT staging before shipment | Enable pre-provisioning in the profile and configure ESP. |
| Existing-device | Usually after reinstallation | Rebuilding an existing managed PC | A more disruptive workflow that can reformat and reinstall Windows; it is not equivalent to shipping a new OEM device. |
Self-deploying and pre-provisioning rely on TPM key attestation for documented device-preparation steps, while the user-driven scenario does not require that TPM flow in Microsoft’s current guidance (ESP documentation). Choose based on ownership, whether a user is present, application needs, and identity dependencies rather than treating one mode as universally best.
Configure a beginner deployment
1. Design the pilot
Decide the join type, deployment mode, naming convention, local-account type, applications required before first use, ESP blocking policy, group structure, and reset, reassignment, and retirement procedures. Use a small pilot containing each important hardware model and deployment scenario.
2. Prepare Intune
- Confirm licensing, tenant access, and automatic enrollment.
- Create Microsoft Entra security groups for pilot devices, users, profiles, applications, and policies.
- Create configuration, endpoint-security, compliance, and application policies.
- Package Win32 applications for silent installation and verify dependencies and detection rules.
- Configure ESP. It has three phases: device preparation, device setup, and account setup. It can track policies, certificates, network connection, and applications.
- Open Intune admin center → Devices → Windows → Enrollment → Windows Autopilot → Deployment Profiles, create the profile, choose the deployment mode and Microsoft Entra join type, and configure OOBE options such as privacy, EULA, language, account type, and pre-provisioning.
Microsoft currently documents a maximum of 350 deployment profiles per tenant. A device needs an assigned profile before deployment; without one, the default Autopilot profile applies. Microsoft also documents that some conflicting assignments resolve to the oldest-created applicable profile, so avoid overlapping broad assignments (profile documentation).
3. Register the hardware
Ask the OEM, reseller, distributor, or Microsoft partner to register the device to the correct tenant whenever possible. Otherwise import the hardware identity manually or harvest it from a running Windows installation. Confirm the device at Devices → Enrollment → Windows → Windows Autopilot → Devices, checking serial number, tenant ownership, hardware identity, group membership, and profile status.
Free tools Windows power users keep installed
One-click scans. No signup required.
A hardware hash can change when regenerated because it contains generation-time information, and a motherboard replacement may require a new hash. Deleting a normal Intune device object does not necessarily deregister it from Autopilot. The Autopilot registration lifecycle is documented at Microsoft’s registration overview.
4. Test OOBE
- Use a factory-fresh or correctly reset device and connect it to a reliable network.
- Confirm the expected organization-branded OOBE appears after region and keyboard selection.
- Sign in with a pilot account for user-driven mode, or validate the unattended flow for self-deploying mode.
- Watch ESP and confirm Entra join, Intune enrollment, device name, applications, configuration, compliance, security policies, and local administrator behavior.
- Test restart, sign-out, temporary offline conditions, recovery, and reassignment before expanding the pilot.
Make ESP reliable
ESP is where many deployments fail. A package that needs interactive input, has an incorrect detection rule, depends on another app that is not installed, or cannot reach its download source can leave the user waiting. Installing too many applications in the blocking phase increases deployment time and fragility.
- Block ESP only on applications and security controls that are genuinely required before work can begin.
- Move nonessential software to post-enrollment Intune assignments or Company Portal.
- Test each installer locally with silent-install parameters and validate its detection rule.
- When ESP reports a failure, identify the named app or policy, review Intune Management Extension and device-management logs, fix the package, and retest it independently.
Allowing users to continue after a failed nonessential application can be reasonable; bypassing a failed security control or essential business application is not.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Registration and profile troubleshooting
Autopilot experience does not appear
- Verify the device exists in the Autopilot inventory, has the correct serial number and tenant, and is not registered elsewhere.
- Check that a profile is assigned and allow processing time. Microsoft documents up to 48 hours for the “convert all targeted devices to Autopilot” registration scenario.
- Check network access, required services, and whether the reset produced the intended OOBE state.
The wrong profile appears
Overlapping groups, delayed membership, a default profile, or conflicting assignments can cause this. Use dedicated pilot groups, inspect assignment status and profile creation order, correct the groups, then reset and enroll again. Editing a profile does not retroactively change an already-enrolled device.
Self-deploying mode fails
Check TPM readiness, firmware, attestation support, network connectivity, profile settings, and ESP compatibility. If the hardware cannot meet the no-user requirements, use user-driven deployment instead.
Best Value
Reset, reuse, and retire devices
For an in-tenant refresh, initiate Intune → Devices → All devices → select device → device actions → Autopilot Reset. A local reset can be started from the lock screen with CTRL + WIN + R, followed by local-administrator authentication (Autopilot Reset documentation). Resetting does not remove the device from Autopilot.
When a PC leaves the organization, follow the documented cleanup order: remove or retire its Intune and Entra objects as appropriate, then deregister it from Autopilot so it no longer identifies itself as belonging to the former tenant. Device deletion, reset, and Autopilot deregistration are separate lifecycle operations.
Monitor deployments
View the current report at Devices → Monitor → Windows Autopilot deployment status. Microsoft documents this report as preview data retained for 30 days; some resets or deployments that do not trigger a new Intune enrollment may not appear. Treat it as an operational aid, not a permanent historical record.
Autopilot versus alternatives
| Approach | Best fit | Trade-off |
|---|---|---|
| Traditional imaging | Offline, highly customized, hardware-specific builds | Image, driver, and update maintenance; weaker remote provisioning. |
| Configuration Manager | Mature task sequences, on-premises management, co-management | More infrastructure; can complement rather than replace Autopilot. |
| Windows Configuration Designer | Small, offline or specialized provisioning jobs | Not a full centralized lifecycle-management platform. |
| Autopilot device preparation | Microsoft’s related newer provisioning approach | Separate registration, policy, reporting, and scenario requirements; compare it explicitly with classic Autopilot. |
For co-management guidance, see Microsoft’s Configuration Manager and Autopilot documentation.
Quick Recap
Is Autopilot right for your organization?
- Choose it when devices are organization-owned, internet-connected, supplier registration is available, and Intune-ready applications and policies can be maintained.
- Plan hybrid join or co-management when file shares, certificates, VPN, Group Policy, or legacy applications still depend on on-premises services.
- Prefer another approach when devices must be deployed offline, applications require image-level integration, or the organization cannot support cloud identity and ongoing Intune operations.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
