The Autopilot profile is the first decision point in the provisioning flow. It determines the deployment mode, the out-of-box experience, and how much control the user has during setup. Most environments need one profile. Some need two. Almost nobody needs more than that.
The architecture article covered why Autopilot exists and what problem it solves. This one covers how to configure it – which deployment mode to choose, what the profile settings actually do, and where the decisions have long-term consequences.
Deployment modes
Autopilot has three deployment modes that matter in practice: User-Driven, Pre-provisioned, and Self-Deploying. A fourth mode – Reset – is technically an Autopilot flow but it’s a device recovery operation, not a provisioning mode.
User-Driven is the default and the right choice for most deployments. The device ships to the user, the user powers it on, signs in with their Entra ID credentials, and Autopilot handles the rest. Policy applies, apps install, the Enrollment Status Page holds the device at the setup screen until the required configuration is complete. The user ends up with a fully configured device without IT touching it.
Pre-provisioned – formerly called White Glove – splits the provisioning process into two phases. IT or the hardware vendor completes the device-targeted configuration before the device ships. The user receives a partially configured device and completes only the user-targeted portion. This reduces the time the user spends waiting at the setup screen, which matters when you have a large app catalog or slow app installs. It requires the device to be physically handled before shipping, which adds a step to the logistics process.
Self-Deploying mode provisions the device without any user interaction. No sign-in prompt, no user credentials, no user context. The device enrolls, applies policy, and lands at the Windows desktop ready for use. This mode is for shared devices, kiosks, and devices that don’t have a dedicated user – conference room machines, reception desks, shared workstations. It requires TPM 2.0 and attestation, which modern hardware supports but older hardware may not.
Choose the deployment mode based on who handles the device and when. User-Driven for direct-to-user shipping. Pre-provisioned when you want IT to do the heavy lifting first. Self-Deploying for shared and kiosk devices.
Profile settings that matter
Within the Autopilot profile, several settings have meaningful consequences beyond their default values.
Deployment mode is the first setting and drives everything else. Set it correctly before configuring anything else in the profile.
Join to Entra ID as controls whether the device joins as Entra ID joined or Hybrid Entra ID joined. For cloud-native deployments – which is what this series is building toward – choose Entra ID joined. Hybrid join requires line-of-sight to a domain controller during provisioning and introduces the dependencies that cloud-native management exists to avoid. If you’re in a hybrid environment that requires domain join for specific reasons, that’s a legitimate constraint, but it should be a deliberate choice rather than a default.
User account type controls whether the provisioning user becomes a local administrator or a standard user. Set this to Standard User. Provisioning with admin rights and then trying to remove them afterward is harder than starting with standard user from the beginning. If specific users need local admin, use LAPS or a separate process to grant it selectively.
Skip specific pages in OOBE controls which out-of-box experience screens are shown or hidden during setup. In a corporate deployment you typically want to skip the privacy settings screen, the Windows Hello setup, and the usage agreements that don’t apply to managed devices. Hiding these creates a cleaner setup experience and prevents users from making choices that your policy will override anyway.
Allow pre-provisioned deployment enables the Pre-provisioned mode technician flow. Leave this off unless you’re actively using Pre-provisioned mode. Enabling it on a User-Driven profile doesn’t break anything, but it exposes a flow that your support staff may not be trained on.
Profile assignment
Autopilot profiles assign to device groups, not user groups. The assignment needs to resolve before the device reaches the Autopilot setup flow – which means the device needs to be in the group at the time it connects to the Autopilot service during OOBE. For devices registered in advance through hardware hash upload or OEM registration, this happens automatically. For devices registered at enrollment, the timing can be tighter.
Create a dedicated Autopilot device group for profile assignment rather than using your general production device group. Autopilot profile assignment is a provisioning-time operation – once the device is enrolled and in production, the profile has already done its job. Keeping the Autopilot group separate makes it easier to manage profile assignment without affecting production policy targeting.
If you have multiple deployment modes in use – User-Driven for standard devices and Self-Deploying for shared devices – you need separate profiles and separate device groups for each. The profile drives the entire setup experience, so devices that need different setup flows need different profiles assigned before they reach setup.
Testing before production
Test every Autopilot profile end-to-end before assigning it to production devices. The setup flow is not easily interrupted – a misconfigured profile can result in a device that’s enrolled but incorrectly configured, which often requires a wipe and re-enrollment to fix. The cost of testing is one device and thirty minutes. The cost of a misconfigured profile in production is every affected device.
Test with a device that represents your standard hardware. Autopilot behavior can differ between hardware generations, particularly around TPM attestation and driver availability during setup. A profile that works on one model may behave differently on another.
Intune Deployment Guide · Phase 4: Provisioning
‹ Previous: [4.1] Windows Autopilot: Consistent Provisioning Without Touching the Device
Next: [4.1.2] Enrollment Status Page: Designing for Reliability ›
