8.3 KiB
title, description, keywords, ms.prod, ms.mktglfcycl, ms.localizationpriority, ms.sitesec, ms.pagetype, author, ms.author, ms.collection, ms.topic
| title | description | keywords | ms.prod | ms.mktglfcycl | ms.localizationpriority | ms.sitesec | ms.pagetype | author | ms.author | ms.collection | ms.topic |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Windows Autopilot for white glove deployment | Windows Autopilot for white glove deployment | mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune, pre-provisioning | w10 | deploy | low | library | deploy | greg-lindsay | greg-lindsay | M365-modern-desktop | article |
Windows Autopilot for white glove deployment
Applies to: Windows 10, version 1903
Windows Autopilot enables organizations to easily provision new devices - leveraging the preinstalled OEM image and drivers with a simple process that can be performed by the end user to help get their device business-ready.
Windows Autopilot can also provide a white glove service that enables partners or IT staff to pre-provision a Windows 10 PC so that it is fully configured and business-ready. From the end user’s perspective, the Windows Autopilot user-driven experience is unchanged, but getting their device to a fully provisioned state is faster.
With Windows Autopilot for white glove deployment, the provisioning process is split. The time-consuming portions are performed by IT, partners, or OEMs. The end user simply completes a few neceesary settings and polices and then they can begin using their device.
Enabled with Microsoft Intune in Windows 10, version 1903 and later, white glove deployment capabilities build on top of existing Windows Autopilot user-driven scenarios, supporting both the user-driven Azure AD join and Hybrid Azure AD join scenarios.
Prerequisites
In addition to Windows Autopilot requirements, Windows Autopilot for white glove deployment adds the following:
- Windows 10, version 1903 or later is required.
- An Intune subscription with additional flighted features that are not yet available publicly is currently required. Note: This feature will change soon from flighted to preview. Prior to this feature switching to preview status, attempts to perform white glove deployment without t flighted features will fail with an Intune enrollment error.
- Physical devices that support TPM 2.0 and device attestation; virtual machines are not supported. The white glove provisioning process leverages Windows Autopilot self-deploying capabilities, hence the TPM 2.0 requirements.
- Physical devices with Ethernet connectivity; Wi-fi connectivity is not supported due to the requirement to choose a language, locale, and keyboard to make that Wi-fi connection; doing that in a pre-provisioning process could prevent the user from choosing their own language, locale, and keyboard when they receive the device.
Preparation
To be ready to try out Windows Autopilot for white glove deployment, ensure that you can first successfully use existing Windows Autopilot user-driven scenarios:
- User-driven Azure AD join. Devices can be deployed using Windows Autopilot and joined to an Azure Active Directory tenant.
- User-driven with Hybrid Azure AD join. Devices can be deployed using Windows Autopilot and joined to an on-premises Active Directory domain, then registered with Azure Active Directory to enable the Hybrid Azure AD join features.
If these scenarios cannot be completed, Windows Autopilot for white glove deployment will also not succeed since it builds on top of these scenarios.
To enable white glove deployment, an additional Autopilot profile setting must be configured:
Tip
To see the white glove deployment Autopilot profile setting, use this URL to access the Intune portal: https://portal.azure.com/?microsoft_intune_enrollment_enableWhiteGlove=true. This is a temporary requirement.
The Windows Autopilot for white glove deployment pre-provisioning process will apply all device-targeted policies from Intune. That includes certificates, security templates, settings, apps, and more – anything targeting the device. Additionally, any apps (Win32 or LOB) that are configured to install in the device context and targeted to the user that has been pre-assigned to the Autopilot device will also be installed. Note: other user-targeted policies will not apply until the user signs into the device. To verify these behaviors, be sure to create appropriate apps and policies targeted to devices and users.
Scenarios
Windows Autopilot for white glove deployment supports two distinct scenarios:
- User-driven deployments with Azure AD Join. The device will be joined to an Azure AD tenant.
- User-driven deployments with Hybrid Azure AD Join. The device will be joined to an on-premises Active Directory domain, and separately registered with Azure AD. Each of these scenarios consists of two parts, a technician flow and a user flow. At a high level, these parts are the same for Azure AD Join and Hybrid Azure AD join; differences are primarily seen by the end user in the authentication steps.
Technican flow
The first part of the Windows Autopilot for white glove deployment process is designed to be carried out by a technician; this could be a member of the IT staff, a services partner, or an OEM – each organization can decide who should perform these activities. Regardless of the scenario, the process to be performed by the technician is the same:
- Boot the device (running Windows 10 Pro, Enterprise, or Education SKUs, version 1903 or later).
- From the first OOBE screen (which could be a language selection or locale selection screen), do not click Next. Instead, press the Windows key five times to view an additional options dialog. From that screen, choose the Windows Autopilot provisioning option and then click Continue.
- On the Windows Autopilot Configuration screen, information will be displayed about the device:
- The Autopilot profile assigned to the device.
- The organization name for the device.
- The user assigned to the device (if there is one).
- A QR code containing a unique identifier for the device, useful to look up the device in Intune to make any configuration changes needed (e.g. assigning a user, adding the device to any additional groups needed for app or policy targeting).
- Validate the information displayed. If any changes are needed, make these and then click Refresh to re-download the updated Autopilot profile details.
- Click Provision to begin the provisioning process. If the pre-provisioning process completes successfully:
- A green status screen will be displayed with information about the device, including the same details presented previously (e.g. Autopilot profile, organization name, assigned user, QR code), as well as the elapsed time for the pre-provisioning steps.
- Click Reseal to shut the device down. At that point, the device can be shipped to the end user.
If the pre-provisioning process fails:
- A red status screen will be displayed with information about the device, including the same details presented previously (e.g. Autopilot profile, organization name, assigned user, QR code), as well as the elapsed time for the pre-provisioning steps.
- Diagnostic logs can be gathered from the device, and then it can be reset to start the process over again.
User flow
If the pre-provisioning process completed successfully and the device was resealed, it can be delivered to the end user to complete the normal Windows Autopilot user-driven process. They will perform a standard set of steps:
- Power on the device.
- Select the appropriate language, locale, and keyboard layout.
- Connect to a network (if using Wi-Fi). If using Hybrid Azure AD Join, there must be connectivity to a domain controller; if using Azure AD Join, internet connectivity is required.
- On the branded sign-on screen, enter the user’s Azure Active Directory credentials.
- If using Hybrid Azure AD Join, the device will reboot; after the reboot, enter the user’s Active Directory credentials.
- Additional policies and apps will be delivered to the device, as tracked by the Enrollment Status Page (ESP). Once complete, the user will be able to access the desktop.