Getting started with Windows Autopilot

Windows AutoPilot allows users to install a new Windows 10 device themselves direct out-of-the-box. Without guidance from the IT department. This allows the end-user (the employee) to receive the device directly from the supplier at home.
No imaging is done by the IT department before the device is handed over to the end-user. This saves the IT department a lot of time.

As soon as the user turns on the device (and connects it to the internet), it does an online check at Microsoft if the device is registered at the Windows Autopilot service. If it is registered, a sign-in page of the company is shown to enter the corporate credentials. After authentication, the registration at Azure AD and Microsoft Intune starts. Settings deployed with Intune are pushed to the device, even as software packages. When the enrollment is finished, the end-user is signed into the device and has a work-ready device.
Optionally, you can allow the device to register at Azure AD and on-premises Active Directory to get a Hybrid Azure AD Joined device. And by installing the Configuration Manager client, you`re also able to set up a co-managed device.

Let`s have a look at all the parts which are involved to get started with Windows Autopilot.

Automatic enrollment

The first requirement is to make sure Azure AD Automatic enrollment is configured by setting the MDM User scope to a group of users or to all.

Most Windows Autopilot related settings are found in the Endpoint Admin center under Devices, Windows, Windows enrollment.

If you open Automatic Enrollment you can set the MDM Scope.

Azure AD Custom branding

