Windows Autopilot Scenario for Streamlined Modern Device Deployment

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 Process End To End Guide
• Windows Autopilot In-Depth Processes From Device Side

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

• Windows Autopilot scenarios | Microsoft Learn

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.