Windows Autopilot DEPLOYMENT

Contents
Windows Autopilot deployment

What's new
Overview
Windows Autopilot overview
Concepts
Scenarios and capabilities
Windows Autopilot update
Deployment scenarios
User-driven mode
Self-deploying mode
Windows Autopilot Reset
White glove
Support for existing devices
Requirements
Software requirements
Networking requirements
Licensing requirements
Configuration requirements
How-to guides
Register devices
Enroll devices in Intune
Deploy hybrid Azure AD-joined devices
Configure device profiles
Enrollment Status Page
BitLocker encryption
DFCI management
Troubleshoot Windows Autopilot
Troubleshooting Windows Autopilot
Policy conflicts
Known issues
Reference
Deployment processes
Support information
FAQ
Contacts
Registration authorization
Device guidelines
Motherboard replacement
Windows Autopilot: What's new
9/4/2020 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Autopilot update history

The following Windows Autopilot updates are available. Note : Updates are automatically downloaded and applied
during the Windows Autopilot deployment process.
No updates are available yet. Check back here later for more information.
New in Windows 10, version 2004

With this release, you can configure Windows Autopilot user-driven Hybrid Azure Active Directory join with VPN
support. This support is also backported to Windows 10, version 1909 and 1903.
If you configure the language settings in the Autopilot profile and the device is connected to Ethernet, all scenarios
will now skip the language, locale, and keyboard pages. In previous versions, this was only supported with self-
deploying profiles.

Windows Autopilot for white glove deployment is new in Windows 10, version 1903. See the following video:
Also new in this version of Windows:

The Intune enrollment status page (ESP) now tracks Intune Management Extensions.
Cortana voiceover and speech recognition during OOBE is disabled by default for all Windows 10 Pro
Education, and Enterprise SKUs.
Windows Autopilot is self-updating during OOBE. Starting with the Windows 10, version 1903 Autopilot
functional and critical updates will begin downloading automatically during OOBE.
Windows Autopilot will set the diagnostics data level to Full on Windows 10 version 1903 and later during
OOBE.

Windows Autopilot self-deploying mode enables a zero touch device provisioning experience. Simply power on the
device, plug it into the Ethernet, and the device is fully configured by Windows Autopilot. This self-deploying
capability removes the current need to have an end user interact by pressing the “Next” button during the
deployment process.
You can utilize Windows Autopilot self-deploying mode to register the device to an AAD tenant, enroll in your
organization’s MDM provider, and provision policies and applications, all with no user authentication or user
interaction required.
NOTE
Window 10, version 1903 or later is required to use self-deploying mode due to issues with TPM device attestation in
Windows 10, version 1809.
Related topics
What's new in Microsoft Intune
What's new in Windows 10
Overview of Windows Autopilot
Applies to
Windows 10
Windows Autopilot is a collection of technologies used to set up and pre-configure new devices, getting them
ready for productive use. You can also use Windows Autopilot to reset, repurpose, and recover devices. This
solution enables an IT department to achieve the above with little to no infrastructure to manage, with a process
that's easy and simple.
Windows Autopilot simplifies the Windows device lifecycle, for both IT and end users, from initial deployment to
end of life. Using cloud-based services, Windows Autopilot:
reduces the time IT spends on deploying, managing, and retiring devices.
reduces the infrastructure required to maintain the devices.
maximizes ease of use for all types of end users.
See the following video and diagram:
When initially deploying new Windows devices, Windows Autopilot uses the OEM-optimized version of Windows
10. This version is preinstalled on the device, so you don't have to maintain custom images and drivers for every
device model. Instead of re-imaging the device, your existing Windows 10 installation can be transformed into a
“business-ready” state that can:
apply settings and policies
install apps
change the edition of Windows 10 being used (for example, from Windows 10 Pro to Windows 10 Enterprise)
to support advanced features.
Once deployed, you can manage Windows 10 devices with:
Microsoft Intune
Windows Update for Business
Microsoft Endpoint Configuration Manager
or other similar tools.
With Windows Autopilot, you can quickly prepare a device for a new user with Windows Autopilot Reset. You can
also use Reset in break/fix scenarios to quickly bring a device back to a business-ready state.
Windows Autopilot enables you to:
Automatically join devices to Azure Active Directory (Azure AD) or Active Directory (via Hybrid Azure AD Join).
For more information about the differences between these two join options, see Introduction to device
management in Azure Active Directory.
Auto-enroll devices into MDM services, such as Microsoft Intune (Requires an Azure AD Premium subscription
for configuration).
Restrict the Administrator account creation.
Create and auto-assign devices to configuration groups based on a device's profile.
Customize OOBE content specific to the organization.
Benefits of Windows Autopilot

Traditionally, IT pros spend significant time building and customizing images that will later be deployed to devices.
Windows Autopilot introduces a new approach.
From the user's perspective, it only takes a few simple operations to make their device ready to use.
From the IT pro's perspective, the only interaction required from the end user is to connect to a network and to
verify their credentials. Everything beyond that is automated.
Requirements
A supported version of Windows 10 semi-annual channel is required to use Windows Autopilot. Windows 10
Enterprise LTSC 2019 is also supported. For more information, see Windows Autopilot software, networking,
configuration, and licensing requirements.
Related topics
Enroll Windows devices in Intune by using Windows Autopilot
Windows Autopilot scenarios and capabilities
Windows Autopilot scenarios and capabilities
Applies to: Windows 10
Scenarios
Windows Autopilot includes support for a growing list of scenarios, designed to support common organization
needs. These needs can vary based on the type of organization, and their progress moving to Windows 10 and
transitioning to modern management.
The following Windows Autopilot scenarios are described in this guide:
SC EN A RIO M O RE IN F O RM AT IO N
Deploy devices to be set up by a member of the organization Windows Autopilot user-driven mode
and configured for that person
Deploy devices to be automatically configured for shared use, Windows Autopilot self-deploying mode
as a kiosk, or as a digital signage device.
Redeploy a device in a business-ready state. Windows Autopilot Reset
Preprovision a device with up-to-date applications, policies, White glove

and settings.
Deploy Windows 10 on an existing Windows 7 or 8.1 device Windows Autopilot for existing devices
These scenarios are summarized in the following video.
Windows Autopilot capabilities

Windows Autopilot is self-updating during OOBE
Starting with the Windows 10, version 1903, Autopilot functional and critical updates will begin downloading
automatically during OOBE after a device is connected to a network, and the critical driver and Windows zero-day
patch (ZDP) updates have completed. The user or IT admin cannot opt out of these Autopilot updates because they
are required for Windows Autopilot deployment to operate properly. Windows will alert the user that the device is
checking for, downloading, and installing the updates.
See Windows Autopilot update for more information.
Cortana voiceover and speech recognition during OOBE
In Windows 10, version 1903 and later Cortana voiceover and speech recognition during OOBE is DISABLED by
default for all Windows 10 Pro, Education, and Enterprise SKUs.
You can also enable Cortana voiceover and speech recognition during OOBE by creating the following registry key.
This key does not exist by default:
HKLM\Software\Microsoft\Windows\CurrentVersion\OOBE\EnableVoiceForAllEditions
The key value is a DWORD with 0 = disabled and 1 = enabled.
VA L UE DESC RIP T IO N
0 Cortana voiceover is disabled
1 Cortana voiceover is enabled
No value Device will fall back to default behavior of the edition
To change this key value, use WCD tool to create as PPKG as documented here.
BitLocker encryption
With Windows Autopilot, you can configure the BitLocker encryption settings to be applied before automatic
encryption is started. For more information, see Setting the BitLocker encryption algorithm for Autopilot devices
Related topics
Windows Autopilot: What's new
Windows Autopilot update
Applies to
Windows 10, version 1903
Windows Autopilot update installs the latest Autopilot features and fixes to your organization's Autopilot devices.
The devices aren't moved to latest Windows OS version. With Autopilot update, you can keep the devices' current
OS version and still benefit from new Autopilot features and bug fixes.
The Windows Autopilot update process occurs after the critical Windows Zero Day Patch (ZDP) update check.
During the update process, the devices check Windows Update for a new Autopilot update. If there's an Autopilot
update available, the device downloads and installs the update, then restart automatically. See the following
example.
The following diagram illustrates a typical Windows Autopilot deployment orchestration during the Out of Box
Experience (OOBE) with the new Windows Autopilot update node.
Release cadence
When an Autopilot update is available, it's typically released on the fourth Tuesday of the month. The update
could be released on a different week if there's an exception.
A knowledge base (KB) article will also be published to document the changes that are included in the update.
For a list of released updates, see Autopilot update history.
See also
Windows Update during OOBE
What's new in Windows Autopilot
Windows Autopilot user-driven mode
Applies to: Windows 10, version 1809 or later

