In this post, You will get an overview of the Windows Autopilot scenario that illustrates how Windows Autopilot could be used in a typical deployment. The Windows Autopilot profile selection process is explained in the previous post.
Windows Autopilot simplifies the device deployment process, reduces the burden on IT staff, and enables end-users to start working more quickly and efficiently.
If you are looking for guidance on how to determine which Autopilot deployment scenario to use, as well as step-by-step instructions for each scenario? Special Thanks to Frank Rojas and Intune team for simplifying the scenarios that would be easy to taking decisions.
Selecting the right Autopilot deployment scenario hinges on several factors, including the organization’s specific needs and the deployment environment. Among the critical considerations is the device identity in use, which may either be Azure AD or hybrid Azure AD. This choice of device identity can potentially impact which Autopilot scenarios are feasible and can be utilized in the given deployment environment.
Is Autopilot an alternate for OSD? The answer is NO. Autopilot is not an alternative to OSD; it was never meant to be. Autopilot does not deploy OS to the end device but is just a means to provide end-users with a customized, streamlined device setup process. Joy, explained the working details behind Windows Autopilot.
Windows Autopilot Scenarios
AutoPilot service helps the organization pre-configure New devices, Recover Devices, Re-purpose Devices, and Reset Devices. Windows Autopilot also has several capabilities that make it a powerful tool for IT professionals.
The Windows Autopilot for existing devices scenario allows for a full reinstallation of the Windows operating system on a device, in anticipation of an Autopilot deployment. It’s worth noting, however, that this scenario isn’t considered an Autopilot deployment in and of itself.
Once the Windows Autopilot for existing devices process is finished, one of three Autopilot scenarios – User-driven, Pre-provisioned, or Self-deploying – will automatically commence.
To gain a better understanding of the Windows Autopilot profile types, let us examine the table and review each column in detail for the scenario, purpose along with added descriptions. If you have any queries or concerns, please feel free to leave a comment below.
| Scenario | Purpose | Description |
|---|---|---|
| Windows Autopilot user-driven mode | Device for a single user | User runs deployment |
| Windows Autopilot for pre-provisioned | Device for a single user | Deployment is split between IT admin/OEM/reseller and user |
| Windows Autopilot self-deploying mode | Kiosk device or device for multiple users | Deployment is completely automated |
| Windows Autopilot for existing devices | Prepare device where Windows OS needs to be reinstalled for a Windows Autopilot deployment | Utilizes Microsoft Configuration Manager to install a fresh Windows OS on an existing device before running a Windows Autopilot deployment |
| Windows Autopilot Reset | Resets an existing device back to the factory default installation of Windows | Utilizes the existing installation of Windows on a device to rebuild Windows and restore it back to the factory installation of Windows |
Windows Autopilot Scenario Pros and Cons
Windows Autopilot offers many benefits for organizations looking to streamline their device deployment process. However, as with any technology solution, there are also some pros and cons of using Windows Autopilot scenarios during the deployment process.
| Scenario | Pros | Cons |
|---|---|---|
| User-driven | • Requires no interaction from admin/OEM/reseller • Doesn’t require TPM attestation so works on physical devices and VMs | • Takes longer for user than the pre-provisioned scenario since user has to go through both device ESP and user ESP |
| Pre-provisioned | Faster for user since IT admin/OEM/reseller handles bulk of device ESP during the technician flow | • Requires interaction by IT admin/OEM/reseller • Requires TPM attestation during technician flow so only works on physical devices with supported TPM (doesn’t work in VMs even with virtual TPM) |
| Self-deploying | Requires no interaction from user or admin/OEM/reseller | • Can’t assign a user to the device • User ESP doesn’t run since no user is assigned • Requires TPM attestation so only works on physical devices with supported TPM (doesn’t work in VMs even with virtual TPM) • Doesn’t support hybrid Azure AD join devices |
| Existing devices | • Can use custom images • Can use ConfigMgr task sequences • Can reinstall a fresh copy of Windows in cases of severe corruption in Windows installation • Good scenario to upgrade a device from domain joined/hybrid Azure AD join to Azure AD join | • Requires Microsoft Configuration Manager • Not an actual Autopilot deployment so doesn’t work on its own – only works alongside one of the other Autopilot scenarios • Takes longer since device has to undergo both task sequence and Autopilot deployment |
| Reset | Easily allows resetting an existing broken or repurposed device to a business ready state | • Doesn’t work if there’s severe corruption in Windows installation • Doesn’t support hybrid Azure AD join devices |
Decision Tree Decide Windows Autopilot Profile Types
The below diagram shows some of the basic questions that help decide your autopilot profile type. And a common challenge for customers. More details from How To Decide Windows Autopilot Profile Types | Intune Architecture.
Autopilot Scenario Capabilities
Windows Autopilot offers several capabilities that make it an attractive option for modern device deployment and management, due to the variety of environments and configurations that IT administrators deal with, different scenarios are needed to meet different needs.
Fortunately, Windows Autopilot offers several scenarios that can be tailored to specific requirements. These scenarios include Self-Deploying mode, User-Driven mode, Hybrid Azure AD Join, pre-provisioning deployment, and Reset, which enables devices to be easily reset and repurposed. The following table compares the different capabilities.
All Autopilot scenarios support Azure AD join, while only the User-driven, Pre-provisioned, and Existing devices scenarios support hybrid Azure AD join
| Scenario | User-driven | Pre-provisioned | Self-deploying | Existing devices | Reset |
|---|---|---|---|---|---|
| Supports Azure AD join | ✅ | ✅ | ✅ | ✅ | ✅ |
| Supports hybrid Azure AD join | ✅ | ✅ | ❌ | ✅ | ❌ |
| Registered as an Autopilot device before deployment | ✅ | ✅ | ❌ | NA | Local reset |
| Deployment requires interaction by IT admin/OEM/reseller | ❌ | ✅ | ❌ | ✅ | Remote reset |
| Deployment requires interaction by the user | ✅ | ✅ | ❌ | NA | NA |
| Minimizes time user interacts with deployment | ❌ | ✅ | ✅ | NA | NA |
| User authenticates | ✅ | User flow | ❌ | NA | Local reset |
| TPM authenticates | ❌ | Technician flow | ✅ | NA | NA |
| Registered as Autopilot device before deployment | ✅ | ✅ | ✅ | ❌ | ✅ |
Download Windows Autopilot Deployment Flowchart
Happy Autopiloting🙂Bonus tip: Windows 10/11 Autopilot deployment process PDF can be downloaded from the link. You can download the Windows Autopilot Deployment Flowchart prepared by Michael Niehaus.
Reference
Author
About Author – Jitesh, Microsoft MVP, has over six years of working experience in the IT Industry. He writes and shares his experiences related to Microsoft device management technologies and IT Infrastructure management. His primary focus is Windows 10/11 Deployment solution with Configuration Manager, Microsoft Deployment Toolkit (MDT), and Microsoft Intune.
Perfect
Hi Jitesh,
The cons for “Pre-Provisioned” of “Existing Devices” in “Pre-Provisioned”.
Thank you Shivam! Updated 🙂
Difference between osd n auto pilot?
I didn’t understand jitesh