This post is targeted at those who have little or no experience with Microsoft Intune and Windows AutoPilot. The main goal of this article is to provide a basic understanding of AutoPilot, its components and to understand some of the benefits of utilizing Windows AutoPilot as a provisioning platform for your devices. Should you want to setup your own environment then check out my step-by-step guide on how to setup Windows AutoPilot. In the step-by-step guide you can also see a video of Windows AutoPilot and Intune in action.
Windows AutoPilot is a provisioning method for corporate Windows 10 devices that leverages modern management and cloud services. AutoPilot is an alternative to operating system deployment (OSD) products such as Configuration Manager, Microsoft Deployment Toolkit (MDT) and others. In this post we will introduce AutoPilot, describe the different alternatives that exist today and some of their limitations.
Why Windows AutoPilot?
Windows AutoPilot has actually been around for a few years now, and we have several variants that we can choose from. Currently the variants are:
- User Driven Azure AD Join
- User Driven Hybrid Join
- Self-Deploying Mode
- AutoPilot White Glove
- Windows AutoPilot for Existing Devices
We will go through each of these scenarios in detail below as there are a different requirements and use cases for each scenario.
The reason that so many organizations are looking into Windows AutoPilot, is firstly that it greatly reduces the amount of logistics needed to get a computer up an running. Traditionally when an organization purchases new devices, they will need to be shipped from the OEM/Vendor to the organization’s IT department. Here they are unboxed and provisioned using a tool like Configuration Manager or MDT and finally distributed to end-users. This process is a logistical nightmare, takes time and is costly to maintain. Secondly, traditional deployments will need testing and verification for each model purchased. Not to mention creating and maintaining driver packages, firmware updates and sometimes even application customization.
What we are basically doing with traditional deployment methods, is overwriting everything that comes from the OEM/Vendor and starting from scratch. Why? The vendor already has a version of Windows pre-installed installed on the device, and all of the drivers and software needed to support that device is already present. Enter Windows AutoPilot.
Windows AutoPilot does not really do Operating System Deployment (OSD) as seen from a traditional perspective, instead it transforms what is already on the device into a production ready client. This includes changing the SKU/Edition of Windows 10 from for example Pro to Enterprise, installing corporate applications/settings, securing the device and much more. When an organization purchases a new device, the OEM/Vendor can upload the unique ID (machine hash) for that particular device into the organizations Microsoft 365 tenant. The administrator of the tenant can then assign an AutoPilot Profile to the device (describes how the device should be provisioned), without ever touching the device itself. The OEM/Vendor can then ship the device directly to the end-user such as their home without involving corporate IT.
The end-user will unbox the device, power it on and connect it to their home network with internet access. The device will then connect to the Windows AutoPilot service, to check if the device is registered with an organization and that an AutoPilot Profile is assigned. The assigned AutoPilot Profile is then downloaded and the device either automatically provisions, or the user is asked to enter their corporate credentials. This behavior depends on the type of AutoPilot scenario specified in the AutoPilot profile. The most common scenario is for the user to enter their credentials as a device is normally associated with a particular user. Once the user credentials are confirmed AutoPilot will enroll the device into Azure AD and Microsoft Intune, which applies applications, settings, certificates, security baselines and so forth to the device. When the device has finished provisioning, the user is presented with their desktop and can start to work normally.
If there is a problem with a device, it can be easily reset either from the device itself or by a remote wipe request from the Intune/Endpoint Manager console. This reset actually rebuilds the Windows installation and removes any installed applications, settings and data. Once complete, the device can be provisioned again through Windows AutoPilot by either the same or a different user.
License Requirements
AutoPilot requires an Azure AD Premium 1 (P1) license to be assigned to the user, however we also require an Intune (or third-party a Mobile Device Management solution) license for management. The Enterprise Mobility + Security (EMS) E3/E5 license has all these features included, including many more such as Multi-Factor Authentication support. There is also support for Device Based Licensing, meaning that the device itself is licensed instead of allocating a specific user a license. This is handy if the organization is deploying a large number of kiosks.
User Driven Azure AD Join
User Driven Azure AD Join was the first scenario that was released by Microsoft, and is often called the regular or normal AutoPilot scenario. In this scenario the device is enrolled into Azure AD and Microsoft Intune for management just like described above. This scenario is perfect for an organization that wants to move all its resources to the cloud, and doesn’t have large dependencies on an on-premise Active Directory environment.
- Windows 10 1703 or later
- Devices can be deployed from anywhere
- Supports Cable and Wi-Fi
- Device is associated to the user who deploys the device
User Driven Hybrid Join
In a User Driven Hybrid Join scenario the device is joined to the on-premise Active Directory and synchronized back to Azure AD. Since the device will be joined to the on-premise Active Directory, we need to be able to communicate with a Domain Controller within that environment. This causes us to loose the flexibility of being able to provision devices from anywhere. Microsoft have announced a private preview, that allows the use of a VPN to complete the Active Directory join process. Hopefully there will be a public preview for VPN support late in 2020. This scenario is ideal for organizations who are dependent on an on-premise environment, but still want to leverage Windows AutoPilot as a deployment mechanism.
Because of the limitations, missing functionality and stability issues in this scenario, I usually don’t recommend this scenario in a production environments. Microsoft is making a lot of investments into solving the many issues, but per my opinion they are not quite there yet. Hopefully Microsoft will provide us with more information at Microsoft Ignite 2020.
- Windows 10 1809 or later
- Requires line of sight to an on-premise Domain Controller (VPN support in private preview)
- Requires Hybrid Join setup on Azure AD Connect
- Requires an Azure AD Connector on-premise.
- Missing some of the functionality that User Driven Azure AD Join has
- Duplicate objects / Stability Issues
Self-Deploying Mode
Self-Deploying mode is intended to be used for devices like kiosks that usually don’t have a specific user assigned to the device. When an AutoPilot device is provisioned, the process is completely automated. An end-user simply needs to connect the device to a wired network and power on the device and AutoPilot will take care of the rest.
- Windows 1903 or later
- Requires TPM 2.0 (TPM Attestation)
- Requires cable connection
- Must be Physical Device (no VM Support)
AutoPilot White Glove
If there are lots of applications that need to be deployed during the AutoPilot process, the deployment can take a long time especially on slower connections. AutoPilot White Glove can resolve some of these pains by running the deployment in stages.
There are three stages in an AutoPilot deployment. First is the registrations phase that enrolls the device into Azure AD and Intune. Second is the device phase, where applications and configuration at the device level (device context) is installed/configured. The third and final phase is the user phase, where any deployments specific to the user is done. An example would be the deployment of an application that needs to be installed in the users profile.
With White Glove an OEM/Partner or the organization’s IT department, can provision a device at the device stage before a user receives it. This means that many of the larger applications can be installed prior to sending the device to an end-user. The end-user will then only need to run through the user phase, reducing the total amount of data that needs to be downloaded and reducing provisioning time, creating a better user experience.
White Glove uses elements from the Self-Deploying mode and therefore has similar requirements.
- Windows 1903 or later
- Requires TPM 2.0 (TPM Attestation)
- Requires cable connection
- Must be Physical Device (no VM Support)
AutoPilot for Existing Devices
AutoPilot for existing devices is a scenario that can be leveraged by organizations who have already deployed services like SharePoint Online, Teams and OneDrive. An example could be, moving from Windows 7 to Windows 10 and in the same process switching from Configuration Manager to Intune. A task sequence from Configuration Manager can be deployed to the client, the task sequence will boot the device in Windows PE (Pre-Install Environment), format the drive, apply a clean Windows 10 image and add a file that contains AutoPilot information before restarting the device. After the restart the device will enter OOBE (Out-of-box-Experience) where an AutoPilot User Driven scenario will take over from Configuration Manager.
- Windows 10 1809 or later
- Windows 7 -> Windows 10
- Configuration Manager task sequence followed by AutoPilot user driven mode
- Supports cable and Wi-Fi.
Conclusion
We have gone through the different AutoPilot scenarios, their use cases and limitations to get a basic understanding of Windows AutoPilot. Check out the step-by-step guide on how to setup a Windows AutoPilot environment to get some hands on experience and to learn more about Windows AutoPilot and Intune.