It might sound strange, but we need to configure Azure AD custom branding. If we don`t configure this, enrollment of a Windows 10 device fails using Autopilot.

Key elements for Autopilot include the “square logo”, “sign-in page text”, and Azure Active Directory tenant name.
Configuration can be done in the Azure (AD) portal, under Azure Active Directory, Company Branding.

Device registration

To use Windows Autopilot as an enrollment feature, our Windows 10 devices need to be registered at the Windows Autopilot service. The big hardware vendors, like Dell, HP, Lenovo and Microsoft itself, are able to register the devices which you purchase in your tenant. So contact your vendor and get these devices registered.

For testing purposes, it is also possible to export the required information with a PowerShell script created by Michael Niehaus and upload it manually. But this is not officially supported by Microsoft for production.

As soon as the device is registered, the device is found in the Endpoint Manager admin center, under Devices, Windows, Windows enrollment, Devices. You can search through the devices on serial number. In the overview, you see the serial numbers, Manufacturers, Models, Group tags, the Profile status and Purchase orders.

If we click on one of the serials we get more details of the device. We see the date on which the profile is assigned and the associated Intune and Azure AD device when the device is enrolled.

Deployment profiles

To get our devices enrolled we need to create and assign at least one Deployment profile to our devices. In a deployment profile, we set the out-of-the-box experience for our end-users. We first choose a deployment mode, User-Driven, or Self-Deploying.
For a standard enrollment, we choose User-Driven, which associates the device with a user. For shared or kiosk devices you choose Self-Deploying.
The next setting to choose is the Azure AD join type, cloud-only (Azure AD) or Hybrid-Azure AD joined (see the Offline Domain Join section). If you choose Hybrid, the enrollment needs to be done on a network with a connection to your Domain Controllers. You also have the option to skip the Domain check and perform the enrollment using a VPN connection.
Furthermore, we need to make choices which out-of-the-box screens are shown to the end-user, like the EULA, or hide these screens and we are able to pre-configure region and keyboard settings.
We set the User account type to administrator or standard user and allow or block pre-provisioned deployment (formerly know as White-Glove, more on that later).
With the last setting, we are able to apply a name template, to create a unique name for our devices based on this template.

Enrollment Status Page

The next part of Autopilot we setup is the Enrollment Status Page (ESP). The enrollment status page appears during the initial device setup and during the first user sign in, when enabled. If enabled, users can see the configuration progress of assigned apps and profiles targeted to their device. There are three phases where the Enrollment Status Page tracks information for; device preparation, device setup, and account setup.
Besides the ESP shows the enrollment status to the user, it also has another benefit. By using the ESP we make sure the targeted configuration profiles are applied and required applications are installed before the user is signed in for the first time to the device. If we don`t use the ESP, profiles are still being applied and applications are not yet installed when the user signs in. The device isn`t ready yet for use.
In the ESP profile, we set a maximum duration of the enrollment, if the user is allowed to use the device when a part of the enrollment fails and if the user is allowed to reset the device after a failure.

And we set if the ESP should block the device until all or a part of the apps are installed. Keep in mind for this setting, the ESP at least waits for these selected apps, bt=ut it might also wait for other apps.

Windows Autopilot for pre-provisioned deployment

Does it take a lot of time to install all these different settings, drivers and software? Then Windows Autopilot for pre-provisioned deployment (before known as White glove) is here for you. This is an additional option within Windows AutoPilot. Through Pre-provisioned deployment, the manufacturer, a partner or the company’s own IT department, can get all the device installations done before the device is handed over to the end-user.

You need to allow Pre-provisioned deployment in the enrollment profile first. Then when a device is turned on, Pre-provisioned deployment setup can be started by clicking the Windows button five times in the first OOBE screen. From this screen, click Refresh to re-download the updated Autopilot profile details. After that click Provision to begin the provisioning process.

If provisioning is successful, hit the reseal button and the device is ready to be shipped to the end-user. This saves the end-user a lot of enrollment time.
More on Windows Autopilot for pre-provisioned deployment can be found on Microsoft Docs.

(Offline) Domain Join

If you have the need to enroll your devices in Azure AD and the on-premises AD (Hybrid AADJ), additional setup is needed. First we need to install the Intune Connector for Active Directory in the on-premises network. During the enrollment of a User-Driven HAAD joined devices Intune connects to this connector to request an Offline Domain Join (ODJ). The Intune Connector provides an ODJ blob to Intune and Intune forwards this blob to the device. In the mean time the ODJ connector creates a computer account in Active Directory. The user sign-ins in to the device to complete the registration.

We also need to deploy a Domain Join configuration profile with Intune. In this profile, we set the Computer name prefix, (on-premises) domain name and Organization Unit in which the computer accounts are created.

If the Hybrid AAD join is done with the option to Skip AD connectivity check set to Yes, the connectivity check between step 6 and 7 of the overview is skipped. Authentication is done over a VPN Connection, that requires additional setup which differs between every VPN solution and it out of scope of this article.

Autopilot Device groups

To target our deployment profiles, configuration profiles and applications we need to have AAD Device groups in-place.
To create a group which contains all Autopilot registered device in your tenant, create a dynamic group with this query:
(device.devicePhysicalIDs -any (_ -contains “[ZTDId]”))

Every Autopilot device is registered with above PhysicalID ZTDid.

We can also (manually) assign TAGs to the Autopilot devices which we can then use in a Dynamic group query. A dynamic group based on such TAG (in this case is the TAG KIOSK) can be created with this query:
(device.devicePhysicalIds -any (_ -eq “[OrderID]:kiosk”))

Above query might be confusing as it uses OrderID for TAGs.

A third option is to use PurchaseOrderID. The PurchaseOrderID allows you to create a group that contains all devices from one order. This ID needs to be registered by the hardware vendor when they register the device at the Autopilot service.
This is the query based on the PurchaseOrderID:
(device.devicePhysicalIds -any (_ -eq “[PurchaseOrderId]:76222342342”))

Profile and application targeting

As written in the ESP section, there are three phases where the ESP tracks information. We need to keep this in mind when we target our configuration profiles and applications. Applications that are assigned to a device group are tracked during the Device phase and user group assigned profiles and apps during the User phase. Besides that, online Store apps are installed during the Account phase. If you want a Store app to be installed during the Device phase, use the offline version of the Store app.

A complete overview of this ESP tracking is found in the Microsoft Docs.

Licensing

So what licenses are needed to make use of Windows Autopilot?
To use the needed Azure Active Directory feature, we need at least an Azure AD P1 license. This license is needed to do automatic MDM enrollment and set the required Company Branding.  For the MDM features, we need a Microsoft Intune license.
These licenses are available separately or as a subscription that contains both licenses. Think of Intune for Education subscription, Enterprise Mobility + Security (EMS) or one of the Microsoft 365 subscriptions.

End-user experience

What the end-result is and what happens in the background differs per setup, but the enrollment phases are pretty equal for the end-user.

The devices needs to be connected to a network with internet connection.

The device does a check online to check if it`s registered at an Autopilot tenant. The device might reboot.

The sign-in page is shown. If the device is assigned to an end-user, only the password needs to be provided, otherwise first the (Azure) AD username needs to be provided.

The device might reboot again and the Device Preparation phase starts.

As soon as this phase is successfully finished, the Device Setup phase is started. Different profiles are applied and device targeted applications are installed. In my case I assigned 5 applications as required and assigned these to all devices.

The latest phase (the Account setup phase) starts, under which additional profiles and applications might be applied. Between the Device and Account setup, the user might need to sign-in an additional time. This could for example be caused by enrolling via a wireless connection, or sign-in is needed when a Hybrid AAD join is performed over a VPN connection.

As soon as this is all finished the user is signed into the Windows device. What the desktop looks like differs what is targeted to the device. I have installed Edge (Chromium), Office 365 suite, and the Company Portal. I also applied scripts to cleanup unwanted Store apps and set a default start menu.

And here is the enrollment shown in a video.

The registration of a PIN in above video is part of Windows Hello for Business, which is not necessary for Autopilot. For the whole tenant this can be turned off Devices, Windows Devices, Windows Enrollment, Windows Hello for Business.

I hope this post gets you started using Windows Autopilot.

More Windows Autopilot related blog post can be found here.