Windows Autopilot user-driven mode lets you configure new Windows 10 devices to automatically transform
them from their factory state to a ready-to-use state. This process doesn't require that IT personnel touch the
device.
The process is simple so that anyone can complete it. Devices can be shipped or distributed to the end user directly
with simple instructions:
1. Unbox the device, plug it in, and turn it on.
2. Choose a language (only required when multiple languages are installed), locale, and keyboard.
3. Connect it to a wireless or wired network with internet access. If using wireless, the user must establish the Wi-
Fi link.
4. Specify your e-mail address and password for your organization account.
The rest of the process is automated, as the device:
1. Joins the organization.
2. Enrolls in Intune (or another MDM service)
3. Is configured as defined by the organization.
Any additional prompts during the Out-of-Box Experience (OOBE) can be suppressed; see Configuring Autopilot
Profiles for options that are available.
Windows Autopilot user-driven mode supports Azure Active Directory and Hybrid Azure Active Directory joined
devices. For more information about these two join options, see What is a device identity.
The process flow completed during the user-driven process are as follows:
1. After connecting to a network, the device downloads a Windows Autopilot profile. The profile defines the
settings used for the device. For example, define the prompts suppressed during OOBE.
2. Windows 10 checks for critical OOBE updates. If updates are available, they're automatically installed
(rebooting if necessary).
3. The user is prompted for Azure Active Directory credentials. This customized user experience shows the Azure
AD tenant name, logo, and sign-in text.
4. The device joins Azure Active Directory or Active Directory, depending on the Windows Autopilot profile
settings.
5. The device enrolls in Intune (or other configured MDM services). Depending on your organizational needs, this
enrollment occurs:
during the Azure Active Directory join process using MDM auto-enrollment
or before the Active Directory join process.
6. If configured, the enrollment status page (ESP) will be displayed.
7. After the device configuration tasks complete, the user is signed into Windows 10 using the credentials they
previously provided. (If the device reboots during the device ESP process, the user must reenter their
credentials as these details aren't persisted across reboots.)
8. After sign-in, the enrollment status page displays for user-targeted configuration tasks.
If any issues are found during this process, see the Windows Autopilot Troubleshooting documentation.
For more information on the available join options, see the following sections:
Azure Active Directory join is available if devices don't need to be joined to an on-prem Active Directory
domain.
Hybrid Azure Active Directory join is available for devices that must be joined to both Azure Active Directory
and your on-prem Active Directory domain.
User-driven mode for Azure Active Directory join

To complete a user-driven deployment using Windows Autopilot, follow these preparation steps:
1. Make sure that the users who will be performing user-driven mode deployments can join devices to Azure
Active Directory. For more information, see Configure device settings in the Azure Active Directory
documentation.
2. Create an Autopilot profile for user-driven mode with the desired settings. In Microsoft Intune, this mode is
explicitly chosen when creating the profile. With Microsoft Store for Business and Partner Center, user-driven
mode is the default and doesn't need to be selected.
3. If using Intune, create a device group in Azure Active Directory and assign the Autopilot profile to that group.
For each device that will be deployed using user-driven deployment, these additional steps are needed:
Make sure that the device has been added to Windows Autopilot. Adding a device to Windows Autopilot can be
done in two ways:
Automatically by an OEM or partner at the time the device is purchased
Manual harvesting as described in Adding devices to Windows Autopilot.
Ensure an Autopilot profile has been assigned to the device:
If using Intune and Azure Active Directory dynamic device groups, this assignment can be done automatically.
If using Intune and Azure Active Directory static device groups, manually add the device to the device group.
If using other methods (for example, Microsoft Store for Business or Partner Center), manually assign an
Autopilot profile to the device.
User-driven mode for hybrid Azure Active Directory join

Windows Autopilot requires that devices be Azure Active Directory joined. If you have an on-premises Active
Directory environment, you can join devices to your on-premises domain. To join the devices, you must configure
Autopilot devices to be hybrid-joined to Azure Active Directory (Azure AD).
Requirements
To perform a user-driven hybrid Azure AD joined deployment using Windows Autopilot:
The device must be running Windows 10, version 1809 or later.
A Windows Autopilot profile for user-driven mode must be created and
Hybrid Azure AD joined must be specified as the selected option under Join to Azure AD as in the
Autopilot profile.
If using Intune, a device group in Azure Active Directory must exist with the Windows Autopilot profile assigned
to that group.
If using intune, create and assign a Domain Join profile. A Domain Join configuration profile includes on-
premises Active Directory domain information
The device must have access to an Active Directory domain controller. It must be connected to the
organization's network. It must be able to resolve the DNS records for the AD domain and the AD domain
controller. It must be able to communicate with the domain controller to authenticate the user.
The device must be able to access the Internet, following the documented Windows Autopilot network
requirements.
The Intune Connector for Active Directory must be installed.
Note: The Intune Connector will perform an on-prem AD join. Therefore, users don't need on-prem AD-join
permission. This assumes the Connector is configured to perform this action on the user's behalf.
If using Proxy, WPAD Proxy settings option must be enabled and configured.
Azure AD device join : The hybrid Azure AD join process uses the system context to perform device Azure AD
join. It's not affected by user-based Azure AD join permission settings. All users can join devices to Azure AD by
default.
User-driven mode for hybrid Azure Active Directory join with VPN
support
Devices joined to Active Directory require connectivity to an Active Directory domain controller for many activities.
These activities include user sign-in (validating the user's credentials) and Group Policy application. As a result, the
Windows Autopilot user-driven Hybrid Azure AD Join process would validate that the device is able to contact an
Active Directory domain controller by pinging that domain controller.
With the addition of VPN support for this scenario, you can configure the Hybrid Azure AD Join process to skip the
connectivity check. This doesn't eliminate the need for communicating with an Active Directory domain controller.
Instead, to allow connection to the organization's network, Intune delivers the needed VPN configuration before
the user attempts to sign in to Windows.
Requirements
The following additional requirements apply for Hybrid Azure AD Join with VPN support:
A supported version of Windows 10:
Windows 10 1903 + December 10 Cumulative update (KB4530684, OS build 18362.535) or higher
Windows 10 1909 + December 10 Cumulative update (KB4530684, OS build 18363.535) or higher
Windows 10 2004 or later
Enable the new “Skip domain connectivity check” toggle in the Hybrid Azure AD Join Autopilot profile.
A VPN configuration that:
can be deployed with Intune and lets the user manually establish a VPN connection from the Windows
logon screen, or
one that automatically establishes a VPN connection as needed.
The specific VPN configuration required depends on the VPN software and authentication being used. For third-
party (non-Microsoft) VPN solutions, this typically would involve deploying a Win32 app (containing the VPN
client software itself and any specific connection information, for example: VPN endpoint host names) via Intune
Management Extensions. Consult your VPN provider's documentation for configuration details specific to that
provider.
NOTE
The VPN requirements aren't specific to Windows Autopilot. For example, if you have already implemented a VPN
configuration to enable remote password resets, where a user needs to log on to Windows with a new password when not
on the organization's network, that same configuration can be used with Windows Autopilot. Once the user has signed in to
cache their credentials, subsequent log-on attempts don't need connectivity since the cached credentials can be used.
In cases where certificate authentication is required by the VPN software, the needed machine certificate should
also be deployed via Intune. This deployment can be done using the Intune certificate enrollment capabilities,
targeting the certificate profiles to the device.
User certificates aren't supported because they can't be deployed until the user logs in. Also, because they aren't
installed until after the user signs in, non-Microsoft UWP VPN plug-ins delivered from the Windows Store aren't
supported.
Validation
Before you attempt a hybrid Azure AD Join using VPN, it's important to confirm that a user-driven Hybrid Azure
AD Join process can be performed on the organization's network. This confirmation simplifies troubleshooting by
making sure the core process works before adding the additional VPN configuration required.
Next, validate that the VPN configuration (Win32 app, certs, and any other requirements) can be deployed using
Intune to an existing device that has already been hybrid Azure AD joined. For example, some VPN clients create a
per-machine VPN connection as part of the installation process. So, you can validate the configuration using steps
like these:
From PowerShell, verify that at least one per-machine VPN connection has been created using the "Get-
VpnConnection -AllUserConnection" command.
Attempt to manually start the VPN connection using the command: RASDIAL.EXE "ConnectionName"
Log out and verify that the "VPN connection" icon can be seen on the Windows logon page.
Move the device off the corporate network and try to establish the connection using the icon on the Windows
logon page. Sign into an account that doesn't have cached credentials.
For VPN configurations that automatically connect, the validation steps may be different.
NOTE
Always On VPN can be used for this scenario. For more information, see the Deploy Always On VPN documentation. Note
that Intune can't yet deploy the needed per-machine VPN profile.
To validate the process, ensure the needed Windows 10 cumulative update has been installed on Windows 10
1903 or Windows 10 1909. You can manually install the update during OOBE by first downloading the latest
cumulative from https://catalog.update.microsoft.com. Follow these steps:
1. Press Shift-F10 to open a command prompt.
2. Insert a USB key containing the downloaded update.
3. Install the update using the command (substituting the real file name): WUSA.EXE .msu /quiet
4. Reboot the computer using the command: shutdown.exe /r /t 0
Or, you can start Windows Update to install the latest updates:
1. Press Shift-F10 to open a command prompt.
2. Run the command "start ms-settings:"
3. Navigate to the "Update & Security" node and check for updates.
4. Reboot after the updates are installed.
Step-by-step instructions
See Deploy hybrid Azure AD joined devices using Intune and Windows Autopilot.
Windows Autopilot Self-Deploying mode

Windows Autopilot self-deploying mode enables a device to be deployed with little to no user interaction. For
devices with an Ethernet connection, no user interaction is required; for devices connected via Wi-fi, no interaction
is required after making the Wi-fi connection (choosing the language, locale, and keyboard, then making a
network connection).
Self-deploying mode joins the device into Azure Active Directory, enrolls the device in Intune (or another MDM
service) leveraging Azure AD for automatic MDM enrollment, and ensures that all policies, applications,
certificates, and networking profiles are provisioned on the device, leveraging the enrollment status page to
prevent access to the desktop until the device is fully provisioned.
NOTE
Self-deploying mode does not support Active Directory Join or Hybrid Azure AD Join. All devices will be joined to Azure
Active Directory.
Self-deploying mode is designed to deploy Windows 10 as a kiosk, digital signage device, or a shared device.
When setting up a kiosk, you can leverage the new Kiosk Browser, an app built on Microsoft Edge that can be used
to create a tailored, MDM-managed browsing experience. When combined with MDM policies to create a local
account and configure it to automatically log on, the complete configuration of the device can be automated. Find
out more about these options by reading simplifying kiosk management for IT with Windows 10. See Set up a
kiosk or digital sign in Intune or other MDM service for additional details.
NOTE
Self-deploying mode does not presently associate a user with the device (since no user ID or password is specified as part of
the process). As a result, some Azure AD and Intune capabilities (such as BitLocker recovery, installation of apps from the
Company Portal, or Conditional Access) may not be available to a user that signs into the device. For more information see
Windows Autopilot scenarios and capabilities and Setting the BitLocker encryption algorithm for Autopilot devices.
Requirements
Because self-deploying mode uses a device’s TPM 2.0 hardware to authenticate the device into an organization’s
Azure AD tenant, devices without TPM 2.0 cannot be used with this mode. The devices must also support TPM
device attestation. (All newly-manufactured Windows devices should meet these requirements.)
IMPORTANT
If you attempt a self-deploying mode deployment on a device that does not have support TPM 2.0 or on a virtual machine,
the process will fail when verifying the device with an 0x800705B4 timeout error (Hyper-V virtual TPMs are not supported).
Also note that Window 10, version 1903 or later is required to use self-deploying mode due to issues with TPM device
attestation in Windows 10, version 1809. Since Windows 10 Enterprise 2019 LTSC is based on Windows 10 version 1809,
self-deploying mode is also not supported on Windows 10 Enterprise 2019 LTSC. See Windows Autopilot known issues to
review other known errors and solutions.
In order to display an organization-specific logo and organization name during the Autopilot process, Azure Active
Directory Company Branding needs to be configured with the images and text that should be displayed. See
Quickstart: Add company branding to your sign-in page in Azure AD for more details.
Step by step
In order to perform a self-deploying mode deployment using Windows Autopilot, the following preparation steps
need to be completed:
Create an Autopilot profile for self-deploying mode with the desired settings. In Microsoft Intune, this mode is
explicitly chosen when creating the profile. (Note that it is not possible to create a profile in the Microsoft Store
for Business or Partner Center for self-deploying mode.)
If using Intune, create a device group in Azure Active Directory and assign the Autopilot profile to that group.
Ensure that the profile has been assigned to the device before attempting to deploy that device.
Boot the device, connecting it to Wi-fi if required, then wait for the provisioning process to complete.
Validation
When performing a self-deploying mode deployment using Windows Autopilot, the following end-user experience
should be observed:
Once connected to a network, the Autopilot profile will be downloaded.
If the Autopilot profile has been configured to automatically configure the language, locale, and keyboard
layout, these OOBE screens should be skipped as long as Ethernet connectivity is available. Otherwise, manual
steps are required:
If multiple languages are preinstalled in Windows 10, the user must pick a language.
The user must pick a locale and a keyboard layout, and optionally a second keyboard layout.
If connected via Ethernet, no network prompt is expected. If no Ethernet connection is available and Wi-fi is
built in, the user needs to connect to a wireless network.
Windows 10 will check for critical OOBE updates, and if any are available they will be automatically installed
(rebooting if required).
The device will join Azure Active Directory.
After joining Azure Active Directory, the device will enroll in Intune (or other configured MDM services).
The enrollment status page will be displayed.
Depending on the device settings deployed, the device will either:
Remain at the logon screen, where any member of the organization can log on by specifying their Azure
AD credentials.
Automatically sign in as a local account, for devices configured as a kiosk or digital signage.
NOTE
Deploying EAS policies using self-deploying mode for kiosk deployments will cause auto-logon functionality to fail.
In case the observed results do not match these expectations, consult the Windows Autopilot Troubleshooting
documentation.
Windows Autopilot Reset
Applies to: Windows 10, version 1709 and later (local reset)
Applies to: Windows 10, version 1809 and later (remote reset)
Windows Autopilot Reset removes personal files, apps, and settings and reapplies a device’s original settings,
maintaining its identity connection to Azure AD and its management connection to Intune so that the device is once
again ready for use. Windows Autopilot Reset takes the device back to a business-ready state, allowing the next
user to sign in and get productive quickly and simply.
The Windows Autopilot Reset process automatically retains information from the existing device:
Set the region, language, and keyboard to the originally-configured values.
Wi-Fi connection details.
Provisioning packages previously applied to the device, as well as a provisioning package present on a USB
drive when the reset process is initiated.
Azure Active Directory device membership and MDM enrollment information.
Windows Autopilot Reset will block the user from accessing the desktop until this information is restored, including
re-applying any provisioning packages. For devices enrolled in an MDM service, Windows Autopilot Reset will also
block until an MDM sync is completed.
When Autopilot reset is used on a device, the device's primary user will be removed. The next user who signs in
after the reset will be set as the primary user.
NOTE
The Autopilot Reset does not support Hybrid Azure AD joined devices.
Scenarios
Windows Autopilot Reset supports two scenarios:
Local reset initiated by IT personnel or other administrators from the organization.
Remote reset initiated remotely by IT personnel via an MDM service such as Microsoft Intune.
Additional requirements and configuration details apply with each scenario; see the detailed links above for more
information.
Reset devices with local Windows Autopilot Reset

Applies to: Windows 10, version 1709 and above
The Intune Service Administrator role is required to perform this task. For more information, see Add users and
grant administrative permission to Intune.
IT admins can perform a local Windows Autopilot Reset to quickly remove personal files, apps, and settings, and
reset Windows 10 devices from the lock screen any time and apply original settings and management enrollment
(Azure Active Directory and device management) so the devices are ready to use. With a local Autopilot Reset,
devices are returned to a fully configured or known IT-approved state.
To enable local Autopilot Reset in Windows 10:
1. Enable the policy for the feature
2. Trigger a reset for each device
Enable local Windows Autopilot Reset
To enable a local Windows Autopilot Reset, the DisableAutomaticReDeploymentCredentials policy must be
configured. This policy is documented in the Policy CSP,
CredentialProviders/DisableAutomaticReDeploymentCredentials . By default, local Windows Autopilot is
disabled. This ensures that a local Autopilot Reset is not triggered by accident.
You can set the policy using one of these methods:
MDM provider
When using Intune, you can create a new device configuration profile, specifying "Windows 10 or later"
for the platform, "Device restrictions" for the profile type, and "General" for the settings category. The
Automatic Redeployment setting should be set to Allow . Deploy this setting to all devices where a
local reset should be permitted.
If you're using an MDM provider other than Intune, check your MDM provider documentation on how to
set this policy.
Windows Configuration Designer
You can use Windows Configuration Designer to set the Runtime settings > Policies >
CredentialProviders > DisableAutomaticReDeploymentCredentials setting to 0 and then create a
provisioning package.
Set up School PCs app
The latest release of the Set up School PCs app supports enabling local Windows Autopilot Reset.
Trigger local Windows Autopilot Reset
Performing a local Windows Autopilot Reset is a two-step process: trigger it and then authenticate. Once you've
done these two steps, you can let the process execute and once it is done, the device is again ready for use.
To trigger a local Autopilot Reset
1. From the Windows device lock screen, enter the keystroke: CTRL + + R.
This will open up a custom login screen for the local Autopilot Reset. The screen serves two purposes:
a. Confirm/verify that the end user has the right to trigger Local Autopilot Reset
b. Notify the user in case a provisioning package, created using Windows Configuration Designer, will be
used as part of the process.
2. Sign in with the admin account credentials. If you created a provisioning package, plug in the USB drive and
trigger the local Autopilot Reset.
Once the local Autopilot Reset is triggered, the reset process starts. Once provisioning is complete, the
device is again ready for use.
Reset devices with remote Windows Autopilot Reset

When performing a remote Windows Autopilot Reset, an MDM service such an Microsoft Intune can be used to
initiate the reset process, avoiding the need for IT staff or other administrators to visit each machine to initiate the
process.
To enable a device for a remote Windows Autopilot Reset, the device must be MDM managed and joined to Azure
AD. This feature is not supported on devices that were enrolled using Autopilot self deploying mode.
Triggering a remote Windows Autopilot Reset
To trigger a remote Windows Autopilot Reset via Intune, follow these steps:
Navigate to Devices tab in the Intune console.
In the All devices view, select the targeted reset devices and then click More to view device actions.
Select Autopilot Reset to kick-off the reset task.
NOTE
The Autopilot Reset option will not be enabled in Microsoft Intune for devices not running Windows 10 build 17672 or
higher.
IMPORTANT
The feature for Autopilot Reset will stay grayed out, unless you reset the device using Autopilot (either using Fresh Reset or
manually sysprep the device).
Once the reset is complete, the device is again ready for use.
Troubleshooting
Windows Autopilot Reset requires that the Windows Recovery Environment (WinRE) is correctly configured and
enabled on the device. If it is not configured and enabled, an error such as
Error code: ERROR_NOT_SUPPORTED (0x80070032) will be reported.
To make sure WinRE is enabled, use the REAgentC.exe tool to run the following command:
reagentc /enable
If Windows Autopilot Reset fails after enabling WinRE, or if you are unable to enable WinRE, please contact
Microsoft Support for assistance.
Windows Autopilot for white glove deployment
Applies to: Windows 10, version 1903

Windows Autopilot helps organizations easily provision new devices by using the preinstalled OEM image and
drivers. This lets end users get their devices business-ready by using a simple process.
Windows Autopilot can also provide a white glove service that helps partners or IT staff pre-provision a fully
configured and business-ready Windows 10 PC. 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 done by IT, partners, or OEMs. The end user simply completes a few necessary settings and policies
and then they can begin using their device.
White glove deployments use Microsoft Intune in Windows 10, version 1903 and later. Such deployments build on
existing Windows Autopilot user-driven scenarios and support user-driven mode scenarios for both Azure Active
Directory joined and Hybrid Azure Active Directory joined devices.
Prerequisites
In addition to Windows Autopilot requirements, Windows Autopilot for white glove deployment also requires:
Windows 10, version 1903 or later.
An Intune subscription.
Physical devices that support TPM 2.0 and device attestation. Virtual machines aren't supported. The white
glove provisioning process uses Windows Autopilot self-deploying capabilities, so TPM 2.0 is required.
Physical devices with Ethernet connectivity. Wi-fi connectivity isn't supported because of the requirement to
choose a language, locale, and keyboard to make that Wi-fi connection. Enforcing this requirement in a pre-
provisioning process could prevent the user from choosing their own language, locale, and keyboard when
they receive the device.
IMPORTANT
Because the OEM or vendor performs the white glove process, this doesn’t require access to an end-user's on-prem domain
infrastructure. This is unlike a typical hybrid Azure AD-joined scenario because rebooting the device is postponed. The device
is resealed before the time when connectivity to a domain controller is expected, and the domain network is contacted when
the device is unboxed on-prem by the end-user.
Preparation
Devices slated for white glove provisioning are registered for Autopilot via the normal registration process.
To be ready to try out Windows Autopilot for white glove deployment, make sure that you can first successfully
use existing Windows Autopilot user-driven scenarios:
User-driven Azure AD join. Make sure that you can deploy devices using Windows Autopilot and join them to
an Azure Active Directory tenant.
User-driven with Hybrid Azure AD join. Make sure that you can deploy devices using Windows Autopilot, join
them to an on-premises Active Directory domain, and register them with Azure Active Directory to enable the
Hybrid Azure AD join features.
If these scenarios can't be completed, Windows Autopilot for white glove deployment will also not succeed since it
builds on top of these scenarios.
Before starting the white glove process in the provisioning service facility, you must configure an additional
Autopilot profile setting by using your Intune account:
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 Win32 or LOB apps will be installed if they meet these two conditions:
configured to install in the device context.
targeted to the user pre-assigned to the Autopilot device.
Make sure not to target both win32 and LOB apps to the same device.
NOTE
Select the language mode as user specified in Autopilot profiles to ensure easy access into white glove provisioning mode.
The white glove technician phase will install all device-targeted apps and any user-targeted, device-context apps that are
targeted to the assigned user. If there is no assigned user, then it will only install the device-targeted apps. 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. The differences are primarily seen by the end user in the
authentication steps.
Technician flow
After the customer or IT Admin has targeted all the apps and settings they want for their devices through Intune,
the white glove technician can begin the white glove process. The technician 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 done 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), don't 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. You can use this code to look up the device in Intune.
You might want to do this to make configuration changes, like assigning a user or adding the device to groups
needed for app or policy targeting.
Note : The QR codes can be scanned using a companion app. The app also configures the device to specify who
it belongs to. An open-source sample of the companion app that integrates with Intune by using the Graph API
has been published to GitHub by the Autopilot team.
Validate the information displayed. If any changes are needed, make the changes 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 appears with information about the device, including the same details presented
previously. For example, Autopilot profile, organization name, assigned user, and QR code. The elapsed time for
the pre-provisioning steps is also provided.
Click Reseal to shut down the device. At that point, the device can be shipped to the end user.
NOTE
Technician Flow inherits behavior from Self-Deploying Mode. Per the Self-Deploying Mode documentation, it uses the
Enrollment Status Page to hold the device in a provisioning state and prevent the user from proceeding to the desktop after
enrollment but before software and configuration is done applying. As such, if Enrollment Status Page is disabled, the reseal
button may appear before software and configuration is done applying letting you proceed to the user flow before
technician flow provisioning is complete. The green screen validates that enrollment was successful, not that the technician
flow is necessarily complete.
If the pre-provisioning process fails:

A red status screen appears with information about the device, including the same details presented previously.
For example, Autopilot profile, organization name, assigned user, and QR code.The elapsed time for the pre-
provisioning steps is also provided.
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, you can deliver to the end
user. The end user will complete the normal Windows Autopilot user-driven process following these steps:
Power on the device.
Select the appropriate language, locale, and keyboard layout.
Connect to a network (if using Wi-Fi). Internet access is always required. If using Hybrid Azure AD Join, there
must also be connectivity to a domain controller.
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 can access the desktop.
Related topics
White glove video
Windows Autopilot Deployment for existing devices

Modern desktop deployment with Windows Autopilot enables you to easily deploy the latest version of Windows
10 to your existing devices. The apps you need for work can be automatically installed. Your work profile is
synchronized, so you can resume working right away.
This topic describes how to convert Windows 7 or Windows 8.1 domain-joined computers to Windows 10 devices
joined to either Azure Active Directory or Active Directory (Hybrid Azure AD Join) by using Windows Autopilot.
NOTE
Windows Autopilot for existing devices only supports user-driven Azure Active Directory and Hybrid Azure AD profiles. Self-
deploying profiles are not supported.
Prerequisites
A currently supported version of Microsoft Endpoint Configuration Manager current branch or technical
preview branch.
The Windows ADK 1803 or later
For more information on Configuration Manager support, see Support for Windows 10 ADK.
Assigned Microsoft Intune Licenses
Azure Active Directory Premium
Windows 10 version 1809 or later imported into Configuration Manager as an Operating System Image
Impor tant : See Known issues if you are using Windows 10 1903 with Configuration Manager’s built-in
Windows Autopilot existing device task sequence template. Currently, one of the steps in this task
sequence must be edited to work properly with Windows 10, version 1903.
Procedures
Configure the Enrollment Status Page (optional)
If desired, you can set up an enrollment status page for Autopilot using Intune.
To enable and configure the enrollment and status page:
1. Open Intune in the Azure portal.
2. Access Intune > Device enrollment > Windows enrollment and Set up an enrollment status page.
3. Access Azure Active Director y > Mobility (MDM and MAM) > Microsoft Intune and Configure
automatic MDM enrollment and configure the MDM user scope for some or all users.
See the following examples.
Create the JSON file
TIP
To run the following commands on a computer running Windows Server 2012/2012 R2 or Windows 7/8.1, you must first
download and install the Windows Management Framework.
1. On an Internet connected Windows PC or server, open an elevated Windows PowerShell command window
2. Enter the following lines to install the necessary modules
Install required modules
Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force

Install-Module AzureAD -Force
Install-Module WindowsAutopilotIntune -Force
Install-Module Microsoft.Graph.Intune -Force
3. Enter the following lines and provide Intune administrative credentials

Be sure that the user account you specify has sufficient administrative rights.
Connect-MSGraph
The user and password for your account will be requested using a standard Azure AD form. Type
your username and password and then click Sign in .
See the following example:
If this is the first time you’ve used the Intune Graph APIs, you’ll also be prompted to enable read and
write permissions for Microsoft Intune PowerShell. To enable these permissions:
Select Consent on behalf or your organization
Click Accept
4. Next, retrieve and display all the Autopilot profiles available in the specified Intune tenant in JSON format:
Retrieve profiles in Autopilot for existing devices JSON format
Get-AutopilotProfile | ConvertTo-AutopilotConfigurationJSON
See the following sample output: (use the horizontal scroll bar at the bottom to view long lines)
PS C:\> Get-AutopilotProfile | ConvertTo-AutopilotConfigurationJSON

{
"CloudAssignedTenantId": "1537de22-988c-4e93-b8a5-83890f34a69b",
"CloudAssignedForcedEnrollment": 1,
"Version": 2049,
"Comment_File": "Profile Autopilot Profile",
"CloudAssignedAadServerData": "{\"ZeroTouchConfig\":
{\"CloudAssignedTenantUpn\":\"\",\"ForcedEnrollment\":1,\"CloudAssignedTenantDomain\":\"M365
x373186.onmicrosoft.com\"}}",
"CloudAssignedTenantDomain": "M365x373186.onmicrosoft.com",
"CloudAssignedDomainJoinMethod": 0,
"CloudAssignedOobeConfig": 28,
"ZtdCorrelationId": "7F9E6025-1E13-45F3-BF82-A3E8C5B59EAC"
}
Each profile is encapsulated within braces { } . In the previous example, a single profile is displayed.
See the following table for a description of properties used in the JSON file.
P RO P ERT Y DESC RIP T IO N
Version (number, optional) The version number that identifies the format of the JSON
file. For Windows 10 1809, the version specified must be
2049.
P RO P ERT Y DESC RIP T IO N
CloudAssignedTenantId (guid, required) The Azure Active Directory tenant ID that should be used.
This is the GUID for the tenant, and can be found in
properties of the tenant. The value should not include
braces.
CloudAssignedTenantDomain (string, required) The Azure Active Directory tenant name that should be
used, for example: tenant.onmicrosoft.com.
CloudAssignedOobeConfig (number, required) This is a bitmap that shows which Autopilot settings were
configured. Values include: SkipCortanaOptIn = 1,
OobeUserNotLocalAdmin = 2, SkipExpressSettings = 4,
SkipOemRegistration = 8, SkipEula = 16
CloudAssignedDomainJoinMethod (number, required) This property specifies whether the device should join
Azure Active Directory or Active Directory (Hybrid Azure
AD Join). Values include: Active AD Join = 0, Hybrid Azure
AD Join = 1
CloudAssignedForcedEnrollment (number, required) Specifies that the device should require AAD Join and
MDM enrollment.
0 = not required, 1 = required.
ZtdCorrelationId (guid, required) A unique GUID (without braces) that will be provided to
Intune as part of the registration process.
ZtdCorrelationId will be included in enrollment message as
“OfflineAutoPilotEnrollmentCorrelator”. This attribute will
be present only if the enrollment is taking place on a
device registered with Zero Touch Provisioning via offline
registration.
CloudAssignedAadServerData (encoded JSON string, An embedded JSON string used for branding. It requires
required) AAD corp branding enabled.
Example value: "CloudAssignedAadServerData": "
{"ZeroTouchConfig":
{"CloudAssignedTenantUpn":"","CloudAssignedTenantDom
ain":"tenant.onmicrosoft.com"}}"
CloudAssignedDeviceName (string, optional) The name automatically assigned to the computer. This
follows the naming pattern convention that can be
configured in Intune as part of the Autopilot profile, or
can specify an explicit name to use.
5. The Autopilot profile must be saved as a JSON file in ASCII or ANSI format. Windows PowerShell defaults to
Unicode format, so if you attempt to redirect output of the commands to a file, you must also specify the file
format. For example, to save the file in ASCII format using Windows PowerShell, you can create a directory
(ex: c:\Autopilot) and save the profile as shown below: (use the horizontal scroll bar at the bottom if needed
to view the entire command string)
Get-AutopilotProfile | ConvertTo-AutopilotConfigurationJSON | Out-File

c:\Autopilot\AutopilotConfigurationFile.json -Encoding ASCII
IMPORTANT : The file name must be named AutopilotConfigurationFile.json in addition to being

encoded as ASCII/ANSI.
If preferred, you can save the profile to a text file and edit in Notepad. In Notepad, when you choose Save
as you must select Save as type: All Files and choose ANSI from the drop-down list next to Encoding . See
the following example.
After saving the file, move the file to a location suitable as a Microsoft Endpoint Configuration Manager
package source.
IMPORTANT
Multiple JSON profile files can be used, but each must be named AutopilotConfigurationFile.json in order for
OOBE to follow the Autopilot experience. The file also must be encoded as ANSI.
Saving the file with Unicode or UTF-8 encoding or saving it with a different file name will cause
Windows 10 OOBE to not follow the Autopilot experience .
Create a package containing the JSON file

1. In Configuration Manager, navigate to \Software Librar y\Over view\Application Management\Packages
2. On the ribbon, click Create Package
3. In the Create Package and Program Wizard enter the following Package and Program Type details:
Name: Autopilot for existing devices config
Select the This package contains source files checkbox
Source folder: Click Browse and specify a UNC path containing the AutopilotConfigurationFile.json file.
Click OK and then click Next .
Program Type: Do not create a program
4. Click Next twice and then click Close .
NOTE : If you change user-driven Autopilot profile settings in Intune at a later date, you must also update the JSON
file and redistribute the associated Configuration Manager package.
Create a target collection
NOTE
You can also choose to reuse an existing collection
1. Navigate to \Assets and Compliance\Over view\Device Collections
2. On the ribbon, click Create and then click Create Device Collection
3. In the Create Device Collection Wizard enter the following General details:
Name: Autopilot for existing devices collection
Comment: (optional)
Limiting collection: Click Browse and select All Systems
NOTE
You can optionally choose to use an alternative collection for the limiting collection. The device to be
upgraded must be running the ConfigMgr agent in the collection that you select.
4. Click Next , then enter the following Membership Rules details:

Click Add Rule and specify either a direct or query based collection rule to add the target test
Windows 7 devices to the new collection.
For example, if the hostname of the computer to be wiped and reloaded is PC-01 and you wish to
use Name as the attribute, click Add Rule > Direct Rule > (wizard opens) > Next and then
enter PC-01 next to Value . Click Next , and then choose PC-01 under Resources . See the following
examples.
5. Continue creating the device collection with the default settings:
Use incremental updates for this collection: not selected
Schedule a full update on this collection: default
Click Next twice and then click Close
Create an Autopilot for existing devices Task Sequence
TIP
The next procedure requires a boot image for Windows 10 1803 or later. Review your available boot images in the
Configuration Manager conole under Software Librar y\Over view\Operating Systems\Boot images and verify that
the OS Version is 10.0.17134.1 (Windows 10 version 1803) or later.
1. In the Configuration Manager console, navigate to \Software Librar y\Over view\Operating

Systems\Task Sequences
2. On the Home ribbon, click Create Task Sequence
3. Select Install an existing image package and then click Next
4. In the Create Task Sequence Wizard enter the following details:
Task sequence name: Autopilot for existing devices
Boot Image: Click Browse and select a Windows 10 boot image (1803 or later)
Click Next , and then on the Install Windows page click Browse and select a Windows 10 Image
package and Image Index , version 1803 or later.
Select the Par tition and format the target computer before installing the operating system
checkbox.
Select or clear Configure task sequence for use with BitLocker checkbox. This is optional.
Product Key and Server licensing mode: Optionally enter a product key and server licensing mode.
Randomly generate the local administrator password and disable the account on all support
platforms (recommended): Optional.
Enable the account and specify the local administrator password: Optional.
Click Next , and then on the Configure Network page choose Join a workgroup and specify a name
(ex: workgroup) next to Workgroup .
IMPORTANT
The Autopilot for existing devices task sequence will run the Prepare Windows for capture action which
uses the System Preparation Tool (sysprep). This action will fail if the target machine is joined to a domain.
IMPORTANT
The System Preparation Tool (sysprep) will run with the /Generalize parameter which, on Windows 10
versions 1903 and 1909, will delete the Autopilot profile file and the machine will boot into OOBE phase
instead of Autopilot phase. To fix this issue, please see Windows Autopilot - known issues.
5. Click Next , and then click Next again to accept the default settings on the Install Configuration Manager
page.
6. On the State Migration page, enter the following details:
Clear the Capture user settings and files checkbox.
Clear the Capture network settings checkbox.
Clear the Capture Microsoft Windows settings checkbox.
Click Next .
NOTE
Because the Autopilot for existing devices task sequence completes while in Windows PE, User State
Migration Toolkit (USMT) data migration is not supported as there is no way to restore the user state into
the new OS. Also, the User State Migration Toolkit (USMT) does not support Azure AD-joined devices.
7. On the Include Updates page, choose one of the three available options. This selection is optional.
8. On the Install applications page, add applications if desired. This is optional.
9. Click Next , confirm settings, click Next , and then click Close .
10. Right click on the Autopilot for existing devices task sequence and click Edit .
11. In the Task Sequence Editor under the Install Operating System group, click the Apply Windows
Settings action.
12. Click Add then click New Group .
13. Change the group Name from New Group to Autopilot for existing devices config .
14. Click Add , point to General , then click Run Command Line .
15. Verify that the Run Command Line step is nested under the Autopilot for existing devices config
group.
16. Change the Name to Apply Autopilot for existing devices config file and paste the following into the
Command line text box, and then click Apply :
cmd.exe /c xcopy AutopilotConfigurationFile.json %OSDTargetSystemDrive%\windows\provisioning\Autopilot\
/c
AutopilotConfigurationFile.json must be the name of the JSON file present in the Autopilot for
existing devices package created earlier.
17. In the Apply Autopilot for existing devices config file step, select the Package checkbox and then
click Browse .
18. Select the Autopilot for existing devices config package created earlier and click OK . An example is
displayed at the end of this section.
19. Under the Setup Operating System group, click the Setup Windows and Configuration Manager
task.
20. Click Add and then click New Group .
21. Change Name from New Group to Prepare Device for Autopilot
22. Verify that the Prepare Device for Autopilot group is the very last step in the task sequence. Use the
Move Down button if necessary.
23. With the Prepare device for Autopilot group selected, click Add , point to Images and then click
Prepare ConfigMgr Client for Capture .
24. Add a second step by clicking Add , pointing to Images , and clicking Prepare Windows for Capture . Use
the following settings in this step:
Automatically build mass storage driver list: Not selected
Do not reset activation flag: Not selected
Shut down the computer after running this action: Optional
25. Click OK to close the Task Sequence Editor.

NOTE
On Windows 10 1903 and 1909, the AutopilotConfigurationFile.json is deleted by the Prepare Windows for
Capture step. See Windows Autopilot - known issues for more information and a workaround.
Deploy Content to Distribution Points

Next, ensure that all content required for the task sequence is deployed to distribution points.
1. Right click on the Autopilot for existing devices task sequence and click Distribute Content .
2. Click Next , Review the content to distribute , and then click Next .
3. On the Specify the content distribution page click Add to specify either a Distribution Point or Distribution
Point Group .
4. On the Add Distribution Points or Add Distribution Point Groups wizard specify content destinations that will
allow the JSON file to be retrieved when the task sequence is run.
5. When you are finished specifying content distribution, click Next twice then click Close .
Deploy the OS with Autopilot Task Sequence
1. Right click on the Autopilot for existing devices task sequence and then click Deploy .
2. In the Deploy Software Wizard enter the following General and Deployment Settings details:
Task Sequence: Autopilot for existing devices .
Collection: Click Browse and then select Autopilot for existing devices collection (or another
collection you prefer).
Click Next to specify Deployment Settings .
Action: Install .
Purpose: Available . You can optionally select Required instead of Available . This is not recommended
during the test owing to the potential impact of inadvertent configurations.
Make available to the following: Only Configuration Manager Clients . Note: Choose the option here
that is relevant for the context of your test. If the target client does not have the Configuration Manager
agent or Windows installed, you will need to select an option that includes PXE or Boot Media.
Click Next to specify Scheduling details.
Schedule when this deployment will become available: Optional
Schedule when this deployment will expire: Optional
Click Next to specify User Experience details.
Show Task Sequence progress: Selected.
Software Installation: Not selected.
System restart (if required to complete the installation): Not selected.
Commit changed at deadline or during a maintenance windows (requires restart): Optional.
Allow task sequence to be run for client on the Internet: Optional
Click Next to specify Aler ts details.
Create a deployment alert when the threshold is higher than the following: Optional.
Click Next to specify Distribution Points details.
Deployment options: Download content locally when needed by the running task sequence .
When no local distribution point is available use a remote distribution point: Optional.
Allow clients to use distribution points from the default site boundary group: Optional.
Click Next , confirm settings, click Next , and then click Close .
Complete the client installation process
1. Open the Software Center on the target Windows 7 or Windows 8.1 client computer. You can do this by
clicking Start and then typing software in the search box, or by typing the following at a Windows
PowerShell or command prompt:
C:\Windows\CCM\SCClient.exe
2. In the software library, select Autopilot for existing devices and click Install . See the following example:
The Task Sequence will download content, reboot, format the drives and install Windows 10. The device will then
proceed to be prepared for Autopilot. Once the task sequence has completed the device will boot into OOBE and
provide an Autopilot experience.
NOTE
If joining devices to Active Directory (Hybrid Azure AD Join), it is necessary to create a Domain Join device configuration
profile that is targeted to "All Devices" (since there is no Azure Active Directory device object for the computer to do group-
based targeting). See User-driven mode for hybrid Azure Active Directory join for more information.
Register the device for Windows Autopilot

Devices provisioned through Autopilot will only receive the guided OOBE Autopilot experience on first boot. Once
updated to Windows 10, the device should be registered to ensure a continued Autopilot experience in the event of
PC reset. You can enable automatic registration for an assigned group using the Conver t all targeted devices
to Autopilot setting. For more information, see Create an Autopilot deployment profile.
Also see Adding devices to Windows Autopilot.
Speeding up the deployment process

To remove around 20 minutes from the deployment process, see Michael Niehaus's blog with instructions for
Speeding up Windows Autopilot for existing devices.
Windows Autopilot software requirements

Windows Autopilot depends on specific features available in Windows 10, Azure Active Directory, and MDM
services, such as Microsoft Intune. To use Windows Autopilot and access these features, some software
requirements must be met.
Note : For a list of OEMs that currently support Windows Autopilot, see the Participant device manufacturers
section at Windows Autopilot.
Software requirements
A supported version of Windows 10 Semi-Annual Channel is required. Windows 10 Enterprise 2019 long-term
servicing channel (LTSC) is also supported.
The following editions are supported:
Windows 10 Pro
Windows 10 Pro Education
Windows 10 Pro for Workstations
Windows 10 Enterprise
Windows 10 Education
Windows 10 Enterprise 2019 LTSC
NOTE
Procedures for deploying Windows Autopilot might refer to specific products and versions. The inclusion of these products in
this content doesn't imply an extension of support for a version that is beyond its support lifecycle. Windows Autopilot does
not support products that are beyond their support lifecycle. For more information, see Microsoft Lifecycle Policy.
Next steps
Windows Autopilot networking requirements
Windows Autopilot networking requirements

Windows Autopilot depends on a variety of internet-based services. Access to these services must be provided for
Autopilot to function properly. In the simplest case, enabling proper functionality can be achieved by ensuring the following
conditions:
Ensure Domain Name Services (DNS) name resolution for internet DNS names
Allow access to all hosts via port 80 (HTTP), 443 (HTTPS), and 123 (UDP/NTP)
Additional configuration may be required to grant access to required services in environments that:
have more restrictive Internet access.
require authentication before internet access can be obtained.
NOTE
Smart card and certificate based authentication isn't supported during OOBE. For more information, see Smartcards and certificate-
based authentication.
For additional details about each of these services and their specific requirements, review the following details:
SERVIC E IN F O RM AT IO N
Windows Autopilot Deployment Ser vice After a network connection is in place, each Windows 10 device will
contact the Windows Autopilot Deployment Service. With
Windows 10 version 1903 and above, the following URLs are used:
https://ztd.dds.microsoft.com, https://cs.dds.microsoft.com.
Windows Activation Windows Autopilot requires Windows Activation services. For

details about the URLs that need to be accessible for the activation
services, see Windows activation or validation fails with error code
0x8004FE33.
Azure Active Director y User credentials are validated by Azure Active Directory, and the
device can also be joined to Azure Active Directory. For more
information, see Office 365 IP Address and URL Web service.
Intune Once authenticated, Azure Active Directory will trigger enrollment

of the device into the Intune mobile device management (MDM)
service. See the following link for details about network
communication requirements: Intune network configuration
requirements and bandwidth.
Windows Update During the OOBE process and after the Windows 10 OS
configuration, the Windows Update service retrieves needed
updates. If there are problems connecting to Windows Update, see
How to solve connection problems concerning Windows Update or
Microsoft Update.
If Windows Update is inaccessible, the Autopilot process will
still continue but critical updates won't be available.
Deliver y Optimization Autopilot contacts the Delivery Optimization service when
downloading the apps and updates. This contact establishes peer-
to-peer sharing of content so that only a few devices need to
download it from the Internet. - Windows Updates - Microsoft
Store apps and app updates - Office Updates - Intune Win32 Apps
If the Delivery Optimization Service is inaccessible, the
Autopilot process will still continue with Delivery Optimization
downloads from the cloud (without peer-to-peer).
Network Time Protocol (NTP) Sync When a Windows device starts up, it will talk to a network time
server to ensure that the time on the device is correct. Ensure that
UDP port 123 to time.windows.com is accessible.
Domain Name Ser vices (DNS) To resolve DNS names for all services, the device communicates
with a DNS server, typically provided via DHCP. This DNS server
must be able to resolve internet names.
Diagnostics data Starting in Windows 10, 1903, diagnostic data collection will be
enabled by default. To disable Windows Analytics and related
diagnostics capabilities, see Manage enterprise diagnostic data
level.
If diagnostic data can't be sent, the Autopilot process still
continues. However, services that depend on diagnostic data,
such as Windows Analytics, won't work.
Network Connection Status Indicator (NCSI) Windows must be able to tell that the device can access the
internet. For more information, see Network Connection Status
Indicator (NCSI).
www.msftconnecttest.com must be resolvable via DNS and
accessible via HTTP.
Windows Notification Ser vices (WNS) This service is used to enable Windows to receive notifications
from apps and services. For more information, see Microsoft Store.
If the WNS services aren't available, the Autopilot process will
still continue without notifications.
Microsoft Store, Microsoft Store for Business Apps in the Microsoft Store can be pushed to the device, triggered
via Intune (MDM). App updates and additional apps may also be
needed when the user first logs in. For more information, see
Prerequisites for Microsoft Store for Business and Education (also
includes Azure AD and Windows Notification Services).
If the Microsoft Store isn't accessible, the Autopilot process will
still continue without Microsoft Store apps.
Microsoft 365 As part of the Intune device configuration, installation of Microsoft

365 Apps for enterprise may be required. For more information,
see Office 365 URLs and IP address ranges. This article includes all
Office services, DNS names, IP addresses. It also includes Azure AD
and other services that may overlap with the services listed above.
Cer tificate revocation lists (CRLs) Some of these services will also need to check certificate revocation
lists (CRLs) for certificates used in the services. For a full list, see
Office 365 URLs and IP address ranges and Office 365 Certificate
Chains.
Hybrid Azure AD join The device can be hybrid Azure AD joined. The computer should be
on corporate network for hybrid Azure AD join to work. See details
at Windows Autopilot user-driven mode
Autopilot Self-Deploying mode and Autopilot White Firmware TPM devices, which are only provided by Intel, AMD, or
Glove Qualcomm, don't include all needed certificates at boot time and
must be able to retrieve them from the manufacturer on first use.
Devices with discrete TPM chips (including devices from any other
manufacturer) come with these certificates preinstalled. For more
information, see TPM recommendations. For each firmware TPM
provider, make sure that these URLs are accessible so that
certificates can be successfully requested:
Intel- https://ekop.intel.com/ekcertservice
Qualcomm-
https://ekcert.spserv.microsoft.com/EKCertificate/GetEKCertificate/v1
AMD- https://ftpm.amd.com/pki/aia
Next steps
Windows Autopilot licensing requirements
Windows Autopilot licensing requirements

Windows Autopilot depends on specific capabilities available in Windows 10 and Azure Active Directory. It also
requires an MDM service such as Microsoft Intune. These capabilities can be obtained through various editions and
subscription programs:
To provide needed Azure Active Directory (automatic MDM enrollment and company branding features) and MDM
functionality, one of the following subscriptions is required:
Microsoft 365 Business Premium subscription
Microsoft 365 F1 or F3 subscription
Microsoft 365 Academic A1, A3, or A5 subscription
Microsoft 365 Enterprise E3 or E5 subscription, which include all Windows 10, Microsoft 365, and EM+S
features (Azure AD and Intune).
Enterprise Mobility + Security E3 or E5 subscription, which include all needed Azure AD and Intune features.
Intune for Education subscription, which include all needed Azure AD and Intune features.
Azure Active Directory Premium P1 or P2 and Microsoft Intune subscription (or an alternative MDM service).
NOTE
Even when using Microsoft 365 subscriptions, you still need to assign Intune licenses to the users.
Additionally, the following are also recommended (but not required):

Microsoft 365 Apps for enterprise, which can be deployed easily via Intune (or other MDM services).
Windows Subscription Activation, to automatically step up devices from Windows 10 Pro to Windows 10
Enterprise.
Next steps
Windows Autopilot configuration requirements
Windows Autopilot configuration requirements

Before Windows Autopilot can be used, some configuration tasks are required to support the common Autopilot
scenarios.
Configure Azure Active Directory automatic enrollment. For Microsoft Intune, see Enable Windows 10
automatic enrollment for details. If using a different MDM service, contact the vendor for the specific URLs or
configuration needed for those services.
Configure Azure Active Directory custom branding. To display an organization-specific logon page, you must
configure Azure Active Directory with the images and text that you want to be displayed. For more information,
see Quickstart: Add company branding to your sign-in page in Azure AD. Key elements for Autopilot include
the "square logo", "sign-in page text", and Azure Active Directory tenant name. The tenant name is configured
separately in the Azure AD tenant properties.
Optional: To automatically step up from Windows 10 Pro to Windows 10 Enterprise, enable Windows
Subscription Activation.
Specific scenarios will then have additional requirements. Generally, there are two specific tasks:
Device registration. Devices must be added to Windows Autopilot to support most Windows Autopilot
scenarios. For more information, see Adding devices to Windows Autopilot.
Profile configuration. Once devices have been added to Windows Autopilot, a profile of settings needs to be
applied to each device. See Configure Autopilot profiles for details. Microsoft Intune can automate this profile
assignment. For more information, see Create an Autopilot device group and Assign an Autopilot deployment
profile to a device group.
For more information, see Windows Autopilot Scenarios.
For a walkthrough for some of these and related steps, see this video:
https://www.youtube.com/embed/KYVptkpsOqs
There are no additional hardware requirements to use Windows 10 Autopilot, beyond the requirements to run
Windows 10.
Next steps
Overview of Windows Autopilot
Adding devices to Windows Autopilot
Applies to
Windows 10
Before deploying a device using Windows Autopilot, the device must be registered with the Windows Autopilot
deployment service. Ideally, this registration is performed by the OEM, reseller, or distributor from which the
devices were purchased. However, the registration can also be done within your organization by collecting the
hardware identity and uploading it manually.
OEM registration
When you purchase devices from an OEM, that OEM can automatically register the devices with the Windows
Autopilot. For the list of OEMs that support registration, see the "Participant device manufacturers and resellers"
section of the Windows Autopilot page.
Before an OEM can register devices for an organization, the organization must grant the OEM permission to do so.
The OEM starts this process, with approval granted by an Azure AD global administrator from the organization.
See the "Customer Consent" section of the Customer consent page.
NOTE
While the hardware hashes (also known as hardware IDs) are generated as part of the OEM device manufacturing process,
these should not be provided directly to customers or CSP partners. Instead, the OEM should register devices on the
customer's behalf. In cases where devices are being registered by CSP partners, OEMs may provide PKID information to
those partners to support the device registration process.
Reseller, distributor, or partner registration

Customers may purchase devices from resellers, distributors, or other partners. As long as these resellers,
distributors, and partners are part of the Cloud Solution Partners (CSP) program, they too can register devices for
the customer.
As with OEMs, CSP partners must be granted permission to register devices for an organization. You can use the
process described on the Customer consent page. The CSP partner requests a relationship with the organization.
That organization's global administrator approves the request. After the approval, CSP partners add devices using
Partner Center, either directly through the web site or via available APIs that can automate the same tasks.
Windows Autopilot doesn't require delegated administrator permissions when establishing the relationship
between the CSP partner and the organization. As part of the global administrator's approval process, they can
choose to uncheck the "Include delegated administration permissions" checkbox.
NOTE
While resellers, distributors, or partners could boot each new Windows device to obtain the hardware hash (for purposes of
providing them to customers or direct registration by the partner), this isn't recommended. Instead, these partners should
register devices using the PKID information obtained from the device packaging (barcode) or obtained electronically from
the OEM or upstream partner (e.g. distributor).
Automatic registration of existing devices
You can automatically register an existing device if it's:
running a supported version of Windows 10 semi-annual channel
enrolled in an MDM service such an Intune.
For devices that meet both these requirements, the MDM service can ask the device for the hardware hash. After it
has that, it can automatically register the device with Windows Autopilot. For instructions on how to do this with
Microsoft Intune, see Create an Autopilot deployment profile documentation describing the "Convert all targeted
devices to Autopilot" setting.
You can automatically convert such devices to Windows using Intune's Conver t all targeted devices to
Autopilot setting. For more information, see Create an Autopilot deployment profile.
When using the Windows Autopilot for existing devices scenario, you don't need to pre-register the devices with
Windows Autopilot. Instead, a configuration file (AutopilotConfigurationFile.json) containing all the Windows
Autopilot profile settings is used. The device can then be registered with Windows Autopilot using the same
"Convert all targeted devices to Autopilot" setting.
Manual registration
To manually register a device, you must first capture its hardware hash. Once this process has completed, the
resulting hardware hash can be uploaded to the Windows Autopilot service. Because this process requires booting
the device into Windows 10 to obtain the hardware hash, manual registration is intended primarily for testing and
evaluation scenarios.
NOTE
Customers can only register devices with a hardware hash. Other methods (PKID, tuple) are available through OEMs or CSP
partners as described in the previous sections.
Device identification
To identify a device with Windows Autopilot, the device's unique hardware hash must be captured and uploaded to
the service. This step is ideally done by the hardware vendor (OEM, reseller, or distributor) automatically
associating the device with an organization. It's also possible to do identify a device with a harvesting process that
collects the device from within a running Windows 10 installation.
The hardware hash contains details about the device:
manufacturer
model
device serial number
hard drive serial number
details about when the ID was generated
many other attributes that can be used to uniquely identify the device
The hardware hash changes each time it's generated because it includes details about when it was generated.
When the Windows Autopilot deployment service attempts to match a device, it considers changes like that. It also
considers large changes such as a new hard drive, and is still able to match successfully. But large changes to the
hardware, such as a motherboard replacement, wouldn't match, so a new hash would need to be generated and
uploaded.
Collecting the hardware hash from existing devices using Microsoft Endpoint Configuration Manager
Microsoft Endpoint Configuration Manager automatically collects the hardware hashes for existing Windows 10
devices. For more information, see Gather information from Configuration Manager for Windows Autopilot. You
can extract the hash information from Configuration Manager into a CSV file.
NOTE
Before uploading the CSV file on Intune, please make sure that the first row contains the device serial number, Windows
product ID, hardware hash, group tag, and assigned user. If there is header information on the top of CSV file, please delete
that header information. See details at Enroll Windows devices in Intune.
Collecting the hardware hash from existing devices using PowerShell

The hardware hash for an existing device is available through Windows Management Instrumentation (WMI), as
long as that device is running a supported version of Windows 10 semi-annual channel. You can use a PowerShell
script (Get-WindowsAutoPilotInfo.ps1) to get a device's hardware hash and serial number. The serial number is
useful to quickly see which device the hardware hash belongs to.
To use this script, you can use either of the following methods:
download it from the PowerShell Gallery and run it on each computer.
install it directly from the PowerShell Gallery.
To install it directly and capture the hardware hash from the local computer, use the following commands from an
elevated Windows PowerShell prompt:
md c:\\HWID
Set-Location c:\\HWID
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Unrestricted
Install-Script -Name Get-WindowsAutoPilotInfo
Get-WindowsAutoPilotInfo.ps1 -OutputFile AutoPilotHWID.csv
You can run the commands remotely if both of the following are true:
WMI permissions are in place
WMI is accessible through the Windows Firewall on the remote computer.
For more information about running the script, see the Get-WindowsAutoPilotInfo script’s help by using “Get-Help
Get-WindowsAutoPilotInfo.ps1”.
IMPORTANT
Do not connect devices to the Internet prior to capturing the hardware hash and creating an Autopilot device profile. This
includes collecting the hardware hash, uploading the .CSV into MSfB or Intune, assigning the profile, and confirming the
profile assignment. Connecting the device to the Internet before this process is complete will result in the device
downloading a blank profile that is stored on the device until it's explicity removed. In Windows 10 version 1809, you can
clear the cached profile by restarting OOBE. In previous versions, the only way to clear the stored profile is to re-install the
OS, reimage the PC, or run sysprep /generalize /oobe .
After Intune reports the profile ready to go, only then should the device be connected to the Internet.
NOTE
If OOBE is restarted too many times it can enter a recovery mode and fail to run the Autopilot configuration. You can
identify this scenario if OOBE displays multiple configuration options on the same page, including language, region, and
keyboard layout. The normal OOBE displays each of these on a separate page. The following value key tracks the count of
OOBE retries:
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\UserOOBE
To ensure OOBE has not been restarted too many times, you can change this value to 1.
Registering devices
After the hardware hashes have been captured from existing devices, they can be uploaded in any of the following
ways:
Microsoft Intune. This is the preferred mechanism for all customers.
The Microsoft Endpoint Manager admin center is used for Intune device enrollment.
Partner Center. This is used by CSP partners to register devices on behalf of customers.
Microsoft 365 Business & Office 365 Admin. This is typically used by small and medium businesses (SMBs)
who manage their devices using Microsoft 365 Business.
Microsoft Store for Business. You might already be using MSfB to manage your apps and settings.
A summary of each platform's capabilities is provided below.
Platform/Por tal Register devices? Create/Assign profile Acceptable DeviceID
OEM Direct API YES - 1000 at a time max NO Tuple or PKID
Partner Center YES - 1000 at a time max YES3 4 Tuple or PKID or 4K HH
Intune YES - 500 at a time max1 YES1 2 4K HH
Microsoft Store for Business YES - 1000 at a time max YES4 4K HH
Microsoft 365 Business YES - 1000 at a time max YES3 4K HH

Premium
1 Microsoft recommended platform to use

2 Intune license required
3 Feature capabilities are limited
4 Device profile assignment will be retired from MSfB and Partner Center in the coming months
For more information about device IDs, see the following topics:
Device identification
Windows Autopilot device guidelines
Add devices to a customer account
Summary
When deploying new devices using Windows Autopilot, the following steps are required:
1. Register devices. Ideally, this step is performed by the OEM, reseller, or distributor from which the devices were
purchased. However, registration can also be done by the organization by collecting the hardware identity and
uploading it manually.
2. Configure device profiles. Specify how the device should be deployed and what user experience should be
presented.
3. Boot the device. IF the device is connected to a network with internet access, it will contact the Windows
Autopilot deployment service to see if the device is registered. If it's registered, it will download profile settings
such as the Enrollment Status page, which are used to customize the end-user experience.
Next steps
BitLocker encryption settings: You can configure the BitLocker encryption settings to be applied before automatic
encryption is started.
Enroll Windows devices in Intune by using Windows
Autopilot
The Windows Autopilot simplifies enrolling devices in Intune. Building and maintaining customized operating
system images is a time-consuming process. You might also spend time applying these custom operating system
images to new devices to prepare them for use before giving them to your end users. With Microsoft Intune and
Autopilot, you can give new devices to your end users without the need to build, maintain, and apply custom
operating system images to the devices. When you use Intune to manage Autopilot devices, you can manage
policies, profiles, apps, and more after they're enrolled. For an overview of benefits, scenarios, and prerequisites,
see Overview of Windows Autopilot.
There are four types of Autopilot deployment:
Self Deploying Mode for kiosks, digital signage, or a shared device
White Glove enables partners or IT staff to pre-provision a Windows 10 PC so that it's fully configured and
business-ready
Autopilot for existing devices enables you to easily deploy the latest version of Windows 10 to your existing
devices
User Driven Mode for traditional users.
This article explains how to set up Autopilot for Windows PC. For more information about Autopilot and Hololens,
see Windows Autopilot for HoloLens 2.
Prerequisites
Intune subscription
Windows automatic enrollment enabled
Azure Active Directory Premium subscription
How to get the CSV for Import in Intune

For more information, see the understanding PowerShell cmdlet.
Get-WindowsAutoPilotInfo
Add devices
You can add Windows Autopilot devices by importing a CSV file with their information.
1. In the Microsoft Endpoint Manager admin center, choose Devices > Windows > Windows enrollment >
Devices (under Windows Autopilot Deployment Program > Impor t .
2. Under Add Windows Autopilot devices , browse to a CSV file listing the devices that you want to add.
The CSV file should list the serial numbers, Windows product IDs, hardware hashes, optional group tags,
and optional assigned user. You can have up to 500 rows in the list. For information about how to get device
information, see Adding devices to Windows Autopilot. Use the header and line format shown below:
Device Serial Number,Windows Product ID,Hardware Hash,Group Tag,Assigned User
<serialNumber>,<ProductID>,<hardwareHash>,<optionalGroupTag>,<optionalAssignedUser>
IMPORTANT
When you use CSV upload to assign a user, make sure that you assign valid UPNs. If you assign an invalid UPN
(incorrect username), your device may be inaccessible until you remove the invalid assignment. During CSV upload
the only validation we perform on the Assigned User column is to check that the domain name is valid. We're
unable to perform individual UPN validation to ensure that you're assigning an existing or correct user.
3. Choose Impor t to start importing the device information. Importing can take several minutes.
4. After import is complete, choose Devices > Windows > Windows enrollment > Devices (under
Windows Autopilot Deployment Program > Sync . A message displays that the synchronization is in
progress. The process might take a few minutes to complete, depending on how many devices are being
synchronized.
5. Refresh the view to see the new devices.
Create an Autopilot device group

1. In the Microsoft Endpoint Manager admin center, choose Groups > New group .
2. In the Group blade:
a. For Group type , choose Security .
b. Type a Group name and Group description .
c. For Membership type , choose either Assigned or Dynamic Device .
3. If you chose Assigned for Membership type in the previous step, then in the Group blade, choose
Members and add Autopilot devices to the group. Autopilot devices that aren't yet enrolled are devices
where the name equals the serial number of the device.
4. If you chose Dynamic Devices for Membership type above, then in the Group blade, choose Dynamic
device members and type any of the following code in the Advanced rule box. Only Autopilot devices
are gathered by these rules, because they target attributes that are only possessed by Autopilot devices.
Creating a group based off non-autopilot attributes won't guarantee that devices included in the group are
actually registered to Autopilot.
If you want to create a group that includes all of your Autopilot devices, type:
(device.devicePhysicalIDs -any (_ -contains "[ZTDId]"))
Intune's group tag field maps to the OrderID attribute on Azure AD devices. If you want to create a group
that includes all of your Autopilot devices with a specific group tag (the Azure AD device OrderID), you
must type: (device.devicePhysicalIds -any (_ -eq "[OrderID]:179887111881"))
If you want to create a group that includes all of your Autopilot devices with a specific Purchase Order ID,
type: (device.devicePhysicalIds -any (_ -eq "[PurchaseOrderId]:76222342342"))
After adding the Advanced rule code, choose Save .
5. Choose Create .
Create an Autopilot deployment profile

Autopilot deployment profiles are used to configure the Autopilot devices. You can create up to 350 profiles per
tenant.
Deployment Profiles > Create Profile > Windows PC or HoloLens . This article explains how to set up
Autopilot for Windows PC. For more information about Autopilot and Hololens, see Windows Autopilot for
HoloLens 2.
2. On the Basics page, type a Name and optional Description .
3. If you want all devices in the assigned groups to automatically convert to Autopilot, set Conver t all
targeted devices to Autopilot to Yes . All corporate owned, non-Autopilot devices in assigned groups will
register with the Autopilot deployment service. Personally owned devices will not be converted to Autopilot.
Allow 48 hours for the registration to be processed. When the device is unenrolled and reset, Autopilot will
enroll it. After a device is registered in this way, disabling this option or removing the profile assignment
won't remove the device from the Autopilot deployment service. You must instead remove the device
directly.
4. Select Next .
5. On the Out-of-box experience (OOBE) page, for Deployment mode , choose one of these two options:
User-driven : Devices with this profile are associated with the user enrolling the device. User credentials
are required to enroll the device.
Self-deploying (preview) : (requires Windows 10, version 1809 or later) Devices with this profile aren't
associated with the user enrolling the device. User credentials aren't required to enroll the device. When
a device has no user associated with it, user-based compliance policies don't apply to it. When using self-
deploying mode, only compliance policies targeting the device will be applied.
NOTE
Options that appear dimmed or shaded are currently not supported by the selected deployment mode.
6. In the Join to Azure AD as box, choose Azure AD joined .

7. Configure the following options:
End-user license agreement (EUL A) : (Windows 10, version 1709 or later) Choose if you want to
show the EULA to users.
Privacy settings : Choose if you want to show privacy settings to users.
IMPORTANT
The default value for the Diagnostic Data setting varies between Windows versions. For devices running Windows 10,
version 1903, the default value is set to Full during the out-of-box experience. For more information, see Windows
Diagnostics Data
Hide change account options (requires Windows 10, version 1809 or later) : Choose Hide to
prevent change account options from displaying on the company sign-in and domain error pages. This
option requires company branding to be configured in Azure Active Directory.
User account type : Choose the user's account type (Administrator or Standard user). We allow the
user joining the device to be a local Administrator by adding them to the local Admin group. We don't
enable the user as the default administrator on the device.
Allow White Glove OOBE (requires Windows 10, version 1903 or later; additional physical
requirements): Choose Yes to allow white glove support.
Apply device name template (requires Windows 10, version 1809 or later, and Azure AD join type):
Choose Yes to create a template to use when naming a device during enrollment. Names must be 15
characters or less, and can have letters, numbers, and hyphens. Names can't be all numbers. Use the
%SERIAL% macro to add a hardware-specific serial number. Or, use the %RAND:x% macro to add a
random string of numbers, where x equals the number of digits to add. You can only provide a pre-fix for
hybrid devices in a domain join profile.
Language (Region) *: Choose the language to use for the device. This option is only available if you
chose Self-deploying for Deployment mode .
Automatically configure keyboard *: If a Language (Region) is selected, choose Yes to skip the
keyboard selection page. This option is only available if you chose Self-deploying for Deployment
mode .
8. Select Next .
9. On the Scope tags page, optionally add the scope tags you want to apply to this profile. For more
information about scope tags, see Use role-based access control and scope tags for distributed IT.
10. Select Next .
11. On the Assignments page, choose Selected groups for Assign to .
12. Choose Select groups to include , and choose the groups you want to include in this profile.
13. If you want to exclude any groups, choose Select groups to exclude , and choose the groups you want to
exclude.
14. Select Next .
15. On the Review + Create page, choose Create to create the profile.
NOTE
Intune will periodically check for new devices in the assigned groups, and then begin the process of assigning profiles to
those devices. This process can take several minutes to complete. Before deploying a device, ensure that this process has
completed. You can check under Devices > Windows > Windows enrollment > Devices (under Windows Autopilot
Deployment Program where you should see the profile status change from "Unassigned" to "Assigning" and finally to
"Assigned."
Edit an Autopilot deployment profile

After you've created an Autopilot deployment profile, you can edit certain parts of the deployment profile.
Deployment profiles .
2. Select the profile you would like to edit.
3. Select Proper ties on the left to change the name or description of the deployment profile. Click Save after you
make changes.
4. Click Settings to make changes to the OOBE settings. Click Save after you make changes.
NOTE
Changes to the profile are applied to devices assigned to that profile. However, the updated profile won't be applied to a
device that has already enrolled in Intune until after the device is reset and reenrolled.
Edit Autopilot device attributes

After you've uploaded an Autopilot device, you can edit certain attributes of the device.
1. In the Microsoft Endpoint Manager admin center,select Devices > Windows > Windows enrollment >
Devices (under Windows Autopilot Deployment Program .
2. Select the device you want to edit.
3. In the pane on the right of the screen, you can edit the device name, group tag, or User Friendly Name (if you've
assigned a user).
4. Select Save .
NOTE
Device names can be configured for all devices, but are ignored in Hybrid Azure AD joined deployments. Device name still
comes from the domain join profile for Hybrid Azure AD devices.
Alerts for Windows Autopilot unassigned devices

Alerts will show how many Autopilot program devices don't have Autopilot deployment profiles. Use the
information in the alert to create profiles and assign them to the unassigned devices. When you click the alert, you
see a full list of Windows Autopilot devices and detailed information about them.
To see alerts for unassigned devices, in the Microsoft Endpoint Manager admin center, choose Devices >
Over view > Enrollment aler ts > Unassigned devices .
Autopilot deployments report

You can see details on each device deployed through Windows Autopilot. To see the report, go to the Microsoft
Endpoint Manager admin center, choose Devices > Monitor > Autopilot deployments . The data is available for
30 days after deployment.
This report is in preview. Device deployment records are currently triggered only by new Intune enrollment events.
This means that any deployment that doesn't trigger a new Intune enrollment will not be picked up by this report.
This includes any kind of reset that maintains enrollment and the user portion of Autopilot White glove.
Assign a user to a specific Autopilot device

You can assign a user to a specific Autopilot device. This assignment pre-fills a user from Azure Active Directory in
the company-branded sign-in page during Windows setup. It also lets you set a custom greeting name. It doesn't
pre-fill or modify Windows sign-in. Only licensed Intune users can be assigned in this manner.
Prerequisites: Azure Active Directory Company Portal has been configured and Windows 10, version 1809 or later.
NOTE
Assigning a user to a specific Autopilot device doesn't work if you are using ADFS.
Devices (under Windows Autopilot Deployment Program > choose the device > Assign user .
2. Choose an Azure user licensed to use Intune and choose Select .
3. In the User Friendly Name box, type a friendly name or just accept the default. This string is the friendly
name that displays when the user signs in during Windows setup.
4. Choose Ok .
Delete Autopilot devices

You can delete Windows Autopilot devices that aren't enrolled into Intune:
Delete the devices from Windows Autopilot at Devices > Windows > Windows enrollment > Devices
(under Windows Autopilot Deployment Program . Choose the devices you want to delete, then choose
Delete . Windows Autopilot device deletion can take a few minutes to complete.
Completely removing a device from your tenant requires you to delete the Intune device, the Azure Active
Directory device, and the Windows Autopilot device records. This can all be done from Intune:
1. If the devices are enrolled in Intune, you must first delete them from the Intune All devices blade.
2. Delete the devices in Azure Active Directory devices at Devices > Azure AD devices .
3. Delete the devices from Windows Autopilot at Devices > Windows > Windows enrollment > Devices
(under Windows Autopilot Deployment Program >. Choose the devices you want to delete, then
choose Delete . Windows Autopilot device deletion can take a few minutes to complete.
Using Autopilot in other portals

If you aren't interested in mobile device management, you can use Autopilot in other portals. While using other
portals is an option, we recommend you only use Intune to manage your Autopilot deployments. When you use
Intune and another portal, Intune isn't able to:
Display changes to profiles created in Intune, but edited in another portal
Synchronize profiles created in another portal
Display changes to profile assignments done in another portal
Synchronize profile assignments done in another portal
Display changes to the device list that were made in another portal
Windows Autopilot for existing devices

You can group Windows devices by a correlator ID when enrolling using Autopilot for existing devices through
Configuration Manager. The correlator ID is a parameter of the Autopilot configuration file. The Azure AD device
attribute enrollmentProfileName is automatically set to equal "OfflineAutopilotprofile-<correlator ID>". This allows
arbitrary Azure AD dynamic groups to be created based off correlator ID by using the enrollmentprofileName
attribute.
WARNING
Because the correlator ID is not pre-listed in Intune, the device may report any correlator ID they want. If the user creates a
correlator ID matching an Autopilot or Apple ADE profile name, the device will be added to any dynamic Azure AD device
group based off the enrollmentProfileName attribute. To avoid this conflict:
Always create dynamic group rules matching against the entire enrollmentProfileName value
Never name Autopilot or Apple ADE profiles beginning with "OfflineAutopilotprofile-".
Next steps
After you configure Windows Autopilot for registered Windows 10 devices, learn how to manage those devices.
For more information, see What is Microsoft Intune device management?
Deploy hybrid Azure AD-joined devices by using
Intune and Windows Autopilot
You can use Intune and Windows Autopilot to set up hybrid Azure Active Directory (Azure AD)-joined devices. To do
so, follow the steps in this article.
Prerequisites
Successfully configure your hybrid Azure AD-joined devices. Be sure to verify your device registration by using the
Get-MsolDevice cmdlet.
The devices to be enrolled must also:
Be running Windows 10 v1809 or greater.
Have access to the internet following the documented Windows Autopilot network requirements.
Have access to an Active Directory domain controller, so it must be connected to the organization's network
(where it can resolve the DNS records for the AD domain and the AD domain controller, and communicate with
the domain controller to authenticate the user.
Be able to ping the domain controller of the domain you are trying to join.
If using Proxy, WPAD Proxy settings option must be enabled and configured.
Undergo the out-of-box experience (OOBE).
Use an authorization type that Azure Active Directory supports in OOBE.
Set up Windows 10 automatic enrollment

1. Sign in to Azure, in the left pane, select Azure Active Director y > Mobility (MDM and MAM) >
Microsoft Intune .
2. Make sure that the users who deploy Azure AD-joined devices by using Intune and Windows are members
of a group that's included in your MDM User scope .
3. Use the default values in the MDM Terms of use URL , MDM Discover y URL , and MDM Compliance
URL boxes, and then select Save .
Increase the computer account limit in the Organizational Unit

The Intune Connector for your Active Directory creates autopilot-enrolled computers in the on-premises Active
Directory domain. The computer that hosts the Intune Connector must have the rights to create the computer
objects within the domain.
In some domains, computers are not granted the rights to create computers. Additionally, domains have a built-in
limit (default of 10) that applies to all users and computers that aren't delegated rights to create computer objects.
Therefore, the rights need to be delegated to computers that host the Intune Connector on the organizational unit
where hybrid Azure AD-joined devices are created.
The organizational unit that's granted the rights to create computers must match:
The organizational unit that's entered in the Domain Join profile.
If no profile is selected, the computer's domain name for your domain.
1. Open Active Director y Users and Computers (DSA.msc) .
2. Right-click the organizational unit that you'll use to create hybrid Azure AD-joined computers, and then
select Delegate Control .
3. In the Delegation of Control wizard, select Next > Add > Object Types .
4. In the Object Types pane, select the Computers check box, and then select OK .
5. In the Select Users, Computers, or Groups pane, in the Enter the object names to select box, enter
the name of the computer where the Connector is installed.
6. Select Check Names to validate your entry, select OK , and then select Next .
7. Select Create a custom task to delegate > Next .
8. Select the Only the following objects in the folder check box, and then select the Computer objects ,
Create selected objects in this folder , and Delete selected objects in this folder check boxes.
9. Select Next .
10. Under Permissions , select the Full Control check box.
This action selects all the other options.
11. Select Next , and then select Finish .
Install the Intune Connector

The Intune Connector for Active Directory must be installed on a computer that's running Windows Server 2016 or
later. The computer must also have access to the internet and your Active Directory. To increase scale and
availability, you can install multiple connectors in your environment. We recommend installing the Connector on a
server that's not running any other Intune connectors. Note that each connector must be able to create computer
objects in any domain that you wish to support.
NOTE
If your organization has multiple domains and you install multiple Intune Connectors, you must use a service account that's
able to create computer objects in all domains, even if you plan to implement hybrid Azure AD join only for a specific domain.
If these are untrusted domains, you must uninstall the connectors from domains in which you don't want to use Windows
Autopilot. Otherwise, with multiple connectors across multiple domains, all connectors must be able to create computer
objects in all domains.
The Intune Connector requires the same endpoints as Intune.

1. Turn off IE Enhanced Security Configuration. By default Windows Server has Internet Explorer Enhanced Security
Configuration turned on. If you're unable to sign in to the Intune Connector for Active Directory then turn off IE
Enhanced Security Configuration for the Administrator. How To Turn Off Internet Explorer Enhanced Security
Configuration.
2. In the Microsoft Endpoint Manager admin center, select Devices > Windows > Windows enrollment >
Intune Connector for Active Director y > Add .
3. Follow the instructions to download the Connector.
4. Open the downloaded Connector setup file, ODJConnectorBootstrapper.exe, to install the Connector.
5. At the end of the setup, select Configure .
6. Select Sign In .
7. Enter the user Global Administrator or Intune Administrator role credentials.
The user account must have an assigned Intune license.
8. Go to Devices > Windows > Windows enrollment > Intune Connector for Active Director y , and then
confirm that the connection status is Active .
NOTE
After you sign in to the Connector, it might take a couple of minutes to appear in the Microsoft Endpoint Manager admin
center. It appears only if it can successfully communicate with the Intune service.
Configure web proxy settings

If you have a web proxy in your networking environment, ensure that the Intune Connector for Active Directory
works properly by referring to Work with existing on-premises proxy servers.
Create a device group

1. In the Microsoft Endpoint Manager admin center, select Groups > New group .
2. In the Group pane, do the following:
a. For Group type , select Security .
b. Enter a Group name and Group description .
c. Select a Membership type .
3. If you selected Dynamic Devices for the membership type, in the Group pane, select Dynamic device
members and then, in the Advanced rule box, do one of the following:
To create a group that includes all your Autopilot devices, enter
(device.devicePhysicalIDs -any _ -contains "[ZTDId]") .
Intune's Group Tag field maps to the OrderID attribute on Azure AD devices. If you want to create a group
that includes all of your Autopilot devices with a specific Group Tag(OrderID) you must type:
(device.devicePhysicalIds -any _ -eq "[OrderID]:179887111881")
To create a group that includes all your Autopilot devices with a specific Purchase Order ID, enter
(device.devicePhysicalIds -any _ -eq "[PurchaseOrderId]:76222342342") .
4. Select Save .
5. Select Create .
Register your Autopilot devices

Select one of the following ways to enroll your Autopilot devices.
Register Autopilot devices that are already enrolled
1. Create an Autopilot deployment profile with Conver t all targeted devices to Autopilot set to Yes .
2. Assign the profile to a group that contains the members that you want to automatically register with Autopilot.
For more information, see Create an Autopilot deployment profile.
Register Autopilot devices that aren't enrolled
If your devices aren't yet enrolled, you can register them yourself. For more information, see Add devices.
Register devices from an OEM
If you're buying new devices, some OEMs can register the devices for you. For more information, see OEM
registration.
When your Autopilot devices are registered, before they're enrolled into Intune, they're displayed in three places
(with names set to their serial numbers):
The Autopilot Devices pane in the Intune in the Azure portal. Select Device enrollment > Windows
enrollment > Devices .
The Azure AD devices pane in the Intune in the Azure portal. Select Devices > Azure AD Devices .
The Azure AD All Devices pane in Azure Active Directory in the Azure portal by selecting Devices > All
Devices .
After your Autopilot devices are enrolled, they're displayed in four places:
The Autopilot Devices pane in the Intune in the Azure portal. Select Device enrollment > Windows
enrollment > Devices .
The Azure AD devices pane in the Intune in the Azure portal. Select Devices > Azure AD Devices .
The Azure AD All Devices pane in Azure Active Directory in the Azure portal. Select Devices > All Devices .
The All Devices pane in the Intune in the Azure portal. Select Devices > All Devices .
After your Autopilot devices are enrolled, their names become the hostname of the device. By default, the hostname
begins with DESKTOP-.
Create and assign an Autopilot deployment profile

Autopilot deployment profiles are used to configure the Autopilot devices.
Deployment Profiles > Create Profile .
2. On the Basics page, type a Name and optional Description .
3. If you want all devices in the assigned groups to automatically convert to Autopilot, set Conver t all targeted
devices to Autopilot to Yes . All corporate owned, non-Autopilot devices in assigned groups will register with
the Autopilot deployment service. Personally owned devices will not be converted to Autopilot. Allow 48 hours
for the registration to be processed. When the device is unenrolled and reset, Autopilot will enroll it. After a
device is registered in this way, disabling this option or removing the profile assignment won't remove the
device from the Autopilot deployment service. You must instead remove the device directly.
4. Select Next .
5. On the Out-of-box experience (OOBE) page, for Deployment mode , select User-driven .
6. In the Join to Azure AD as box, select Hybrid Azure AD joined .
7. If you are deploying devices off of the organization's network leveraging VPN support, set the Skip Domain
Connectivity Check option to Yes . See User-driven mode for hybrid Azure Active Directory join with VPN
support for additional information.
8. Configure the remaining options on the Out-of-box experience (OOBE) page as needed.
9. Select Next .
10. On the Scope tags page, select scope tags for this this profile.
11. Select Next .
12. On the Assignments page, select Select groups to include > search for and select the device group >
Select .
13. Select Next > Create .
It takes about 15 minutes for the device profile status to change from Not assigned to Assigning and, finally, to
Assigned.
(Optional) Turn on the enrollment status page
Enrollment Status Page .
2. In the Enrollment Status Page pane, select Default > Settings .
3. In the Show app and profile installation progress box, select Yes .
4. Configure the other options as needed.
5. Select Save .
Create and assign a Domain Join profile

1. In the Microsoft Endpoint Manager admin center, select Devices > Configuration profiles > Create
Profile .
2. Enter the following properties:
Name : Enter a descriptive name for the new profile.
Description : Enter a description for the profile.
Platform : Select Windows 10 and later .
Profile type : Select Domain Join (Preview) .
3. Select Settings , and then provide a Computer name prefix , Domain name .
4. (Optional) Provide an Organizational unit (OU) in DN format. Your options include:
Provide an OU in which you've delegated control to your Windows 2016 device that is running the Intune
Connector.
Provide an OU in which you've delegated control to the root computers in your on-prem Active Directory.
If you leave this blank, the computer object will be created in the Active Directory default container
(CN=Computers if you never changed it).
Here are some valid examples:
OU=Level 1,OU=Level2,DC=contoso,DC=com
OU=Mine,DC=contoso,DC=com
Here are some examples that are not valid:
CN=Computers,DC=contoso,DC=com (you can't specify a container, instead leave the value blank to use
the default for the domain)
OU=Mine (you must specify the domain via the DC= attributes)
NOTE
Don't use quotation marks around the value in Organizational unit .
5. Select OK > Create .

The profile is created and displayed in the list.
6. To assign the profile, follow the steps under Assign a device profile and assign the profile to the same group
used at this step Create a device group. Alternatively, different groups can be used if there is a need to join
devices to different domains or OUs.
NOTE
The naming capabilities for Windows Autopilot for Hybrid Azure AD Join do not support variables such as %SERIAL% and
only support prefixes for the computer name.
Next steps
After you configure Windows Autopilot, learn how to manage those devices. For more information, see What is
Microsoft Intune device management?.
Configure Autopilot profiles
Applies to
Windows 10
For each device that has been defined to the Windows Autopilot deployment service, a profile of settings needs to
be applied that specifies the exact behavior of that device when it is deployed. For detailed procedures on how to
configure profile settings and register devices, see Registering devices.
Profile settings
The following profile settings are available:
Skip Cor tana, OneDrive, and OEM registration setup pages . All devices registered with Autopilot
will automatically skip these pages during the out-of-box experience (OOBE) process.
Automatically set up for work or school . All devices registered with Autopilot are automatically
considered work or school devices, so this question will not appear during the OOBE process.
Sign in experience with company branding . Instead of presenting a generic Azure Active Directory
sign-in page, all devices registered with Autopilot will present a customized sign-in page with the
organization’s name, logo, and additional help text, as configured in Azure Active Directory. See Add
company branding to your directory to customize these settings.
Skip privacy settings . This optional Autopilot profile setting enables organizations to not ask about
privacy settings during the OOBE process. This is typically desirable so that the organization can configure
these settings via Intune or other management tool.
Disable local admin account creation on the device . Organizations can decide whether the user
setting up the device should have administrator access once the process is complete.
Skip End User License Agreement (EUL A) . In Windows 10 version 1709 and later, organizations can
decide to skip the EULA page presented during the OOBE process. This means that organizations accept the
EULA terms on behalf of their users.
Disable Windows consumer features . In Windows 10 version 1803 and later, organizations can disable
Windows consumer features so that the device does not automatically install any additional Microsoft Store
apps when the user first signs into the device. For more information, see the MDM documentation.
Related topics
Profile download
Registering devices
Windows Autopilot Enrollment Status Page
Applies to
Windows 10, version 1803 and later
The Enrollment Status Page (ESP) displays the status of the complete device configuration process when an MDM-
managed user signs into a device for the very first time. The ESP will help users understand the progress of device
provisioning and ensures the device has met the organizations desired state before the user can access the
desktop for the first time.
The ESP will track the installation of applications, security policies, certificates, and network connections. With
Intune, an administrator can deploy ESP profiles to a licensed Intune user and configure specific settings within
the ESP profile; a few of these settings are: force the installation of specified applications, allow users to collect
troubleshooting logs, specify what a user can do if device setup fails. For more information, see how to set up the
Enrollment Status Page in Intune.
More information
For more information on configuring the Enrollment Status Page, see the Microsoft Intune documentation.
For details about the underlying implementation, see the FirstSyncStatus details in the DMClient CSP
documentation.
For more information about blocking for app installation:
Blocking for app installation using Enrollment Status Page.
Support Tip: Office C2R installation is now tracked during ESP.
Setting the BitLocker encryption algorithm for
Autopilot devices
Applies to
Windows 10
With Windows Autopilot, you can configure BitLocker encryption settings to get applied before automatic
encryption starts. This configuration makes sure the default encryption algorithm isn't applied automatically.
Other BitLocker policies can also be applied before automatic BitLocker encryption begins.
The BitLocker encryption algorithm is used when BitLocker is first enabled. The algorithm sets the strength for full
volume encryption. Available encryption algorithms are: AES-CBC 128-bit, AES-CBC 256-bit, XTS-AES 128-bit, or
XTS-AES 256-bit encryption. The default value is XTS-AES 128-bit encryption. See BitLocker CSP for information
about the recommended encryption algorithms to use.
To make sure the BitLocker encryption algorithm you want is set before automatic encryption occurs for Autopilot
devices:
1. Configure the encryption method settings in the Windows 10 Endpoint Protection profile to the encryption
algorithm you want.
2. Assign the policy to your Autopilot device group. The encryption policy must be assigned to devices in the
group, not users.
3. Enable the Autopilot Enrollment Status Page (ESP) for these devices. If the ESP isn't enabled, the policy won't
apply before encryption starts.
An example of Microsoft Intune Windows Encryption settings is shown below.
A device that is encrypted automatically will need to be decrypted before changing the encryption algorithm.
The settings are available under Device Configuration > Profiles > Create profile > Platform = Windows 10
and later, Profile type = Endpoint protection > Configure > Windows Encr yption > BitLocker base settings ,
Configure encryption methods = Enable.
It's also recommended to set Windows Encr yption > Windows Settings > Encr ypt = Require.
Requirements
Windows 10, version 1809 or later.
Next steps
BitLocker overview
DFCI Management
Applies to
Windows 10
With Windows Autopilot Deployment and Intune, you can manage Unified Extensible Firmware Interface (UEFI)
settings after they're enrolled by using the Device Firmware Configuration Interface (DFCI). DFCI enables Windows
to pass management commands from Intune to UEFI to Autopilot deployed devices. This allows you to limit end
user's control over BIOS settings. For example, you can lock down the boot options to prevent users from booting
up another OS, such as one that doesn't have the same security features.
If a user reinstalls a previous Windows version, install a separate OS, or format the hard drive, they can't override
DFCI management. This feature can also prevent malware from communicating with OS processes, including
elevated OS processes. DFCI’s trust chain uses public key cryptography, and doesn't depend on local UEFI password
security. This layer of security blocks local users from accessing managed settings from the device’s UEFI menus.
For an overview of DFCI benefits, scenarios, and prerequisites, see Device Firmware Configuration Interface (DFCI)
Introduction.
DFCI management lifecycle

The DFCI management lifecycle can be viewed as UEFI integration, device registration, profile creation, enrollment,
management, retirement, and recovery. See the following figure.
Requirements
Windows 10, version 1809 or later and a supported UEFI is required.
The device manufacturer must have DFCI added to their UEFI firmware in the manufacturing process, or as a
firmware update that you install. Work with your device vendors to determine the manufacturers that support
DFCI, or the firmware version needed to use DFCI.
The device must be managed with Microsoft Intune. For more information, see Enroll Windows devices in Intune
using Windows Autopilot.
The device must be registered for Windows Autopilot by a Microsoft Cloud Solution Provider (CSP) partner, or
registered directly by the OEM.
IMPORTANT
Devices manually registered for Autopilot (such as by importing from a csv file) are not allowed to use DFCI. By design, DFCI
management requires external attestation of the device’s commercial acquisition through an OEM or a Microsoft CSP partner
registration to Windows Autopilot. When your device is registered, its serial number is displayed in the list of Windows
Autopilot devices.
Managing DFCI profile with Windows Autopilot

There are four basic steps in managing DFCI profile with Windows Autopilot:
1. Create an Autopilot Profile
2. Create an Enrollment status page profile
3. Create a DFCI profile
4. Assign the profiles
See Create the profiles and Assign the profiles, and reboot for details.
You can also change existing DFCI settings on devices that are in use. In your existing DFCI profile, change the
settings and save your changes. Since the profile is already assigned, the new DFCI settings take effect when next
time the device syncs or the device reboots.
OEMs that support DFCI

Microsoft Surface
Additional OEMs are pending.
See also
Microsoft DFCI Scenarios
Windows Autopilot and Surface devices

Windows Autopilot is designed to simplify all parts of the Windows device lifecycle, but there are always situations
where issues may arise. Review the following information to assist with troubleshooting efforts.
Troubleshooting process
Whether you're performing user-driven or self-deploying device deployments, the troubleshooting process is
about the same. It's useful to understand the flow for a specific device:
1. A network connection is established. The connection can be a wireless (Wi-fi) or wired (Ethernet) connection.
2. The Windows Autopilot profile is downloaded. When you use a wired connection, or manually establish a
wireless connection, the profile downloads from the Autopilot deployment service as soon as the network
connection is in place.
3. User authentication occurs. When performing a user-driven deployment, the user will enter their Azure Active
Directory credentials, which will be validated.
4. Azure Active Directory join occurs. For user-driven deployments, the device will be joined to Azure AD using the
specified user credentials. For self-deploying scenarios, the device will be joined without specifying any user
credentials.
5. Automatic MDM enrollment occurs. As part of the Azure AD join process, the device will enroll in the MDM
service configured in Azure AD (for example, Microsoft Intune).
6. Settings are applied. If the enrollment status page is configured, most settings will be applied while the
enrollment status page is displayed. If not configured or available, settings will be applied after the user is
signed in.
For troubleshooting, key activities to perform are:
Configuration: Has Azure Active Directory and Microsoft Intune (or an equivalent MDM service) been
configured as specified in Windows Autopilot configuration requirements?
Network connectivity: Can the device access the services described in Windows Autopilot networking
requirements?
Autopilot out-of-box (OOBE) behavior: Were only the expected out-of-box experience screens displayed? Was
the Azure AD credentials page customized with organization-specific details as expected?
Azure AD join issues: Was the device able to join Azure Active Directory?
MDM enrollment issues: Was the device able to enroll in Microsoft Intune (or an equivalent MDM service)?
Troubleshooting Autopilot Device Import

Clicking Import after selecting CSV does nothing, '400' error appears in network trace with error body "Cannot
convert the literal '[DEVICEHASH ]' to the expected type 'Edm.Binary'"
This error points to the device hash being incorrectly formatted. Anything that corrupts the collected hash can
cause this error. One possibility is that the hash itself (even if it's valid) fails to be decoded.
The device hash is Base64. At the device level, it's encoded as unpadded Base64, but Autopilot expects padded
Base64. Usually, the payload doesn't require padding and the process works. Sometimes, however, the payload
doesn't line up cleanly and padding is necessary. In this case, you get the error displayed above. PowerShell's
Base64 decoder also expects padded Base64, so we can use this decoder to validate that the hash is properly
padded.
The "A" characters at the end of the hash are effectively empty data. Each character in Base64 is 6 bits, A in Base64
is 6 bits equal to 0. Deleting or adding A s at the end doesn't change the actual payload data.
To fix this issue, we'll need to modify the hash, then test the new value, until PowerShell succeeds in decoding the
hash. The result is mostly illegible, which is fine. We're just looking for it to not throw the error "Invalid length for a
Base-64 char array or string".
To test the base64, you can use the following PowerShell:
[System.Text.Encoding]::ascii.getstring( [System.Convert]::FromBase64String("DEVICE HASH"))
So, as an example (this isn't a device hash, but it's misaligned unpadded Base64 so it's good for testing):
[System.Text.Encoding]::ascii.getstring( [System.Convert]::FromBase64String("Q29udG9zbwAAA"))
Now for the padding rules. The padding character is "=". The padding character can only be at the end of the hash,
and there can only be a maximum of two padding characters. Here's the basic logic.
Does decoding the hash fail?
Yes: Are the last two characters "="?
Yes: Replace both "=" with a single "A" character, then try again
No: Add another "=" character at the end, then try again
No: That hash is valid
Looping the logic above on the previous example hash, we get the following permutations:
Q29udG9zbwAAA
Q29udG9zbwAAA=
Q29udG9zbwAAA==
Q29udG9zbwAAAA
Q29udG9zbwAAAA=
Q29udG9zbwAAAA== (This one has valid padding)
Replace the collected hash with this new padded hash then try to import again.
Troubleshooting Autopilot OOBE issues

When OOBE includes unexpected Autopilot behavior, it's useful to check if the device received an Autopilot profile.
If so, check the settings that the profile contained. Depending on the Windows 10 release, there are different
mechanisms available to do that.
Windows 10 version 1803 and above
Windows 10 version 1803 and above adds event log entries. You can use the og entries to see details related to the
Autopilot profile settings and OOBE flow. These entries can be viewed using Event Viewer. Review the information
at Application and Ser vices Logs –> Microsoft –> Windows –> Provisioning-Diagnostics-Provider –>
Autopilot for versions before 1903. For version 1903 and later, see Application and Ser vices Logs –>
Microsoft –> Windows –> ModernDeployment-Diagnostics-Provider –> Autopilot . The following events
may be recorded, depending on the scenario and profile configuration:
EVEN T ID TYPE DESC RIP T IO N
100 Warning “Autopilot policy [name] not found.” This

error is typically a temporary problem,
while the device is waiting for an
Autopilot profile to be downloaded.
101 Info “AutopilotGetPolicyDwordByName

succeeded: policy name = [setting
name]; policy value = [value].” This
message shows Autopilot retrieving
and processing numeric OOBE settings.
103 Info “AutopilotGetPolicyStringByName

succeeded: policy name = [name]; value
= [value].” This message shows
Autopilot retrieving and processing
OOBE setting strings such as the Azure
AD tenant name.
109 Info “AutopilotGetOobeSettingsOverride

succeeded: OOBE setting [setting
name]; state = [state].” This message
shows Autopilot retrieving and
processing state-related OOBE settings.
111 Info “AutopilotRetrieveSettings succeeded.”

This message means that the settings
stored in the Autopilot profile that
control the OOBE behavior have been
retrieved successfully.
153 Info “AutopilotManager reported the state

changed from [original state] to [new
state].” Usually, this message should say
“ProfileState_Unknown” to
“ProfileState_Available”. This case
indicates that a profile was available
and downloaded for the device. So, the
device is ready to deploy using
Autopilot.
160 Info “AutopilotRetrieveSettings beginning

acquisition.” This message shows that
Autopilot is getting ready to download
the needed Autopilot profile settings.
161 Info “AutopilotManager retrieve settings

succeeded.” The Autopilot profile was
successfully downloaded.
163 Info “AutopilotManager determined

download isn't required and the device
is already provisioned. Clean or reset
the device to change this.” This message
indicates that an Autopilot profile is
resident on the device; it typically would
only be removed by the Sysprep
/Generalize process.
EVEN T ID TYPE DESC RIP T IO N
164 Info “AutopilotManager determined Internet

is available to attempt policy download.”
171 Error “AutopilotManager failed to set TPM

identity confirmed. HRESULT=[error
code].” This message indicates an issue
performing TPM attestation, needed to
complete the self-deploying mode
process.
172 Error “AutopilotManager failed to set

Autopilot profile as available. HRESULT=
[error code].” This error is typically
related to event ID 171.
In addition to the event log entries, the registry and ETW trace options below work with Windows 10 version 1803
and above.
Windows 10 version 1709 and above
Autopilot profile settings received from the Autopilot deployment service are stored in the device's registry. This
information can be found at HKLM\SOFTWARE\Microsoft\Provisioning\Diagnostics\Autopilot . Available
registry entries include:
VA L UE DESC RIP T IO N
AadTenantId The GUID of the Azure AD tenant the user signed into. The
user receives an error if this entry doesn't match the tenant
that was used to register the device.
CloudAssignedTenantDomain The Azure AD tenant the device has been registered with, for
example, “contosomn.onmicrosoft.com.” If the device isn't
registered with Autopilot, this value will be blank.
CloudAssignedTenantId The GUID of the Azure AD tenant the device registered with.
The GUID corresponds to the tenant domain from the
CloudAssignedTenantDomain registry value. If the device isn’t
registered with Autopilot, this value will be blank.
IsAutopilotDisabled If set to 1, this registry value indicates that the device isn't
registered with Autopilot. This state could also indicate that
the Autopilot profile couldn't be downloaded because of
network connectivity or firewall issues, or network timeouts.
TenantMatched This entry is set to 1 if the user's tenant ID matches the

tenant ID that the device was registered with. If this registry
value is 0, the user would be shown an error and forced to
start over.
CloudAssignedOobeConfig A bitmap that shows which Autopilot settings were

configured. Values include: SkipCortanaOptIn = 1,
OobeUserNotLocalAdmin = 2, SkipExpressSettings = 4,
SkipOemRegistration = 8, SkipEula = 16
Windows 10 semi-annual channel supported versions

On devices running a supported version of Windows 10 semi-annual channel, you can use ETW tracing to get
detailed information from Autopilot and related components. The ETW trace files can be viewed using the
Windows Performance Analyzer or similar tools. For more information, see the advanced troubleshooting blog.
Troubleshooting Azure AD Join issues

The most common issue joining a device to Azure AD is related to Azure AD permissions. Make sure that the
correct configuration is in place to allow users to join devices to Azure AD. Errors can also happen if the user
exceeds the number of devices that they're allowed to join. This limit is configured in Azure AD.
An Azure AD device is created upon import. It's important this object isn't deleted. The object acts as Autopilot's
anchor in Azure AD for group membership and targeting (including the profile). Deleting it may lead to join errors.
If this object is deleted, you can fix the issue by deleting and reimporting this autopilot hash so it can recreate the
associated object.
Error code 801C0003 will typically be reported on an error page titled "Something went wrong". This error means
that the Azure AD join failed.
Troubleshooting Intune enrollment issues

See this knowledge base article for assistance with Intune enrollment issues. Common issues can include"
incorrect or missing licenses assigned to the user.
too many devices enrolled for the user.
Error code 80180018 will typically be reported on an error page titled "Something went wrong". This error means
that the MDM enrollment failed.
If Autopilot Reset fails immediately with the error Ran into trouble. Please sign in with an administrator
account to see why and reset manually , see Troubleshoot Autopilot Reset for more help.
Profile download
When an Internet-connected Windows 10 device boots up, it will attempt to connect to the Autopilot service and
download an Autopilot profile. Note: It's important that a profile exists at this stage so that a blank profile isn't
cached locally on the PC. To remove the currently cached local profile in Windows 10 version 1803 and earlier, it's
necessary to re-generalize the OS using sysprep /generalize /oobe , reinstall the OS, or re-image the PC. In
Windows 10 version 1809 and later, you can retrieve a new profile by rebooting the PC.
When a profile is downloaded depends upon the version of Windows 10 that is running on the PC. See the
following table.
W IN DO W S 10 VERSIO N P RO F IL E DO W N LO A D B EH AVIO R
1709 The profile is downloaded after the OOBE network connection

page. This page isn't displayed when using a wired connection.
In this case, the profile is downloaded before the EULA screen.
1803 The profile is downloaded as soon as possible. If wired, it's

downloaded at the start of OOBE. If wireless, it's downloaded
after the network connection page.
1809 The profile is downloaded as soon as possible (same as 1803),

and again after each reboot.
If you need to reboot a computer during OOBE:

Press Shift-F10 to open a command prompt.
Enter shutdown /r /t 0 to restart immediately, or shutdown /s /t 0 to shut down immediately.
For more information, see Windows Setup Command-Line Options.
Related topics
Windows Autopilot - known issues
Diagnose MDM failures in Windows 10
Windows Autopilot - Policy Conflicts
Applies to
Windows 10
There are a significant number of policy settings available for Windows 10, both as native MDM policies and group
policy (ADMX-backed) settings. Some of these can cause issues in certain Windows Autopilot scenarios as a result
of how they change the behavior of Windows 10. If you encounter any of these issues, remove the policy in
question to resolve the issue.
P O L IC Y M O RE IN F O RM AT IO N
Device restriction / Password Policy When certain DeviceLock policies, such as minimum password
length and password complexity, or any similar group policy
settings (including any that disable autologon) are applied to a
device, and that device reboots during the device Enrollment
Status Page (ESP), the out-of-box experience (OOBE) or user
desktop autologon can fail unexpectantly. This is especially
true for kiosk scenarios where passwords are automatically
generated.
Windows 10 Security Baseline / Administrator elevation When modifying user account control (UAC) settings during
prompt behavior the OOBE using the device Enrollment Status Page (ESP),
Windows 10 Security Baseline / Require admin approval mode additional UAC prompts may result, especially if the device
for administrators reboots after these policies are applied, enabling them to take
effect. To work around this issue, the policies can be targeted
to users instead of devices so that they apply later in the
process.
Device restrictions / Cloud and Storage / Microsoft Account Setting this policy to "disabled" will disable the Microsoft Sign-
sign-in assistant in Assistant service (wlidsvc). This service is required by
Windows Autopilot to obtain the Windows Autopilot profile.
Related topics
Windows Autopilot - known issues
Applies to
Windows 10
ISSUE M O RE IN F O RM AT IO N
Blocking apps specified in a user-targeted Enrollment Status The services responsible for determining the list of apps that
Profile are ignored during device ESP. should be blocking during device ESP aren't able to determine
the correct ESP profile containing the list of apps because
they don't know the user identity. As a workaround, enable
the default ESP profile (which targets all users and devices)
and place the blocking app list there. In the future, it will be
possible to instead target the ESP profile to device groups to
avoid this issue.
That username looks like it belongs to another organization. Confirm that all of your information is correct at
Try signing in again or start over with a different account. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Provisioning\
Diagnostics\AutoPilot. For more information, see
Troubleshooting Windows Autopilot.
Windows Autopilot user-driven Hybrid Azure AD This issue will occur when there's another user on the device
deployments don't grant users Administrator rights even that already has Administrator rights. For example, a
when specified in the Windows Autopilot profile. PowerShell script or policy could create an additional local
account that is a member of the Administrators group. To
ensure this works properly, don't create an additional account
until after the Windows Autopilot process has completed.
Windows Autopilot device provisioning can fail with TPM To fix this issue:
attestation errors or ESP timeouts on devices where the real- 1. Boot the device to the start of the out-of-box
time clock is off by a significant amount of time (for example, experience (OOBE).
several minutes or more). 2. Establish a network connection (wired or wireless).
3. Run the command w32tm /resync /force to sync
the time with the default time server
(time.windows.com).
Windows Autopilot for existing devices doesn't work for To fix this issue:
Windows 10, version 1903 or 1909; you see screens that 1. Edit the Configuration Manager task sequence and
you've disabled in your Windows Autopilot profile, such as disable the Prepare Windows for Capture step.
the Windows 10 License Agreement screen. 2. Add a new Run command line step that runs
c:\windows\system32\sysprep\sysprep.exe
This issue happens because Windows 10, version 1903 and /oobe /reboot .
1909 deletes the AutopilotConfigurationFile.json file.
More information
TPM attestation fails on Windows 10 1903 because of Download and install the KB4517211 update.
missing AKI extension in EK certificate. (An additional
validation added in Windows 10 1903 to check that the TPM
EK certs had the proper attributes according to the TCG
specifications uncovered that a number of them don’t, so that
validation will be removed).
The following known issues are resolved by installing the Download and install the KB4512941 update.
August 30, 2019 KB4512941 update (OS Build 18362.329):
Windows Autopilot for existing devices feature doesn't See the section: How to get this update for information on
properly suppress “Activities” page during OOBE. specific release channels you can use to obtain the update.
(Because of this issue, you’ll see that extra page during
OOBE).
TPM attestation state isn't cleared by sysprep
/generalize, causing TPM attestation failure during
later OOBE flow. (This isn’t a particularly common
issue, but you could run into it while testing if you're
running sysprep /generalize and then rebooting or
reimaging the device to go back through an Autopilot
white glove or self-deploying scenario).
TPM attestation may fail if the device has a valid AIK
cert but no EK cert. (This issue is related to the
previous item).
If TPM attestation fails during the Windows Autopilot
white glove process, the landing page appears to be
hung. (Basically, the white glove landing page, where
you click “Provision” to start the white glove process,
isn’t reporting errors properly).
TPM attestation fails on newer Infineon TPMs
(firmware version > 7.69). (Before this fix, only a
specific list of firmware versions was accepted).
Device naming templates may truncate the computer
name at 14 characters instead of 15.
Assigned Access policies cause a reboot, which can
interfere with the configuration of single-app kiosk
devices.
The following known issues are resolved by installing the July Download and install the KB4505903 update.
26, 2019 KB4505903 update (OS Build 18362.267):
Windows Autopilot white glove doesn't work for a See the section: How to get this update for information on
non-English OS and you see a red screen that says specific release channels you can use to obtain the update.
"Success."
Windows Autopilot reports an AUTOPILOTUPDATE
error during OOBE after sysprep, reset, or other
variations. This issue typically happens if you reset the
OS or used a custom sysprepped image.
BitLocker encryption isn't correctly configured. Ex:
BitLocker didn’t get an expected notification after
policies were applied to begin encryption.
You're unable to install UWP apps from the Microsoft
Store, causing failures during Windows Autopilot. If
you're deploying Company Portal as a blocking app
during Windows Autopilot ESP, you’ve probably seen
this error.
A user isn't granted administrator rights in the
Windows Autopilot user-driven Hybrid Azure AD join
scenario. This is another non-English OS issue.
Windows Autopilot self-deploying mode fails with an error
code: 0x800705B4 This is a general error
indicating a timeout. A
common cause of this error
in self-deploying mode is
that the device isn't TPM 2.0
capable (ex: a virtual
machine). Devices that aren't
TPM 2.0 capable can't be
used with self-deploying
mode.
0x801c03ea This error indicates that

TPM attestation failed,
causing a failure to join
Azure Active Directory with
a device token.
0xc1036501 The device can't do an

automatic MDM enrollment
because there are multiple
MDM configurations in
Azure AD. See Inside
Windows Autopilot self-
deploying mode.
White glove gives a red screen and the Microsoft- This issue can happen if Azure AD can’t find an Azure AD
Windows-User Device Registration/Admin event log device object for the device that you're trying to deploy. This
displays HResult error code 0x801C03F3 issue will occur if you manually delete the object. To fix it,
remove the device from Azure AD, Intune, and Autopilot, then
re-register it with Autopilot, which will recreate the Azure AD
device object.
To obtain troubleshooting logs, use:

Mdmdiagnosticstool.exe -area Autopilot;TPM -cab
c:\autopilot.cab
White glove gives a red screen White glove isn't supported on a VM.
Error importing Windows Autopilot devices from a .csv file Ensure that you haven't edited the .csv file in Microsoft Excel
or an editor other than Notepad. Some of these editors can
introduce extra characters causing the file format to be
invalid.
Windows Autopilot for existing devices doesn't follow the Ensure that the JSON profile file is saved in ANSI/ASCII
Autopilot OOBE experience. format, not Unicode or UTF-8.
Something went wrong is displayed page during OOBE. The client is likely unable to access all the required Azure
AD/MSA-related URLs. For more information, see
[Networking requirements](networking-requirements.md).
Using a provisioning package in combination with Windows Using PPKGs in combination with Windows Autopilot isn't
Autopilot can cause issues, especially if the PPKG contains recommended.
join, enrollment, or device name information.
Related topics
Diagnose MDM failures in Windows 10
Windows Autopilot deployment process
Applies to
Windows 10
Windows Autopilot deployment processes are summarized in the poster below. The poster is two pages in portrait
mode (11x17). Click the image below to view a PDF in your browser.
Note : The Windows Autopilot for existing devices process is included in the Microsoft Endpoint Configuration
Manager deployment poster.
Windows Autopilot FAQ

This article provides OEMs, partners, administrators, and end users with answers to some frequently asked
questions about deploying Windows 10 with Windows Autopilot.
A glossary of abbreviations used in this article is provided at the end.
Microsoft Partner Center

Q UEST IO N A N SW ER
In the Partner Center, does the Tenant ID need to be provided No. Providing the Tenant ID is a one-time entry in the Partner
with every device file upload? Is it needed to allow the Center that can be reused with future device uploads.
business customer to access their devices in Microsoft Store
for Business (MSfB)?
How does the customer or tenant know that their devices are After the device file upload is completed in the Partner Center,
ready to be claimed in MSfB? the tenant can see the devices available for Windows Autopilot
setup in MSfB. The OEM needs to advise the tenant to access
MSfB. Autonotification from MSfB to the tenant is being
developed.
How does a customer authorize an OEM or Channel Partner Before an OEM or Channel Partner can register a device for
to register Autopilot devices on the customer’s behalf? Autopilot on behalf of a customer, the customer must first
give them consent. The consent process begins with the OEM
or Channel Partner sending a link to the customer that directs
the customer to a consent page in MSfB. For more
information, see Registration.
Are there any restrictions if a business customer has The devices will need to be deleted in MSfB by the business
registered devices in MSfB and later wants those devices to be customer before the CSP can upload and manage them in the
managed by a Cloud Solution Provider (CSP) using the Partner Partner Center.
Center?
Does Windows Autopilot support removing the option to Windows Autopilot doesn’t support removing the local admin
enable a local administrator account? account. However, it does support restricting the user
performing Azure Active Directory (Azure AD) domain join in
OOBE to a standard account (versus an administrator account
by default).
How can I test the Windows Autopilot CSV file in the Partner Only CSP Partners have access to the Partner Center portal. If
Center? you are a CSP, you can create a Sales agent user account that
has access to devices for testing the file. This can be done
today in the Partner Center.
For more information, see Create user accounts and set

permissions.
Is it required to become a CSP to participate in Windows This is not required for top volume OEMs because they can
Autopilot? use the OEM Direct API. All others who choose to use MPC to
register devices must become CSPs in order to access MPC.
Do the different CSP levels have all the same capabilities when For purposes of Windows Autopilot, there are three different
it comes to Windows Autopilot? types of CSPs, each with different levels of authority and
access:
1. Direct CSP : Gets direct authorization from the customer to

register devices.
2. Indirect CSP Provider : Gets implicit permission to

register devices through the relationship their CSP Reseller
partner has with the customer. Indirect CSP Providers register
devices through Microsoft Partner Center.
3. Indirect CSP Reseller : Gets direct authorization from the

customer to register devices. At the same time, their indirect
CSP Provider partner also gets authorization, which means
that either the Indirect Provider or the Indirect Reseller can
register devices for the customer. However, the Indirect CSP
Reseller must register devices through the MPC UI (manually
uploading CSV file), whereas the Indirect CSP Provider has the
option to register devices using the MPC APIs.
Is there such a thing as a single, worldwide CSP account? No. The CSP sales regions are dependent on the location of
the (AzureAD) tenant. A CSP Partner can only sell or manage
customers that have a tenant located in the same CSP region
as the Partner enrolled as CSP (the location of the tenant the
CSP Partner is using to transact). If the customer tenant was
created in the US, only a Partner that has a CSP enrollment in
the US can establish a reseller relationship with this customer.
With regards to Autopilot & Intune, it does not matter where
the end user or device is located. A device that is used by an
employee located in Germany can enroll using the Autopilot
profile created in the US tenant and can be managed by the
Intune service instance in US. The user in Germany will also
authenticate in the US AzureAD instance. If a partner wants to
manage customers globally, they need to have a global
presence. They must have multiple CSP enrollments in each of
the CSP sales regions where they wish to conduct business. It
is also not possible to create user accounts that have access to
all CSP tenants; this scenario would translate into 18 user
accounts for a CSP Admin Agent that wants to be able to
manage all customers around the world. In summary, the
location of the user and devices does not matter. The location
of the customer tenant matters. Cross-border device
registration is not the problem; the problem is cross-border
sales via CSP.
Manufacturing
What changes need to be made in the factory OS image for No changes are required on the factory floor to enable
customer configuration settings? Windows Autopilot deployment.
What version of the OA3 tool meets Windows Autopilot Windows Autopilot can work with any version of the OA3 tool.
deployment requirements? We recommend using a supported version of Windows 10
semi-annual channel to generate the 4K hardware hash.
At the time of placing an order, do customers need to be state Yes, if they want Windows Autopilot, they will want a
whether they want it with or without Windows Autopilot supported version of Windows 10 semi-annual channel. Also,
options? they will want to receive the CSV file or have the file upload
(that is, registration) completed on their behalf.
Does the OEM need to manage or collect any custom imaging No change, OEMs just send the CBRs as usual to Microsoft.
files from customers and perform any image uploads to No images are sent to Microsoft to enable Windows Autopilot.
Microsoft? Windows Autopilot only customizes OOBE and allows policy
configurations (disables admin account, for example).
Are there any customer impacts to upgrading from Windows The devices must be running a supported version of Windows
8 to Windows 10? 10 semi-annual channel to enroll in Windows Autopilot
deployment. Otherwise, there are no impacts.
Will there be any change to the existing CBR with 4K hardware No.
hash?
What new information needs to be sent from the OEM to Nothing, unless the OEM opts to register the device on the
Microsoft? customer’s behalf, in which case they would upload the device
ID using a CSV file into Microsoft Partner Center, or use the
OEM Direct API.
Is there a contract or amendment for an OEM to participate in No.

Windows Autopilot Deployment?
CSV schema
Can a comma be used in the CSV file? No.
What error messages can a user expect to see in the Partner See the In Microsoft Store for Business section of this guide.
Center or MSfB when uploading a file?
Is there a limit to the number of devices that can be listed in Yes, the CSV file can only contain 1,000 devices to apply to a
the CSV file? single profile. If more than 1,000 devices need to be applied to
a profile, the devices need to be uploaded through multiple
CSV files.
Does Microsoft have any recommendations on how an OEM We recommend encrypting the CSV file when sending to the
should provide the CSV file to their customers? business customer to self-register their Windows Autopilot
devices (either through MPC, MSfB, or Intune).
Hardware hash
Must every hardware hash submitted by the OEM contain the Yes. Since Windows Autopilot is based on the ability to
SMBIOS UUID (universally unique identifier), MAC (media uniquely identify devices applying for cloud configuration, it is
access control) address, and unique disk serial number (if critical to submit hardware hashes that meet the outlined
using Windows 10 OEM Activation 3.0 tool)? requirement.
What is the reason for needing the SMBIOS UUID, MAC For creating the hardware hash, these are the fields that are
Address, and Disk Serial Number in the hardware hash details? needed to identify a device, as parts of the device are added
or removed. Since we don’t have a unique identifier for
Windows devices, this is the best logic to identify a device.
What is difference between OA3 hardware hash, 4K hardware None. They’re different names for the same thing. The OA3
hash, and Windows Autopilot hardware hash? tool output is called the OA3 Hash, which is 4K in size, which is
usable for the Windows Autopilot deployment scenario. Note:
When using an older, unsupported Windows version OA3Tool,
you get a different sized Hash, which may not be used for
Windows Autopilot deployment.
What is the thought around parts replacement and repair for Yes. If you replace parts, you need to gather the new hardware
the NIC (network interface controller) and Disk? Will the hash, though it depends on what is replaced, and the
hardware hash become invalid? characteristics of the parts. For example, if you replace the
TPM or motherboard, it’s a new device and you must have
new hardware hash. If you replace one network card, it’s
probably not a new device, and the device will function with
the old hardware hash. However, as a best practice, you
should assume the old hardware hash is invalid and get a new
hardware hash after any hardware changes. This is
recommended anytime you replace parts.
Motherboard replacement
How does Autopilot handle motherboard replacement Motherboard replacement is out for scope for Autopilot. Any
scenarios? device that is repaired or serviced in a way that alters the
ability to identify the device for Windows Autopilot must go
through the normal OOBE process, and manually select the
right settings or apply a custom image, as is the case today.
To reuse the same device for Windows Autopilot after a

motherboard replacement, the device would need to be de-
registered from Autopilot, the motherboard replaced, a new
4K HH harvested, and then re-registered using the new 4K
hardware hash (or device ID).
Note : An OEM will not be able to use the OEM Direct API to
re-register the device, since the OEM Direct API only accepts a
tuple or PKID. In this case, the OEM would either have to send
the new 4K hardware hash information using a CSV file to
customer, and let customer reregister the device using MSfB
or Intune.
SMBIOS
Any specific requirement to SMBIOS UUID? It must be unique as specified in the Windows 10 hardware
requirements.
What is the requirement on the SMBIOS table to meet the It must meet all the Windows 10 hardware requirements.
Windows Autopilot hardware hash need? Additional details may be found here.
If the SMBIOS supports UUID and Serial Number, is it enough No. At a minimum, the following SMBIOS fields need to be
for the OA3 tool to generate the hardware hash? populated with unique values: ProductKeyID
SmbiosSystemManufacturer SmbiosSystemProductName
SmbiosSystemSerialNumber SmbiosSkuNumber
SmbiosSystemFamily MacAddress SmbiosUuid
DiskSerialNumber TPM EkPub
Technical interface
What is the interface to get the MAC Address and Disk Serial Disk serial number is found from
Number? How does the OA tool get MAC and Disk Serial #? IOCTL_STORAGE_QUERY_PROPERTY with
StorageDeviceProperty/PropertyStandardQuery. Network
MAC address is IOCTL_NDIS_QUERY_GLOBAL_STATS from
OID_802_3_PERMANENT_ADDRESS. However the method for
performing this operation varies depending on the scenario.
Follow up clarification: If we have 2-3 MACs on the system, In short, all available values are used. In detail, there may be
how does OA Tool choose which MAC Address and Disk Serial specific usage rules. The system disk serial number is more
Number are on the system since there are multiple instances important than the other disks available. Network interfaces
of each? If a platform has LAN And WLAN, which MAC is that are removable should not be used if detected as they are
chosen? removable. LAN vs WLAN should not matter, as both will be
used.
The end-user experience

How do I know that I received Autopilot? You can tell that you received Windows Autopilot (as in the
device received a configuration but has not yet applied it)
when you skip the selection page (as seen below), and are
immediately taken to a generic or customized sign-in page.
Windows Autopilot didn’t work, what do I do now? Questions and actions to assist in troubleshooting: Did a
screen not get skipped? Did a user end up as an admin when
configured not to? Remember that Azure AD Admins will be
local admins regardless of whether Windows Autopilot is
configured to disable local admin Collection information: run
licensingdiag.exe and send the .cab (Cabinet) file that is
generated to [email protected]. If possible, collect
an ETL from Windows Performance Recorder (WPR). Often in
these cases, users are not signing into the right Azure AD
tenant, or are creating local user accounts. For a complete list
of support options, refer to Windows Autopilot support.
If an Administrator makes changes to an existing profile, will No. Windows Autopilot profiles are not resident on the device.
the changes take effect on devices that have that profile They are downloaded during OOBE, the settings defined at
assigned to them that have already been deployed? the time are applied. Then, the profile is discarded on the
device. If the device is reimaged or reset, the new profile
settings will take effect the next time the device goes through
OOBE.
What is the experience if a device isn’t registered or if an IT If the device isn’t registered, it will not receive the Windows
Admin doesn’t configure Windows Autopilot prior to an end Autopilot experience and the end user will go through normal
user attempting to self-deploy? OOBE. The Windows Autopilot configurations will not be
applied until the user runs through OOBE again, after
registration. If a device is started before an MDM profile is
created, the device will go through standard OOBE experience.
The IT Admin would then have to manually enroll that device
into the MDM, after which the next time that device is reset, it
will go through the Windows Autopilot OOBE experience.
Why didn't I receive a customized sign-in screen during Tenant branding must be configured in portal.azure.com to
Autopilot? receive a customized sign-in experience.
What happens if a device is registered with Azure AD but does The regular Azure AD OOBE will occur since no Windows
not have a Windows Autopilot profile assigned? Autopilot profile was assigned to the device.
How can I collect logs on Autopilot? The best way to collect logs on Windows Autopilot
performance is to collect a WPR trace during OOBE. The XML
file (WPRP extension) for this trace may be provided upon
request.
MDM
Must we use Intune for our MDM? No, any MDM will work with Autopilot, but others probably
won’t have the same full suite of Windows Autopilot features
as Intune. You’ll get the best experience from Intune.
Can Intune support Win32 app preinstalls? Yes. Starting with the Windows 10 October Update (version
1809), Intune supports Win32 apps using .msi and .msix
wrappers.
What is co-management? Co-management is when you use a combination of a cloud

MDM tool (Intune) and an on-premises configuration tool like
Microsoft Endpoint Configuration Manager. You only need to
use the Configuration Manager if Intune can’t support what
you want to do with your profile. If you choose to co-manage
using Intune + Configuration Manager, you do it by including
a Configuration Manager agent in your Intune profile. When
that profile is pushed to the device, the device will see the
Configuration Manager agent and go out to the Configuration
Manager to pull down any additional profile settings.
Must we use Microsoft Endpoint Configuration Manager for No. Co-management (described above) is optional.
Windows Autopilot
Features
Self-deploying mode A new version of Windows Autopilot where the user only
turns on the device, and nothing else. It’s useful for scenarios
where a standard user account isn’t needed (for example,
shared devices, or KIOSK devices).
Hybrid Azure Active Directory join Allows Windows Autopilot devices to connect to an on-
premises Active Directory domain controller (in addition to
being Azure AD joined).
Windows Autopilot reset Removes user apps and settings from a device, but maintains
Azure AD domain join and MDM enrollment. Useful for when
transferring a device from one user to another.
Personalization Adds the following to the OOBE experience: A personalized

welcome message can be created. A username hint can be
added Sign-in page text can be personalized. The company’s
logo can be included
Autopilot for existing devices Offers an upgrade path to Windows Autopilot for all existing
Windows 7- and Windows 8-based devices.
General
If I wipe the machine and restart, will I still receive Windows Yes, if the device is still registered for Windows Autopilot and is
Autopilot? running a supported version of Windows 10 semi-annual
channel, it will receive the Windows Autopilot experience.
Can I harvest the device fingerprint on existing machines? Yes, if the device is running a supported version of Windows
10 semi-annual channel, you can harvest device fingerprints
for registration. There are no plans to backport the
functionality to legacy releases and no way to harvest them
on devices running unsupported versions of Windows.
Is Windows Autopilot supported on other SKUs, for example, No, Windows Autopilot isn’t supported on other SKUs.
Surface Hub, HoloLens, Windows Mobile.
Does Windows Autopilot work after MBR or image Yes. For more information, see Windows Autopilot
reinstallation? motherboard replacement scenario guidance.
Can devices that have been reimaged a few times go through There are limits to the number of devices a particular Azure
Autopilot? What does the error message "This user is not AD user can enroll in Azure AD, as well as the number of
authorized to enroll" mean? Error code 801c0003. devices that are supported per user in Intune. These are
configurable, but not infinite. You’ll run into this error
frequently if you reuse the devices, or even if you roll back to
previous virtual machine snapshots.
What happens if a device is registered to a malicious agent? By design, Windows Autopilot does not apply a profile until
the user signs in with the matching tenant for the configured
profile using the Azure AD sign-in process. For example, if
badguys.com registers a device owned by contoso.com, then
at worst, the user will be directed to sign in to badguys.com.
When the user enters their email and password, the sign-in
information is redirected through Azure AD to the proper
Azure AD authentication and the user is prompted to then
sign into contoso.com. Since contoso.com does not match
badguys.com as the tenant, the Windows Autopilot profile will
not be applied and the regular Azure AD OOBE will occur.
Where is the Windows Autopilot data stored? Windows Autopilot data is stored in the United States (US),
not in a sovereign cloud, even when the Azure AD tenant is
registered in a sovereign cloud. This is applicable to all
Windows Autopilot data, regardless of the portal leveraged to
deploy Autopilot.
Why is Windows Autopilot data stored in the US and not in a Customer data is not stored, only business data that enables
sovereign cloud? Microsoft to provide a service, therefore it is appropriate for
the data to reside in the US. Customers can stop subscribing
to the service at any time. In that event, the business data is
removed by Microsoft. Autopilot is not currently supported in
any sovereign cloud.
How many ways are there to register a device for Windows There are six ways to register a device, depending on who is
Autopilot doing the registering:
1. OEM Direct API (only available to TVOs)

2. MPC using the MPC API (must be a CSP)
3. MPC using manual upload of CSV file in the UI (must be a
CSP)
4. MSfB using CSV file upload
5. Intune using CSV file upload
6. Microsoft 365 Business Premium portal using CSV file
upload
How many ways are there to create a Windows Autopilot There are four ways to create and assign a Windows Autopilot
profile? profile:
1. Through MPC (must be a CSP)

2. Through MSfB
3. Through Intune (or another MDM)
4. Microsoft 365 Business Premium portal
Microsoft recommends creation and assignment of profiles

through Intune.
What are some common causes of registration failures? 1. Bad or missing hardware hash entries can lead to faulty
registration attempts
2. Hidden special characters in CSV files.
To avoid this issue, after creating your CSV file, open it in

Notepad to look for hidden characters or trailing spaces or
other corruptions.
Is Autopilot supported on IoT devices? Autopilot is not supported on IoT Core devices, and there are
currently no plans to add this support. Autopilot is supported
on Windows 10 IoT Enterprise SAC devices. Autopilot is
supported on Windows 10 Enterprise LTSC 2019 and above; it
is not supported on earlier versions of LTSC.
Is Autopilot supported in all regions/countries? Autopilot only supports customers using global Azure. Global
Azure does not include the three entities listed below:
- Azure Germany
- Azure China 21Vianet
- Azure Government
So, if a customer is set up in global Azure, there are no region
restrictions. For example, if Contoso uses global Azure but has
employees working in China, the Contoso employees working
in China would be able to use Autopilot to deploy devices. If
Contoso uses Azure China 21Vianet, the Contoso employees
would not be able to use Autopilot.
Glossary
T ERM M EA N IN G
CSV Comma-Separated Values (File type similar to Excel

spreadsheet)
MPC Microsoft Partner Center
MDM Mobile Device Management
OEM Original Equipment Manufacturer
CSP Cloud Solution Provider
MSfB Microsoft Store for Business
Azure AD Azure Active Directory
4K HH 4K hardware hash
CBR Computer Build Report
EC Enterprise Commerce
DDS Device Directory Service
OOBE Out of the Box Experience
UUID Universally Unique Identifier

Windows Autopilot support information

The following table displays support information for the Windows Autopilot program.
Before contacting the resources listed below for Windows Autopilot-related issues, check the Windows Autopilot
FAQ.
A UDIEN C E SUP P O RT C O N TA C T
OEM or Channel Partner registering devices as a CSP (via Use the help resources available in MPC. Whether you are a
MPC) named partner or a channel partner (distributor, reseller, SI,
etc.), if you’re a CSP registering Autopilot devices through
MPC (either manually or through the MPC API), your first-line
of support should be the help resources within MPC.
OEM registering devices using OEM Direct API Contact [email protected]. Response time depends
on priority:
Low – 120 hours
Normal – 72 hours
High – 24 hours
Immediate – 4 hours
Enterprise customers Contact your Technical Account Manager (TAM), or Account

Technology Strategist (ATS), or Customer Service Support
(CSS) representative.
End-user Contact your IT administrator.
Microsoft Partner Center (MPC) users Use the help resources available in MPC.
Microsoft Store for Business (MSfB) users Use the help resources available in MSfB.
Intune users From the Microsoft Azure portal, click Help + support.
Microsoft 365 Business Premium Support is accessible directly through the Microsoft 365
Business Premium portal when logged in:
https://support.microsoft.com/en-us.
Queries relating to MDA testing Contact [email protected].

Windows Autopilot customer consent

This article describes how a cloud service provider (CSP) partner (direct bill, indirect provider, or indirect reseller)
or an OEM can get customer authorization to register Windows Autopilot devices on the customer’s behalf.
CSP authorization
CSP partners can get customer authorization to register Windows Autopilot devices on the customer’s behalf per
the following restrictions:
Direct CSP Gets direct authorization from the customer to register

devices.
Indirect CSP Provider Gets implicit permission to register devices through the
relationship their CSP Reseller partner has with the customer.
Indirect CSP Providers register devices through Microsoft
Partner Center.
Indirect CSP Reseller Gets direct authorization from the customer to register
devices. At the same time, their indirect CSP Provider partner
also gets authorization, which mean that either the Indirect
Provider or the Indirect Reseller can register devices for the
customer. However, the Indirect CSP Reseller must register
devices through the MPC UI (manually uploading CSV file),
whereas the Indirect CSP Provider has the option to register
devices using the MPC APIs.
Steps
For a CSP to register Windows Autopilot devices on behalf of a customer, the customer must first grant that CSP
partner permission using the following process:
1. CSP sends link to customer requesting authorization/consent to register/manage devices on their behalf. To
do so:
CSP logs into Microsoft Partner Center
Click Dashboard on the top menu
Click Customer on the side menu
Click the Request a reseller relationship link:
Select the checkbox indicating whether or not you want delegated admin rights:
NOTE: Depending on your partner, they might request Delegated Admin Permissions (DAP) when
requesting this consent. You should ask them to use the newer DAP-free process (shown in this
document) if possible. If not, you can easily remove their DAP status either from Microsoft Admin Center
or the Microsoft 365 admin portal: https://docs.microsoft.com/partner-
center/customers_revoke_admin_privileges
Send the template above to the customer via email.
2. Customer with global administrator privileges in Microsoft Admin Center clicks the link in the body of the
email once they receive it from the CSP, which takes them directly to the following Microsoft 365 admin
center page:
The image above is what the customer will see if they requested delegated admin rights (DAP). Note that the
page says what Admin roles are being requested. If the customer did not request delegated admin rights
they would see the following page:
NOTE
A user without global admin privileges who clicks the link will see a message similar to the following:
3. Customer selects the Yes checkbox, followed by the Accept button. Authorization happens instantaneously.
4. The CSP will know that this consent/authorization request has been completed because the customer will
show up in the CSP’s MPC account under their customers list, for example:
OEM authorization
Each OEM has a unique link to provide to their respective customers, which the OEM can request from Microsoft
via [email protected].
1. OEM emails link to their customer.
2. Customer with global administrator privileges in Microsoft Store for Business (MSfB) clicks the link once
they receive it from the OEM, which takes them directly to the following MSfB page:
NOTE
A user without global admin privileges who clicks the link will see a message similar to the following:
3. Customer selects the Yes checkbox, followed by the Accept button, and they’re done. Authorization
happens instantaneously.
NOTE
Once this process has completed, it is not currently possible for an administrator to remove an OEM. To remove an
OEM or revoke their permissions, send a request to [email protected]
4. The OEM can use the Validate Device Submission Data API to verify the consent has completed. This API is
discussed in the latest version of the API Whitepaper, p. 14ff
https://devicepartner.microsoft.com/assets/detail/windows-autopilot-integration-with-oem-api-design-
whitepaper-docx. Note : this link is only accessible by Microsoft Device Partners. As discussed in this
whitepaper, it’s a best practice recommendation for OEM partners to run the API check to confirm they’ve
received customer consent before attempting to register devices, thus avoiding errors in the registration
process.
NOTE
During the OEM authorization registration process, no delegated admin permissions are granted to the OEM.
Summary
At this stage of the process, Microsoft is no longer involved; the consent exchange happens directly between the
OEM and the customer. And, it all happens instantaneously - as quickly as buttons are clicked.
Windows Autopilot device guidelines
Applies to
Windows 10
Hardware and firmware best practice guidelines for Windows Autopilot

All devices using Windows Autopilot should meet the minimum hardware requirements for Windows 10.
The following best practices ensure that devices can easily be provisioned as part of the Windows Autopilot
deployment process:
TPM 2.0 is enabled and in a good state (not in Reduced Functionality Mode ) on devices intended for
Windows Autopilot self-deploying mode.
The OEM should provision either of the following information into the SMBIOS fields. The information should
follow Microsoft specifications (Manufacturer, Product Name, and Serial Number stored in SMBIOS Type 1 04h,
Type 1 05h and Type 1 07h).
Unique tuple info (SmbiosSystemManufacturer, SmbiosSystemProductName,
SmbiosSystemSerialNumber)
PKID + SmbiosSystemSerialNumber
Before shipping devices to an Autopilot customer or channel partner, the OEM should upload 4K Hardware
Hashes to Microsoft by using the CBR report. The hashes should be collected using the OA3 Tool RS3+ run in
Audit mode on full OS.
Microsoft requires that OEM shipping drivers get published to Windows Update within 30 days of the CBR
submission date. System firmware and driver updates are published to Windows Update within 14 days.
The OEM ensures that the PKID provisioned in the SMBIOS is passed on to the channel.
Software best practice guidelines for Windows Autopilot

The Windows Autopilot device should be preinstalled with only a Windows 10 base image plus drivers.
You can preinstall your licensed version of Office, such as Microsoft 365 Apps for enterprise.
Unless explicitly requested by the customer, no other preinstalled software should be included.
Per OEM Policy, Windows 10 features, including built-in apps, shouldn't be disabled or removed.
Next steps
Windows Autopilot customer consent
Motherboard replacement scenario guidance
Windows Autopilot motherboard replacement
scenario guidance
Applies to
Windows 10
This document offers guidance for Windows Autopilot device repair scenarios that Microsoft partners can use in
Motherboard Replacement (MBR) situations, and other servicing scenarios.
Repairing Autopilot enrolled devices is complex, as it tries to balance OEM requirements with Windows Autopilot
requirements. Specifically, OEM requirements include strict uniqueness across motherboards, MAC addresses, and
so on. Windows Autopilot requires strict uniqueness at the hardware hash level for each device to enable
successful registration. The hardware hash doesn't always accommodate all the OEM hardware component
requirements. So these requirements are sometimes at odds, causing issues with some repair scenarios. The
hardware hash is also known as the hardware ID.
Motherboard Replacement (MBR)
If a motherboard replacement is needed on a Windows Autopilot device, the following process is recommended:
1. Deregister the device from Windows Autopilot
2. Replace the motherboard
3. Capture a new device ID (4K HH)
4. Reregister the device with Windows Autopilot
5. Reset the device
6. Return the device
Each of these steps is described below.
Deregister the Autopilot device from the Autopilot program

Before the device arrives at the repair facility, it must be deregistered by the entity that registered it.
If the IT Admin registered the device, they likely did so via Intune (or possibly the Microsoft Store for Business).
If so, they should deregister the device from Intune (or MSfB) because devices registered in Intune won't show
up in Microsoft Partner Center (MPC).
If the OEM or CSP par tner registered the device, they likely did so via the MPC. In that case, they should
deregister the device from MPC, which will also remove it from the customer IT Admin’s Intune account.
Below we describe the steps an IT Admin would go through to deregister a device from Intune, and the steps an
OEM or CSP would go through to deregister a device from MPC.
To avoid problems, an OEM or CSP should register Autopilot devices whenever possible. If the customer registers
the devices, OEMs or CSPs can't deregister them if, for example, a customer leasing a device goes out of business
before deregistering it themselves.
If a customer grants an OEM permission to register devices on their behalf using the automated consent process,
an OEM can use the API to deregister devices they didn’t register themselves. This deregistration only removes
those devices from the Autopilot program. It won't disenroll them from Intune or disjoin them from Azure AD. The
customer can only do those steps through Intune.
Deregister from Intune
To deregister an Autopilot device from Intune, an IT Admin would:
1. Sign in to their Intune account
2. Navigate to Intune > Groups > All groups
3. Remove the device from its group
4. Navigate to Intune > Devices > All devices
5. Select the checkbox next to the device you want to delete, then click the Delete button on the top menu
6. Navigate to Intune > Devices > Azure AD devices
7. Select the checkbox next to the device you want to delete, then click the Delete button along the top menu
8. Navigate to Intune > Device enrollment > Windows enrollment > Devices
9. Select the checkbox next to the device you want to deregister
10. Click the extended menu icon (“…”) on the far right end of the line containing the device you want to deregister
to expose an additional menu with the option to “unassign user”
11. Click “Unassign user” if the device was previously assigned to a user. If not, this option will be grayed-out and
can be ignored.
12. With the unassigned device still selected, click the Delete button along the top menu to remove this device
These steps deregister the device from Autopilot, but also unenroll the device from Intune, and disjoin the device
from Azure AD. It may appear that only deregistering the device from Autopilot is needed. However, there are
barriers in Intune that require all the steps above to avoid problems with lost or unrecoverable devices. To prevent
the possibility of orphaned devices in the Autopilot database, Intune, or Azure AD, it's best to complete all the steps.
If a device gets into an unrecoverable state, you can contact the appropriate Microsoft support alias for assistance.
The deregistration process will take about 15 minutes. You can accelerate the process by clicking the “Sync” button,
then “Refresh” the display until the device is no longer present.
More details on deregistering devices from Intune can be found here.
Deregister from MPC
To deregister an Autopilot device from the Microsoft Partner Center (MPC), a CSP would:
1. Log into MPC
2. Navigate to Customer > Devices
3. Select the device to be deregistered and click the “Delete device” button
Deregistering a device from Autopilot in MPC does only that. It doesn't do either of the following:
unenroll the device from the MDM (Intune)
disjoin the device from Azure AD
So, if possible, the OEM/CSP ideally should work with the customer IT Admin to have the device fully removed per
the Intune steps in the previous section.
Or, an OEM partner that has integrated the OEM Direct APIs can deregister a device with the
AutopilotDeviceRegistration API. Make sure the TenantID and TenantDomain fields are left blank.
Because the repair facility won't have the user’s login credentials, they'll have to reimage the device as part of the
repair process. The customer should do three things before sending the device to the facility:
1. Copy all important data off the device.
2. Let the repair facility know which version of Windows they should reinstall after the repair.
3. If applicable, let the repair facility know which version of Office they should reinstall after the repair.
Replace the motherboard

Technicians replace the motherboard (or other hardware) on the broken device. A replacement Digital Product Key
(DPK) is injected.
Repair and key replacement processes vary between facilities. Sometimes repair facilities receive motherboard
spare parts from OEMs that have replacement DPKs already injected, but sometimes not. Sometimes repair
facilities receive fully-functional BIOS tools from OEMs, but sometimes not. So, the quality of the data in the BIOS
after an MBR varies. To ensure the repaired device will still be Autopilot-capable following its repair, check to make
sure the new (post-repair) BIOS can successfully gather and populate the following information at a minimum:
DiskSerialNumber
SmbiosSystemSerialNumber
SmbiosSystemManufacturer
SmbiosSystemProductName
SmbiosUuid
TPM EKPub
MacAddress
ProductKeyID
OSType
For simplicity, and because processes vary between repair facilities, we've excluded many of the additional steps
often used in an MBR, such as:
Verify that the device is still functional
Disable BitLocker*
Repair the Boot Configuration Data (BCD)
Repair and verify the network driver operation
*BitLocker can be suspended rather than disabled if the technician can resume it after the repair.
Capture a new Autopilot device ID (4K HH) from the device

Repair technicians must sign in to the repaired device to capture the new device ID. If the repair technician doesn't
have access to the customer’s login credentials, they'll have to reimage the device to gain access:
1. The repair technician creates a WinPE bootable USB drive.
2. The repair technician boots the device to WinPE.
3. The repair technician applies a new Windows image to the device.
Ideally, the same Windows version that was originally on the device should be reimaged onto the device.
Some coordination will be required between the repair facility and customer to capture this information at
the time the device arrives for repair. Such coordination might include the customer sending the repair
facility a customized image (.ppk file) via a USB stick, for example.
4. The repair technician boots the device into the new Windows image.
5. Once on the desktop, the repair technician captures the new device ID (4K HH) off the device using either
the OA3 Tool or the PowerShell script, as described below.
Those repair facilities with access to the OA3 Tool (which is part of the ADK) can use the tool to capture the 4K
Hardware Hash (4K HH).
Instead, the WindowsAutoPilotInfo PowerShell script can be used to capture the 4K HH by following these steps:
1. Install the script from the PowerShell Gallery or from the command line (command-line installation is
shown below).
2. Navigate to the script directory and run it on the device when the device is either in Full OS or Audit Mode.
See the following example.
md c:\HWID
Set-Location c:\HWID
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Unrestricted -Force
Install-Script -Name Get-WindowsAutopilotInfo -Force
Get-WindowsAutopilotInfo.ps1 -OutputFile AutopilotHWID.csv
If you are prompted to install the NuGet package, choose Yes .

If, after installing the script you get an error that Get-WindowsAutopilotInfo.ps1 isn't found, verify that
C:\Program Files\WindowsPowerShell\Scripts is present in your PATH variable.
If the Install-Script cmdlet fails, verify that you have the default PowerShell repository registered (Get-
PSRepositor y ) or register the default repository with Register-PSRepositor y -Default -Verbose .
The script creates a .csv file that contains the device information, including the complete 4K HH. Save this file so
that you can access it later. The service facility will use this 4K HH to reregister device as described below. Be sure
to use the -OutputFile parameter when saving the file, which ensures that file formatting is correct. don't attempt
to pipe the command output to a file manually.
NOTE
If the repair facility can't run the OA3 tool or PowerShell script to capture the new 4K HH, then the CSP (or OEM) partners
must do it for them. Without some entity capturing the new 4K HH, there's no way to reregister this device as an Autopilot
device.
Reregister the repaired device using the new device ID

If an OEM can't reregister the device, you have two options:
The repair facility or CSP can reregister the device using MPC.
The customer IT Admin should reregister the device via Intune (or MSfB).
Both ways of reregistering a device are shown below.
Reregister from Intune
To reregister an Autopilot device from Intune, an IT Admin would:
1. Sign in to Intune.
2. Navigate to Device enrollment > Windows enrollment > Devices > Import.
3. Click the Impor t button to upload a csv file containing the device ID of the device to be reregistered. The device
ID was the 4K HH captured by the PowerShell script or OA3 tool described previously in this document.
The following video provides a good overview of how to (re)register devices via MSfB.
Reregister from MPC

To reregister an Autopilot device from MPC, an OEM or CSP would:
1. Sign in to MPC.
2. Navigate to the Customer > Devices page and click the Add devices button to upload the csv file.
When reregistering a repaired device through MPC, the uploaded csv file must contain the 4K HH for the device,
and not just the PKID or Tuple (SerialNumber + OEMName + ModelName). If only the PKID or Tuple was used, the
Autopilot service would be unable to find a match in the Autopilot database. No match would be found because no
4K HH info was previously submitted for this essentially “new” device. The upload will fail, likely returning a
ZtdDeviceNotFound error. So, again, only upload the 4K HH, not the Tuple or PKID.
When including the 4K HH in the csv file, you don't also need to include the PKID or Tuple. Those columns may be
left blank, as shown below:
Reset the device
The repair facility must reset the image back to a pre-OOBE state before returning it to the customer. This reset is
needed because the device was required to be in Full OS or Audit Mode to capture the 4K HH. One way to reset the
image is by using the built-in reset feature in Windows, as follows:
On the device, go to Settings > Update & Security > Recovery and click on Get started. Under Reset this PC, select
Remove everything and Just remove my files. Finally, click on Reset.
However, it’s likely the repair facility won’t have access to Windows because they lack the user credentials to sign
in. In this case they need to use other means to reimage the device, such as the Deployment Image Servicing and
Management tool.
Return the repaired device to the customer

The repaired device can now be returned to the customer. It will be auto-enrolled into the Autopilot program on
first boot-up during OOBE.
IMPORTANT
If the repair facility did NOT reimage the device, they could be sending it back in a potentially broken state. For example,
there’s no way to log into the device because it’s been dissociated from the only known user account. So, they should tell the
organization that they need to fix the registration and OS themselves. A device can be “registered” for Autopilot before being
powered-on. But the device isn’t actually “deployed” to Autopilot until it goes through OOBE. Therefore, resetting the device
back to a pre-OOBE state is a required step.
Specific repair scenarios

This section covers the most common repair scenarios, and their impact on Autopilot enablement.
NOTES ON TEST RESULTS:
Scenarios below were tested using Intune only (no other MDMs were tested).
In most test scenarios below, the repaired and reregistered device needed to go through OOBE again for
Autopilot to be enabled.
Motherboard replacement scenarios often result in lost data. Repair centers or customers should be reminded
to back up data (if possible) before repair.
When a repair facility can't write device info into the BIOS of the repaired device, new processes need to be
created to successfully enable Autopilot.
Repaired device should have the Product Key (DPK) preinjected in the BIOS before capturing the new 4K HH
(device ID)
In the following table:
Supported = Yes : the device can be reenabled for Autopilot
Supported = No : the device can't be reenabled for Autopilot
SC EN A RIO SUP P O RT ED M IC RO SO F T REC O M M EN DAT IO N
Motherboard Replacement (MBR) in Yes The recommended course of action for

general MBR scenarios is:
1. Autopilot device is deregistered
from the Autopilot program
2. The motherboard is replaced
3. The device is reimaged (with
BIOS info and DPK reinjected)*
4. A new Autopilot device ID (4K
HH) is captured off the device
5. The repaired device is
reregistered for the Autopilot
program using the new device
ID
6. The repaired device is reset to
boot to OOBE
7. The repaired device is shipped
back to the customer
*It’s not necessary to reimage the
device if the repair technician has
access to the customer’s login
credentials. It’s technically possible
to successfully re-enable MBR and
Autopilot without keys or certain
BIOS info (like serial #, model name,
and so on). But doing so is only
recommended for
testing/educational purposes.
MBR when motherboard has a TPM Yes 1. Deregister damaged device

chip (enabled) and only one onboard 2. Replace motherboard
network card (that also gets replaced) 3. Reimage device (to gain access),
unless you have access to
customers’ login credentials
4. Write device info into BIOS
5. Capture new 4K HH
6. Reregister repaired device
7. Reset device back to OOBE
8. Go through Autopilot OOBE
(customer)
9. Autopilot successfully enabled
MBR when motherboard has a TPM No This scenario breaks the Autopilot
chip (enabled) and a second network experience. The resulting Device ID
card (or network interface) that isn't won't be stable until after TPM
replaced along with the motherboard attestation has completed. Even then
registration may give incorrect results
because of ambiguity with MAC
Address resolution. Therefore, we don't
recommend this scenario.
MBR where the NIC card, HDD, and Yes 1. Deregister damaged device
WLAN all remain the same after the 2. Replace motherboard with a new
repair Replacement Digital Product Key
(RDPK) preinjected in BIOS
3. Reimage device (to gain access),
4. Write old device info into BIOS
(same s/n, model, and so on)*
(customer)
*For this and later scenarios,
rewriting old device info wouldn't
include the TPM 2.0 endorsement
key, as the associated private key is
locked to the TPM device
MBR where the NIC card remains the Yes 1. Deregister damaged device
same, but the HDD and WLAN are 2. Replace motherboard (with new
replaced RDPK preinjected in BIOS)
3. Insert new HDD and WLAN
(same s/n, model, and so on)
(customer)
MBR where the NIC card and WLAN Yes 1. Deregister damaged device
remains the same, but the HDD is 2. Replace motherboard (with new
replaced RDPK preinjected in BIOS)
3. Insert new HDD
(customer)
MBR where only the MB is replaced (all Yes 1. Deregister damaged device
other parts remain same). The new MB 2. Replace motherboard (with new
was taken from a previously used RDPK preinjected in BIOS)
device that had never been enabled for 3. Reimage device (to gain access),
Autopilot. unless you have access to
(customer)
MBR where only the MB is replaced (all Yes 1. Deregister old device from which
other parts remain same). The new MB MB will be taken
was taken from a previously used 2. Deregister damaged device (that
device that HAD been Autopilot- you want to repair)
enabled before. 3. Replace motherboard in repair
device with MB from other
Autopilot device (with new RDPK
preinjected in BIOS)
(customer)
The repaired device can also be
used successfully as a normal, non-
Autopilot device.
BIOS info excluded from MBR device No Repair facility doesn't have BIOS tool to
write device info into BIOS after MBR.
1. Deregister damaged device
2. Replace motherboard (BIOS
does NOT contain device info)
3. Reimage and write DPK into
image
6. Create Autopilot profile for
device
(customer)
8. Autopilot FAILS to recognize
repaired device
MBR when there's no TPM chip Yes We don't recommend enabling
Autopilot devices without a TPM chip
(which is recommended for BitLocker
encryption). However, it's possible to
enable an Autopilot device in “standard
user” mode (but NOT Self-deploying
mode) that doesn't have a TPM chip. In
this case, you would:
2. Replace motherboard
(customer)
New DPK written into image on Yes Repair facility replaces normal MB on
repaired Autopilot device with a new damaged device. MB doesn't contain
MB any DPK in the BIOS. Repair facility
writes DPK into image after MBR.
2. Replace motherboard – BIOS
does NOT contain DPK info
6. Reset or reimage device to pre-
OOBE and write DPK into image
New Repair Product Key (RDPK) Yes Using a motherboard with a new RDPK
preinjected results in a successful
Autopilot refurbishment scenario.
2. Replace motherboard (with new
RDPK preinjected in BIOS)
3. Reimage or rest image to pre-
OOBE
7. Reimage or reset image to pre-
OOBE
No Repair Product Key (RDPK) injected No This scenario violates Microsoft policy
and breaks the Windows Autopilot
experience.
Reimage damaged Autopilot device that Yes, but the device will still be 1. Reimage damaged device
wasn't deregistered before repair associated with previous tenant ID, so 2. Write DPK into image
should only be returned to same 3. Go through Autopilot OOBE
customer 4. Autopilot successfully enabled
(to previous tenant ID)
Disk replacement from a non-Autopilot Yes 1. don't deregister damaged device

device to an Autopilot device before repair
2. Replace HDD on damaged
device
3. Reimage or reset image back to
OOBE
(customer)
(repaired device recognized as
its previous self)
Disk replacement from one Autopilot Maybe If the device from which the HDD is
device to another Autopilot device taken was itself previously deregistered
from Autopilot, then that HDD can be
used in a repair device. The newly
repaired device won't have the proper
Autopilot experience if the HDD wasn't
previously deregistered from Autopilot
before being used in the repaired
device.
Assuming the used HDD was
previously deregistered (before
being used in this repair):
2. Replace HDD on damaged
device using an HDD from
another deregistered Autopilot
device
3. Reimage or rest the repaired
device back to a pre-OOBE state
(customer)
Non-Microsoft network card No Any scenario where a third party (not
replacement onboard) network card is replaced will
break the Autopilot experience. This
includes any of the following scenarios:
from a non-Autopilot device to
an Autopilot device
from one Autopilot device to
another Autopilot device
from an Autopilot device to a
non-Autopilot device
We don't recommend any of these
scenarios.
A device repaired more than three No Autopilot isn't supported when a device
times is repeatedly repaired. Parts NOT
replaced become associated with too
many parts that have been replaced.
This makes it difficult to uniquely
identify that device in the future.
Memory replacement Yes Replacing the memory on a damaged

device doesn't negatively affect the
Autopilot experience on that device. No
de/reregistration is needed. The repair
technician simply needs to replace the
memory.
GPU replacement Yes Replacing the GPU(s) on a damaged

device doesn't negatively affect the
Autopilot experience on that device. No
de/reregistration is needed. The repair
technician simply needs to replace the
GPU.
When scavenging parts from another Autopilot device, we recommend unregistering the scavenged device
from Autopilot, scavenging it, and then NEVER REGISTERING THE SCAVENGED DEVICE (AGAIN) FOR
AUTOPILOT, because reusing parts this way may cause two active devices to end up with the same ID, with no
possibility of distinguishing between the two.
The following parts may be replaced without compromising Autopilot enablement or requiring special additional
repair steps:
Memory (RAM or ROM)
Power Supply
Video Card
Card Reader
Sound card
Expansion card
Microphone
Webcam
Fan
Heat sink
CMOS battery
Other repair scenarios not yet tested and verified include:
Daughterboard replacement
CPU replacement
Wifi replacement
Ethernet replacement
FAQ
We have a tool that programs product information into the No. Not if the in-house tool writes the minimum necessary
BIOS after the MBR. Do we still need to submit a CBR report information into the BIOS that the Autopilot program looks
for the device to be Autopilot-capable? for to identify the device, as described earlier in this
document.
What if only some components are replaced rather than the It’s true that some limited repairs don't prevent the Autopilot
full motherboard? algorithm from successfully matching the post-repair device
with the pre-repair device. Even so, it's best to ensure 100%
success by going through the MBR steps above even for
devices that only needed limited repairs.
How does a repair technician gain access to a broken device if The technician will have to reimage the device and use their
they don’t have the customer’s login credentials? own credentials during the repair process.
Related topics
Device guidelines

Windows Autopilot DEPLOYMENT

Uploaded by

Copyright:

Available Formats

Windows Autopilot DEPLOYMENT

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Windows Autopilot DEPLOYMENT

Uploaded by

Copyright:

Available Formats

What are the different deployment scenarios for Windows Autopilot?

What are the different deployment scenarios for Windows Autopilot?

What are some of the new features introduced in Windows Autopilot version 1903?

What are some of the new features introduced in Windows Autopilot version 1903?

Contents

Windows Autopilot deployment

Windows Autopilot update history

New in Windows 10, version 2004

New in Windows 10, version 1903

Also new in this version of Windows:

New in Windows 10, version 1809

Benefits of Windows Autopilot

Applies to: Windows 10

Redeploy a device in a business-ready state. Windows Autopilot Reset

Preprovision a device with up-to-date applications, policies, White glove

These scenarios are summarized in the following video.

Windows Autopilot capabilities

0 Cortana voiceover is disabled

1 Cortana voiceover is enabled

No value Device will fall back to default behavior of the edition

Applies to: Windows 10, version 1809 or later

User-driven mode for Azure Active Directory join

User-driven mode for hybrid Azure Active Directory join

Applies to: Windows 10, version 1903 or later

Reset devices with local Windows Autopilot Reset

Reset devices with remote Windows Autopilot Reset

Applies to: Windows 10, version 1903

If the pre-provisioning process fails:

Applies to: Windows 10

Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force

3. Enter the following lines and provide Intune administrative credentials

PS C:\> Get-AutopilotProfile | ConvertTo-AutopilotConfigurationJSON

P RO P ERT Y DESC RIP T IO N

Get-AutopilotProfile | ConvertTo-AutopilotConfigurationJSON | Out-File

IMPORTANT : The file name must be named AutopilotConfigurationFile.json in addition to being

Create a package containing the JSON file

4. Click Next , then enter the following Membership Rules details:

1. In the Configuration Manager console, navigate to \Software Librar y\Over view\Operating

25. Click OK to close the Task Sequence Editor.

Deploy Content to Distribution Points

Register the device for Windows Autopilot

Speeding up the deployment process

Applies to: Windows 10

Applies to: Windows 10

Windows Activation Windows Autopilot requires Windows Activation services. For

Intune Once authenticated, Azure Active Directory will trigger enrollment

Microsoft 365 As part of the Intune device configuration, installation of Microsoft

Applies to: Windows 10

Additionally, the following are also recommended (but not required):

Applies to: Windows 10

Reseller, distributor, or partner registration

Collecting the hardware hash from existing devices using PowerShell

Platform/Por tal Register devices? Create/Assign profile Acceptable DeviceID

OEM Direct API YES - 1000 at a time max NO Tuple or PKID

Partner Center YES - 1000 at a time max YES3 4 Tuple or PKID or 4K HH

Intune YES - 500 at a time max1 YES1 2 4K HH

Microsoft Store for Business YES - 1000 at a time max YES4 4K HH

Microsoft 365 Business YES - 1000 at a time max YES3 4K HH

1 Microsoft recommended platform to use

How to get the CSV for Import in Intune