deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-06-15 02:13:43 +00:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity

fixed merge conflicts from private repo

Browse Source
This commit is contained in:
Liza Poggemeyer
2019-08-09 14:48:50 -07:00
parent 383e9a87f8 5724ed3ec3
commit ccad36495e
691 changed files with 52440 additions and 52369 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
windows/deployment/windows-autopilot/TOC.md
View File

@ -26,4 +26,4 @@
## [Contacts](autopilot-support.md)
## [Registration authorization](registration-auth.md)
## [Device guidelines](autopilot-device-guidelines.md)
## [Motherboard replacement](autopilot-mbr.md)
## [Motherboard replacement](autopilot-mbr.md)

324
windows/deployment/windows-autopilot/add-devices.md
View File

@ -1,162 +1,162 @@
---
title: Adding devices
ms.reviewer:
manager: laurawi
description: How to add devices to Windows Autopilot
keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: medium
ms.sitesec: library
ms.pagetype: deploy
author: greg-lindsay
ms.author: greglin
ms.collection: M365-modern-desktop
ms.topic: article
---
# 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 would be performed by the OEM, reseller, or distributor from which the devices were purchased, but this can also be done by the organization by collecting the hardware identity and uploading it manually.
## OEM registration
When you purchase devices directly from an OEM, that OEM can automatically register the devices with the Windows Autopilot deployment service. For the list of OEMs that currently support this, see the "Participant device manufacturers" section of the [Windows Autopilot information page](https://www.microsoft.com/en-us/windowsforbusiness/windows-autopilot).
Before an OEM can register devices on behalf of an organization, the organization must grant the OEM permission to do so. This process is initiated by the OEM, with approval granted by an Azure AD global administrator from the organization. See the "Customer Consent" section of the [Customer consent page](https://docs.microsoft.com/windows/deployment/windows-autopilot/registration-auth#oem-authorization).
## 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](https://partner.microsoft.com/en-us/cloud-solution-provider), they too can register devices on behalf of the customer.
As with OEMs, CSP parnters must be granted permission to register devices on behalf of an organization. This follows the process described on the [Customer consent page](https://docs.microsoft.com/windows/deployment/windows-autopilot/registration-auth#csp-authorization). The CSP partner initiates a request to establish a relationship with the organization, with approval granted by a global administrator from the organization. Once approved, CSP partners add devices using [Partner Center](https://partner.microsoft.com/en-us/pcv/dashboard/overview), either directly through the web site or via available APIs that can automate the same tasks.
Windows Autopilot does not require delegated administrator permissions when establishing the relationship between the CSP partner and the organization. As part of the approval process performed by the global administrator, the global administrator can choose to uncheck the "Include delegated administration permissions" checkbox.
## Automatic registration of existing devices
If an existing device is already running Windows 10 version 1703 or later and enrolled in an MDM service such an Intune, that MDM service can ask the device for the hardware ID (also known as a hardware hash). Once 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](https://docs.microsoft.com/intune/enrollment-autopilot#create-an-autopilot-deployment-profile) documentation describing the "Convert all targeted devices to Autopilot" setting.
Also note that when using the [Windows Autopilot for existing devices](https://docs.microsoft.com/windows/deployment/windows-autopilot/existing-devices) scenario, it is not necessary 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 be registered with Windows Autopilot after the fact using the same "Convert all targeted devices to Autopilot" setting.
## Manual registration
To perform manual registration of a device, you must first capture its hardware ID (also known as a hardware hash). Once this process has completed, the resulting hardware ID can be uploaded to the Windows Autopilot service. Because this process requires booting the device into Windows 10 in order to obtain the hardware ID, this is intended primarily for testing and evaluation scenarios.
## Device identification
To define a device to the Windows Autopilot deployment service, a unique hardware ID for the device needs to be captured and uploaded to the service. While this step is ideally done by the hardware vendor (OEM, reseller, or distributor), automatically associating the device with an organization, it is also possible to do this through a harvesting process that collects the device from within a running Windows 10 version 1703 or later installation.
The hardware ID, also commonly referred to as a hardware hash, contains several details about the device, including its manufacturer, model, device serial number, hard drive serial number, and many other attributes that can be used to uniquely identify that device.
Note that the hardware hash also contains details about when it was generated, so it will change each time it is generated. When the Windows Autopilot deployment service attempts to match a device, it considers changes like that, as well as more substantial changes such as a new hard drive, and is still able to match successfully. But substantial changes to the hardware, such as a motherboard replacement, would not match, so a new hash would need to be generated and uploaded.
### Collecting the hardware ID from existing devices using System Center Configuration Manager
Starting with System Center Configuration Manager current branch version 1802, the hardware hashes for existing Windows 10 version 1703 and higher devices are automatically collected by Configuration Manager. See the [What’s new in version 1802](https://docs.microsoft.com/sccm/core/plan-design/changes/whats-new-in-version-1802#report-on-windows-autopilot-device-information) documentation for more details. The hash information can be extracted from Configuration Manager into a CSV file.
### Collecting the hardware ID from existing devices using PowerShell
The hardware ID, or hardware hash, for an existing device is available through Windows Management Instrumentation (WMI), as long as that device is running Windows 10 version 1703 or later. To help gather this information, as well as the serial number of the device (useful to see at a glance the machine to which it belongs), a PowerShell script called [Get-WindowsAutoPilotInfo.ps1 has been published to the PowerShell Gallery website](https://www.powershellgallery.com/packages/Get-WindowsAutoPilotInfo).
To use this script, you can download it from the PowerShell Gallery and run it on each computer, or you can 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:
```powershell
md c:\\HWID
Set-Location c:\\HWID
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Unrestricted
Install-Script -Name Get-WindowsAutoPilotInfo
Get-WindowsAutoPilotInfo.ps1 -OutputFile AutoPilotHWID.csv
```
The commands can also be run remotely, as long as WMI permissions are in place and WMI is accessible through the Windows Firewall on that remote computer. See the [Get-WindowsAutoPilotInfo](https://www.powershellgallery.com/packages/Get-WindowsAutoPilotInfo) script’s help (using “Get-Help Get-WindowsAutoPilotInfo.ps1”) for more information about running the script.
>[!IMPORTANT]
>Do not connect devices to the Internet prior to capturing the hardware ID and creating an Autopilot device profile. This includes collecting the hardware ID, 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 is 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**. <br>
>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: <br>
>**HKCU\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\UserOOBE** <br>
>To ensure OOBE has not been restarted too many times, you can change this value to 1.
## Registering devices
<img src="./images/image2.png" width="511" height="249" />
Once the hardware IDs have been captured from existing devices, they can be uploaded through a variety of means. See the detailed documentation for each available mechanism.
- [Microsoft Intune](https://docs.microsoft.com/intune/enrollment-autopilot). This is the preferred mechanism for all customers.
- [Partner Center](https://msdn.microsoft.com/partner-center/autopilot). This is used by CSP partners to register devices on behalf of customers.
- [Microsoft 365 Business & Office 365 Admin](https://support.office.com/article/Create-and-edit-AutoPilot-profiles-5cf7139e-cfa1-4765-8aad-001af1c74faa). This is typically used by small and medium businesses (SMBs) who manage their devices using Microsoft 365 Business.
- [Microsoft Store for Business](https://docs.microsoft.com/microsoft-store/add-profile-to-devices#manage-autopilot-deployment-profiles). You might already be using MSfB to manage your apps and settings.
A summary of each platform's capabilities is provided below.
<table>
<tr>
<td BGCOLOR="#a0e4fa"><B>Platform/Portal</th>
<td BGCOLOR="#a0e4fa"><B>Register devices?</th>
<td BGCOLOR="#a0e4fa"><B>Create/Assign profile</th>
<td BGCOLOR="#a0e4fa"><B>Acceptable DeviceID</th>
</tr>
<tr>
<td>OEM Direct API</td>
<td>YES - 1000 at a time max</td>
<td>NO</td>
<td>Tuple or PKID</td>
</tr>
<tr>
<td><a href="https://docs.microsoft.com/partner-center/autopilot">Partner Center</a></td>
<td>YES - 1000 at a time max</td>
<td>YES</td>
<td>Tuple or PKID or 4K HH</td>
</tr>
<tr>
<td><a href="https://docs.microsoft.com/intune/enrollment-autopilot">Intune</a></td>
<td>YES - 500 at a time max<b>\*</b></td>
<td>YES<b>\*</b></td>
<td>4K HH</td>
</tr>
<tr>
<td><a href="https://docs.microsoft.com/microsoft-store/add-profile-to-devices#manage-autopilot-deployment-profiles">Microsoft Store for Business</a></td>
<td>YES - 1000 at a time max</td>
<td>YES</td>
<td>4K HH</td>
</tr>
<tr>
<td><a href="https://docs.microsoft.com/microsoft-365/business/create-and-edit-autopilot-profiles">Microsoft Business 365</a></td>
<td>YES - 1000 at a time max</td>
<td>YES</td>
<td>4K HH</td>
</tr>
</table>
><b>*</b>Microsoft recommended platform to use
## Summary
When deploying new devices using Windows Autopilot, the following steps are required:
1. [Register devices](#registering-devices). Ideally, this step is performed by the OEM, reseller, or distributor from which the devices were purchased, but this can also be done by the organization by collecting the hardware identity and uploading it manually.
2. [Configure device profiles](profiles.md), specifying how the device should be deployed and what user experience should be presented.
3. Boot the device. When 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, and if it is, it will download profile settings such as the [Enrollment Status page](enrollment-status.md), which are used to customize the end user experience.
## Other configuration settings
- [Bitlocker encryption settings](bitlocker.md): You can configure the BitLocker encryption settings to be applied before automatic encryption is started.
---
title: Adding devices
ms.reviewer:
manager: laurawi
description: How to add devices to Windows Autopilot
keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: medium
ms.sitesec: library
ms.pagetype: deploy
audience: itpro
author: greg-lindsay
ms.author: greglin
ms.collection: M365-modern-desktop
ms.topic: article
---
# 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 would be performed by the OEM, reseller, or distributor from which the devices were purchased, but this can also be done by the organization by collecting the hardware identity and uploading it manually.
## OEM registration
When you purchase devices directly from an OEM, that OEM can automatically register the devices with the Windows Autopilot deployment service. For the list of OEMs that currently support this, see the "Participant device manufacturers" section of the [Windows Autopilot information page](https://www.microsoft.com/en-us/windowsforbusiness/windows-autopilot).
Before an OEM can register devices on behalf of an organization, the organization must grant the OEM permission to do so. This process is initiated by the OEM, with approval granted by an Azure AD global administrator from the organization. See the "Customer Consent" section of the [Customer consent page](https://docs.microsoft.com/windows/deployment/windows-autopilot/registration-auth#oem-authorization).
## 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](https://partner.microsoft.com/en-us/cloud-solution-provider), they too can register devices on behalf of the customer.
As with OEMs, CSP parnters must be granted permission to register devices on behalf of an organization. This follows the process described on the [Customer consent page](https://docs.microsoft.com/windows/deployment/windows-autopilot/registration-auth#csp-authorization). The CSP partner initiates a request to establish a relationship with the organization, with approval granted by a global administrator from the organization. Once approved, CSP partners add devices using [Partner Center](https://partner.microsoft.com/en-us/pcv/dashboard/overview), either directly through the web site or via available APIs that can automate the same tasks.
Windows Autopilot does not require delegated administrator permissions when establishing the relationship between the CSP partner and the organization. As part of the approval process performed by the global administrator, the global administrator can choose to uncheck the "Include delegated administration permissions" checkbox.
## Automatic registration of existing devices
If an existing device is already running Windows 10 version 1703 or later and enrolled in an MDM service such an Intune, that MDM service can ask the device for the hardware ID (also known as a hardware hash). Once 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](https://docs.microsoft.com/intune/enrollment-autopilot#create-an-autopilot-deployment-profile) documentation describing the "Convert all targeted devices to Autopilot" setting.
Also note that when using the [Windows Autopilot for existing devices](https://docs.microsoft.com/windows/deployment/windows-autopilot/existing-devices) scenario, it is not necessary 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 be registered with Windows Autopilot after the fact using the same "Convert all targeted devices to Autopilot" setting.
## Manual registration
To perform manual registration of a device, you must first capture its hardware ID (also known as a hardware hash). Once this process has completed, the resulting hardware ID can be uploaded to the Windows Autopilot service. Because this process requires booting the device into Windows 10 in order to obtain the hardware ID, this is intended primarily for testing and evaluation scenarios.
## Device identification
To define a device to the Windows Autopilot deployment service, a unique hardware ID for the device needs to be captured and uploaded to the service. While this step is ideally done by the hardware vendor (OEM, reseller, or distributor), automatically associating the device with an organization, it is also possible to do this through a harvesting process that collects the device from within a running Windows 10 version 1703 or later installation.
The hardware ID, also commonly referred to as a hardware hash, contains several details about the device, including its manufacturer, model, device serial number, hard drive serial number, and many other attributes that can be used to uniquely identify that device.
Note that the hardware hash also contains details about when it was generated, so it will change each time it is generated. When the Windows Autopilot deployment service attempts to match a device, it considers changes like that, as well as more substantial changes such as a new hard drive, and is still able to match successfully. But substantial changes to the hardware, such as a motherboard replacement, would not match, so a new hash would need to be generated and uploaded.
### Collecting the hardware ID from existing devices using System Center Configuration Manager
Starting with System Center Configuration Manager current branch version 1802, the hardware hashes for existing Windows 10 version 1703 and higher devices are automatically collected by Configuration Manager. See the [What’s new in version 1802](https://docs.microsoft.com/sccm/core/plan-design/changes/whats-new-in-version-1802#report-on-windows-autopilot-device-information) documentation for more details. The hash information can be extracted from Configuration Manager into a CSV file.
### Collecting the hardware ID from existing devices using PowerShell
The hardware ID, or hardware hash, for an existing device is available through Windows Management Instrumentation (WMI), as long as that device is running Windows 10 version 1703 or later. To help gather this information, as well as the serial number of the device (useful to see at a glance the machine to which it belongs), a PowerShell script called [Get-WindowsAutoPilotInfo.ps1 has been published to the PowerShell Gallery website](https://www.powershellgallery.com/packages/Get-WindowsAutoPilotInfo).
To use this script, you can download it from the PowerShell Gallery and run it on each computer, or you can 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:
```powershell
md c:\\HWID
Set-Location c:\\HWID
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Unrestricted
Install-Script -Name Get-WindowsAutoPilotInfo
Get-WindowsAutoPilotInfo.ps1 -OutputFile AutoPilotHWID.csv
```
The commands can also be run remotely, as long as WMI permissions are in place and WMI is accessible through the Windows Firewall on that remote computer. See the [Get-WindowsAutoPilotInfo](https://www.powershellgallery.com/packages/Get-WindowsAutoPilotInfo) script’s help (using “Get-Help Get-WindowsAutoPilotInfo.ps1”) for more information about running the script.
>[!IMPORTANT]
>Do not connect devices to the Internet prior to capturing the hardware ID and creating an Autopilot device profile. This includes collecting the hardware ID, 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 is 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**. <br>
>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: <br>
>**HKCU\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\UserOOBE** <br>
>To ensure OOBE has not been restarted too many times, you can change this value to 1.
## Registering devices
<img src="./images/image2.png" width="511" height="249" />
Once the hardware IDs have been captured from existing devices, they can be uploaded through a variety of means. See the detailed documentation for each available mechanism.
- [Microsoft Intune](https://docs.microsoft.com/intune/enrollment-autopilot). This is the preferred mechanism for all customers.
- [Partner Center](https://msdn.microsoft.com/partner-center/autopilot). This is used by CSP partners to register devices on behalf of customers.
- [Microsoft 365 Business & Office 365 Admin](https://support.office.com/article/Create-and-edit-AutoPilot-profiles-5cf7139e-cfa1-4765-8aad-001af1c74faa). This is typically used by small and medium businesses (SMBs) who manage their devices using Microsoft 365 Business.
- [Microsoft Store for Business](https://docs.microsoft.com/microsoft-store/add-profile-to-devices#manage-autopilot-deployment-profiles). You might already be using MSfB to manage your apps and settings.
A summary of each platform's capabilities is provided below.
<table>
<tr>
<td BGCOLOR="#a0e4fa"><B>Platform/Portal</th>
<td BGCOLOR="#a0e4fa"><B>Register devices?</th>
<td BGCOLOR="#a0e4fa"><B>Create/Assign profile</th>
<td BGCOLOR="#a0e4fa"><B>Acceptable DeviceID</th>
</tr>
<tr>
<td>OEM Direct API</td>
<td>YES - 1000 at a time max</td>
<td>NO</td>
<td>Tuple or PKID</td>
</tr>
<tr>
<td><a href="https://docs.microsoft.com/partner-center/autopilot">Partner Center</a></td>
<td>YES - 1000 at a time max</td>
<td>YES</td>
<td>Tuple or PKID or 4K HH</td>
</tr>
<tr>
<td><a href="https://docs.microsoft.com/intune/enrollment-autopilot">Intune</a></td>
<td>YES - 500 at a time max<b>\*</b></td>
<td>YES<b>\*</b></td>
<td>4K HH</td>
</tr>
<tr>
<td><a href="https://docs.microsoft.com/microsoft-store/add-profile-to-devices#manage-autopilot-deployment-profiles">Microsoft Store for Business</a></td>
<td>YES - 1000 at a time max</td>
<td>YES</td>
<td>4K HH</td>
</tr>
<tr>
<td><a href="https://docs.microsoft.com/microsoft-365/business/create-and-edit-autopilot-profiles">Microsoft Business 365</a></td>
<td>YES - 1000 at a time max</td>
<td>YES</td>
<td>4K HH</td>
</tr>
</table>
><b>*</b>Microsoft recommended platform to use
## Summary
When deploying new devices using Windows Autopilot, the following steps are required:
1. [Register devices](#registering-devices). Ideally, this step is performed by the OEM, reseller, or distributor from which the devices were purchased, but this can also be done by the organization by collecting the hardware identity and uploading it manually.
2. [Configure device profiles](profiles.md), specifying how the device should be deployed and what user experience should be presented.
3. Boot the device. When 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, and if it is, it will download profile settings such as the [Enrollment Status page](enrollment-status.md), which are used to customize the end user experience.
## Other configuration settings
- [Bitlocker encryption settings](bitlocker.md): You can configure the BitLocker encryption settings to be applied before automatic encryption is started.

6
windows/deployment/windows-autopilot/autopilot-device-guidelines.md
View File

@ -4,12 +4,12 @@ ms.reviewer:
manager: laurawi
description: Windows Autopilot deployment
keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune
audience: itpro
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: medium
ms.sitesec: library
ms.pagetype: deploy
audience: itpro
author: greg-lindsay
ms.author: greglin
ms.collection: M365-modern-desktop
@ -29,8 +29,8 @@ All devices used with Windows Autopilot should meet the [minimum hardware requir
The following additional best practices ensure that devices can easily be provisioned by organizations as part of the Windows Autopilot deployment process:
- Ensure that the TPM 2.0 is enabled and in a good state (not in Reduced Functionality Mode) by default on devices intended for Windows Autopilot self-deploying mode.
- The OEM provisions unique tuple info (SmbiosSystemManufacturer, SmbiosSystemProductName, SmbiosSystemSerialNumber) into the [SMBIOS fields](https://docs.microsoft.com/windows-hardware/drivers/bringup/smbios) per Microsoft specification (Manufacturer, Product Name and Serial Number stored in SMBIOS Type 1 04h, Type 1 05h and Type 1 07h).
- The OEM uploads 4K Hardware Hashes that include the Product Key IDs (PKIDs) obtained using OA3 Tool RS3+ run in Audit mode on full OS to Microsoft via CBR report prior to shipping devices to an Autopilot customer or channel partner.
- The OEM provisions unique tuple info (SmbiosSystemManufacturer, SmbiosSystemProductName, SmbiosSystemSerialNumber) or PKID + SmbiosSystemSerialNumber into the [SMBIOS fields](https://docs.microsoft.com/windows-hardware/drivers/bringup/smbios) per Microsoft specification (Manufacturer, Product Name and Serial Number stored in SMBIOS Type 1 04h, Type 1 05h and Type 1 07h).
- The OEM uploads 4K Hardware Hashes obtained using OA3 Tool RS3+ run in Audit mode on full OS to Microsoft via CBR report prior to shipping devices to an Autopilot customer or channel partner.
- As a best practice, Microsoft requires that OEM shipping drivers are published to Windows Update within 30 days of the CBR being submitted, and 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.

328
windows/deployment/windows-autopilot/autopilot-faq.md
View File

@ -1,164 +1,164 @@
---
title: Windows Autopilot support
ms.reviewer:
manager: laurawi
description: Support information for Windows Autopilot
keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: low
ms.sitesec: library
ms.pagetype: deploy
author: greg-lindsay
ms.author: greglin
ms.collection: M365-modern-desktop
ms.topic: article
---
# Windows Autopilot FAQ
**Applies to: Windows 10**
This topic provides OEMs, partners, administrators, and end-users with answers to some frequently asked questions about deploying Windows 10 with Windows Autopilot.
A [glossary](#glossary) of abbreviations used in this topic is provided at the end.
## Microsoft Partner Center
| Question | Answer |
| --- | --- |
| In the Partner Center, does the Tenant ID need to be provided with every device file upload? Is this needed to allow the business customer to access their devices in MSfB? | No. Providing the Tenant ID is a one-time entry in the Partner Center that can be re-used with future device uploads. |
| How does the customer or tenant know that their devices are ready to be claimed in MSfB? | After the device file upload is completed in the Partner Center, the tenant can see the devices available for Windows Autopilot setup in MSfB. The OEM would need to advise the tenant to access MSfB. Auto-notification from MSfB to the tenant is being developed. |
| How does a customer authorize an OEM or Channel Partner to register Autopilot devices on the customer’s behalf? | Before an OEM or Channel Partner can register a device for 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, which directs the customer to a consent page in Microsoft Store for Business. The steps explaining this process are [here](registration-auth.md). |
| Are there any restrictions if a business customer has registered devices in MSfB and later wants those devices to be managed by a CSP via the Partner Center? | The devices will need to be deleted in MSfB by the business customer before the CSP can upload and manage them in the Partner Center. |
| Does Windows Autopilot support removing the option to enable a local administrator account? | Windows Autopilot doesn’t support removing the local admin account. However, it does support restricting the user performing AAD domain join in OOBE to a standard account (versus admin account by default).|
| How can I test the Windows Autopilot CSV file in the Partner Center? | Only CSP Partners have access to the Partner Center portal. If you are a CSP, you can create a Sales agent user account which has access to “Devices” for testing the file. This can be done today in the Partner Center. <br><br>Go [here](https://msdn.microsoft.com/partner-center/create-user-accounts-and-set-permissions) for more information. |
| Must I become a Cloud Solution Provider (CSP) to participate in Windows Autopilot? | Top volume OEMs do not, as they can 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 it comes to Windows Autopilot? | For purposes of Windows Autopilot, there are three different types of CSPs, each with different levels of authority an access: <br><br>1. <b>Direct CSP</b>: Gets direct authorization from the customer to register devices. <br><br>2. <b>Indirect CSP Provider</b>: 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. <br><br>3. <b>Indirect CSP Reseller</b>: 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. |
## Manufacturing
| Question | Answer |
| --- | --- |
| What changes need to be made in the factory OS image for customer configuration settings? |No changes are required on the factory floor to enable Windows Autopilot deployment. |
| What version of the OA3 tool meets Windows Autopilot deployment requirements? | Windows Autopilot can work with any version of the OA3 tool. We recommend using Windows 10, version 1703 and above to generate the 4K Hardware Hash. |
| At the time of placing an order, do customers need to be state whether they want it with or without Windows Autopilot options? | Yes, if they want Windows Autopilot, they will want Windows 10, version 1703 or later versions. Also, they will want to receive the CSV file or have the file upload (i.e., registration) completed on their behalf. |
| Does the OEM need to manage or collect any custom imaging files from customers and perform any image uploads to Microsoft? | No change, OEMs just send the CBRs as usual to Microsoft. No images are sent to Microsoft to enable Windows Autopilot. Windows Autopilot only customizes OOBE and allows policy configurations (disables admin account, for example). |
| Are there any customer impacts to upgrading from Windows 8 to Windows 10? | The devices must have Windows 10, version 1703 or later to enroll in Windows Autopilot deployment, otherwise no impacts. |
| Will there be any change to the existing CBR with 4k Hardware Hash? | No. |
| What new information needs to be sent from the OEM to Microsoft? | Nothing, unless the OEM opts to register the device on the customer’s behalf, in which case they would upload the device ID via 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 Windows Autopilot Deployment? | No. |
## CSV schema
| Question | Answer |
| --- | --- |
| Can a comma be used in the CSV file? | No. |
| What error messages can a user expect to see in the Partner Center or MSfB when uploading a file? | See the “In Microsoft Store for Business” section of this guide. |
| Is there a limit to the number of devices that can be listed in the CSV file? | Yes, the CSV file can only contain 1,000 devices to apply to a 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 should provide the CSV file to their customers? | Microsoft recommends encrypting the CSV file when sending to the business customer to self-register their Windows Autopilot devices (either through MPC, MSfB, or Intune). |
## Hardware hash
| Question | Answer |
| --- | --- |
| Must every Hardware Hash submitted by the OEM contain the SMBIOS UUID (universally unique identifier), MAC (media access control) address and unique disk serial number (if using Windows 10, version 1703 and above OEM Activation 3.0 tool)? | Yes. Since Windows Autopilot is based on the ability to uniquely identify devices applying for cloud configuration, it is critical to submit Hardware Hashes which meet the outlined requirement. |
| What is the reason for needing the SMBIOS UUID, MAC Address and Disk Serial Number in the Hardware Hash details? | For creating the Hardware Hash, these are the fields that are needed to identify a device, as parts of the device are added/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 Hash, and Windows Autopilot Hardware Hash? | None. They’re different names for the same thing. The Windows 10, 1703 version of the OA3 tool output is called the OA3 Hash, which is 4K in size, which is usable for the Windows Autopilot deployment scenario. Note: When using a non-1703 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/or repair for the NIC (network interface controller) and/or Disk? Will the Hardware Hash become invalid? | Yes. If you replace parts, you need to gather the new Hardware Hash, though it depends on what is replaced, and the characteristics of the parts. For example, if you replace the TPM or motherboard, it’s a new device – 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 Microsoft’s strong recommendation any time you replace parts. |
## Motherboard replacement
| Question | Answer |
| --- | --- |
| How does Autopilot handle motherboard replacement scenarios?” | Motherboard replacement is out for scope for Autopilot. Any 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. <br><br>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 HH (or device ID). <br><br>**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 HH info via a CSV file to customer, and let customer reregister the device via MSfB or Intune.|
## SMBIOS
| Question | Answer |
| --- | --- |
| 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 Windows Autopilot Hardware Hash need? | It must meet all the Windows 10 hardware requirements. Additional details may be found [here](https://msdn.microsoft.com/library/jj128256(v=vs.85).aspx). |
| If the SMBIOS supports UUID and Serial Number, is it enough for the OA3 tool to generate the Hardware Hash? | No. At a minimum, the following SMBIOS fields need to be populated with unique values: ProductKeyID SmbiosSystemManufacturer SmbiosSystemProductName SmbiosSystemSerialNumber SmbiosSkuNumber SmbiosSystemFamily MacAddress SmbiosUuid DiskSerialNumber TPM EkPub |
## Technical interface
| Question | Answer |
| --- | --- |
| What is the interface to get the MAC Address and Disk Serial Number? How does the OA tool get MAC and Disk Serial #? | Disk serial number is found from IOCTL_STORAGE_QUERY_PROPERTY with StorageDeviceProperty/PropertyStandardQuery. Network MAC address is IOCTL_NDIS_QUERY_GLOBAL_STATS from OID_802_3_PERMANENT_ADDRESS. However the exact mechanisms/”interface” for doing this operation varies depending on the exact scenario being discussed. |
| Follow up clarification: If we have 2-3 MACs on the system, how does OA Tool choose which MAC Address and Disk Serial Number on the system since there are multiple instances of each? If a platform has LAN And WLAN, which MAC is chosen? | In short, all available values are used. In detail, there may be extra specific usage rules. The System disk serial number is more important than any other disks available. Network interfaces that are removable should not be used if detected as they are removable. LAN vs WLAN should not matter, both will be used. |
## The end user experience
|Question|Answer|
|----|-----|
|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 AAD 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) file that is generated to AutopilotHelp@microsoft.com. If possible, collect an ETL from WPR. Often in these cases, users are not signing into the right AAD tenant, or are creating local user accounts. For a complete list of support options, refer to [Windows Autopilot support](autopilot-support.md). |
| If an Administrator makes changes to an existing profile, will the changes take effect on devices that have that profile assigned to them that have already been deployed? |No. Windows Autopilot profiles are not resident on the device. They are downloaded during OOBE, the settings defined at the time are applied. Then, the profile is discarded on the device. If the device is re-imaged 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 Admin doesn’t configure Windows Autopilot prior to an end user attempting to self-deploy? |If the device isn’t registered, it will not receive the Windows Autopilot experience and the end user will go through normal 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 enrol that device into the MDM, after which—the next time that device is “reset”—it will go through the Windows Autopilot OOBE experience.|
|What may be a reason why I did not receive a customized sign-in screen during Autopilot? |Tenant branding must be configured in portal.azure.com to receive a customized sign-in experience.|
|What happens if a device is registered with Azure AD but does not have an Windows Autopilot profile assigned? |The regular AAD OOBE will occur since no Windows 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 Windows Performance Recorder (WPR) trace during OOBE. The XML file (WPRP extension) for this trace may be provided upon request.|
## MDM
| Question | Answer |
| --- | --- |
| Must we use Intune for our MDM? | No. 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-premise configuration tool like System Center Configuration Manager (SCCM). You only need to use SCCM if Intune can’t support what you want to do with your profile. If you choose to co-manage using Intune + SCCM, you do it by including an SCCM agent in your Intune profile. When that profile is pushed to the device, the device will see the SCCM agent and go out to SCCM to pull down any additional profile settings. |
| Must we use System Center Configuration Manager (SCCM) for Windows Autopilot | No. Co-management (described above) is optional. |
## Features
| Question | Answer |
| --- | --- |
| 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 (e.g., shared devices, or KIOSK devices). |
| Hybrid Azure Active Directory join | Allows Windows Autopilot devices to connect to an on-premise Active Directory domain controller (in addition to being Azure AD joined). |
| Windows Autopilot reset | Removes user apps and settings from a device, but maintains AAD 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](existing-devices.md) | Offers an upgrade path to Windows Autopilot for all existing Win 7/8 devices. |
## General
|Question|Answer
|------------------|-----------------|
|If I wipe the machine and restart, will I still receive Windows Autopilot?|Yes, if the device is still registered for Windows Autopilot and is running Windows 10, version 1703 7B and above releases, it will receive the Windows Autopilot experience.|
|Can I harvest the device fingerprint on existing machines?|Yes, if the device is running Windows 10, version 1703 and above, you can harvest device fingerprints for registration. There are no plans to backport the functionality to previous releases and no way to harvest them on pre-Windows 10 Windows 10, version 1703 devices that have not been updated to Windows 10, version 1703.|
|What is Windows 10, version 1703 7B and why does it matter?| Windows 10, version 1703 7B is a Windows 10, version 1703 image bundled with cumulative updates. To receive Autopilot, clients **must** run Windows 10, version 1703 7B or later. These cumulative updates contain a critical fix for Autopilot. Consider the following:<br><br><I>Windows Autopilot will not apply its profiles to the machine unless AAD credentials match the expected AAD tenant. For the Windows 10, version 1703 release, it was assumed that would be determined by the domain name, so the domain name used to register (for example contoso.com) should match the domain name used to sign in (for example user@contoso.com). But what happens if your tenant has multiple domains (for example us.contoso.com, or fr.contoso.com)? Since these domain names do not match, the device will not be configured for Autopilot. However, both domains are part of the same AAD tenant, and as such it was determined the matching scheme was not useful. This was improved upon by making use of the tenant ID. By using the tenant ID, we can determine that if the user signs into a domain with a tenant matching the one they registered with, we can safely consider this to be a match. The fix for this problem already exists in Windows 10, version 1709 and was backported into the Windows 10, version 1703 7B release.</I> <br><br>**Key Take-Aways**: When using pre-Windows 10, version 1703 7B clients the user’s domain **must** match the domain they registered with. This functionality is found in Windows 10 version 1709 clients using build >= 16215, and Windows 10, version 1703 clients >= 7B. |
|What is the impact of not updating to 7B?|See the detailed scenario described directly above.|
|Is Windows Autopilot supported on other SKUs, e.g. Surface Hub, HoloLens, Windows Mobile.|No, Windows Autopilot isn’t supported on other SKUs.|
|Does Windows Autopilot work after MBR or image re-installation?|Yes.|
| Can machines that have reimaged a few times go through Autopilot? What does the error message "This user is not authorized to enroll" mean? Error code 801c0003. |There are limits to the number of devices a particular AAD user can enroll in AAD, as well as the number of devices that are supported per user in Intune. (These are somewhat configurable but not “infinite.”) You’ll run into this 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 via the AAD sign-in process. What occurs is illustrated below. If badguys.com registers a device owned by contoso.com, at worst, the user would be directed to sign into badguys.com. When the user enters their email/password, the sign-in information is redirected through AAD to the proper AAD 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 AAD 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 AAD 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 sovereign cloud?|It is not customer data that we store, but business data which enables Microsoft to provide a service, therefore it is okay for the data to reside in the US. Customers can stop subscribing to the service any time, and, in that event, the business data is removed by Microsoft.|
|How many ways are there to register a device for Windows Autopilot|There are six ways to register a device, depending on who is doing the registering: <br><br>1. OEM Direct API (only available to TVOs) <br>2. MPC via the MPC API (must be a CSP) <br>3. MPC via manual upload of CSV file in the UI (must be a CSP) <br>4. MSfB via CSV file upload <br>5. Intune via CSV file upload <br>6. Microsoft 365 Business portal via CSV file upload|
|How many ways are there to create a Windows Autopilot profile?|There are four ways to create & assign an Windows Autopilot profile: <br><br>1. Through MPC (must be a CSP) <br>2. Through MSfB <br>3. Through Intune (or another MDM) <br>4. Microsoft 365 Business portal <br><br>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 <br>2. Hidden special characters in CSV files. <br><br>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 public Azure. Public Azure does not include the three entities listed below:<br>- Azure Germany <br>- Azure China<br>- Azure Government<br>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, the Contoso employees would not be able to use Autopilot.|
## Glossary
| Term | Meaning |
| --- | --- |
| 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 |
| AAD | 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 |
---
title: Windows Autopilot support
ms.reviewer:
manager: laurawi
description: Support information for Windows Autopilot
keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: low
ms.sitesec: library
ms.pagetype: deploy
audience: itpro
author: greg-lindsay
ms.author: greglin
ms.collection: M365-modern-desktop
ms.topic: article
---
# Windows Autopilot FAQ
**Applies to: Windows 10**
This topic provides OEMs, partners, administrators, and end-users with answers to some frequently asked questions about deploying Windows 10 with Windows Autopilot.
A [glossary](#glossary) of abbreviations used in this topic is provided at the end.
## Microsoft Partner Center
| Question | Answer |
| --- | --- |
| In the Partner Center, does the Tenant ID need to be provided with every device file upload? Is this needed to allow the business customer to access their devices in MSfB? | No. Providing the Tenant ID is a one-time entry in the Partner Center that can be re-used with future device uploads. |
| How does the customer or tenant know that their devices are ready to be claimed in MSfB? | After the device file upload is completed in the Partner Center, the tenant can see the devices available for Windows Autopilot setup in MSfB. The OEM would need to advise the tenant to access MSfB. Auto-notification from MSfB to the tenant is being developed. |
| How does a customer authorize an OEM or Channel Partner to register Autopilot devices on the customer’s behalf? | Before an OEM or Channel Partner can register a device for 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, which directs the customer to a consent page in Microsoft Store for Business. The steps explaining this process are [here](registration-auth.md). |
| Are there any restrictions if a business customer has registered devices in MSfB and later wants those devices to be managed by a CSP via the Partner Center? | The devices will need to be deleted in MSfB by the business customer before the CSP can upload and manage them in the Partner Center. |
| Does Windows Autopilot support removing the option to enable a local administrator account? | Windows Autopilot doesn’t support removing the local admin account. However, it does support restricting the user performing AAD domain join in OOBE to a standard account (versus admin account by default).|
| How can I test the Windows Autopilot CSV file in the Partner Center? | Only CSP Partners have access to the Partner Center portal. If you are a CSP, you can create a Sales agent user account which has access to “Devices” for testing the file. This can be done today in the Partner Center. <br><br>Go [here](https://msdn.microsoft.com/partner-center/create-user-accounts-and-set-permissions) for more information. |
| Must I become a Cloud Solution Provider (CSP) to participate in Windows Autopilot? | Top volume OEMs do not, as they can 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 it comes to Windows Autopilot? | For purposes of Windows Autopilot, there are three different types of CSPs, each with different levels of authority an access: <br><br>1. <b>Direct CSP</b>: Gets direct authorization from the customer to register devices. <br><br>2. <b>Indirect CSP Provider</b>: 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. <br><br>3. <b>Indirect CSP Reseller</b>: 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. |
## Manufacturing
| Question | Answer |
| --- | --- |
| What changes need to be made in the factory OS image for customer configuration settings? |No changes are required on the factory floor to enable Windows Autopilot deployment. |
| What version of the OA3 tool meets Windows Autopilot deployment requirements? | Windows Autopilot can work with any version of the OA3 tool. We recommend using Windows 10, version 1703 and above to generate the 4K Hardware Hash. |
| At the time of placing an order, do customers need to be state whether they want it with or without Windows Autopilot options? | Yes, if they want Windows Autopilot, they will want Windows 10, version 1703 or later versions. Also, they will want to receive the CSV file or have the file upload (i.e., registration) completed on their behalf. |
| Does the OEM need to manage or collect any custom imaging files from customers and perform any image uploads to Microsoft? | No change, OEMs just send the CBRs as usual to Microsoft. No images are sent to Microsoft to enable Windows Autopilot. Windows Autopilot only customizes OOBE and allows policy configurations (disables admin account, for example). |
| Are there any customer impacts to upgrading from Windows 8 to Windows 10? | The devices must have Windows 10, version 1703 or later to enroll in Windows Autopilot deployment, otherwise no impacts. |
| Will there be any change to the existing CBR with 4k Hardware Hash? | No. |
| What new information needs to be sent from the OEM to Microsoft? | Nothing, unless the OEM opts to register the device on the customer’s behalf, in which case they would upload the device ID via 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 Windows Autopilot Deployment? | No. |
## CSV schema
| Question | Answer |
| --- | --- |
| Can a comma be used in the CSV file? | No. |
| What error messages can a user expect to see in the Partner Center or MSfB when uploading a file? | See the “In Microsoft Store for Business” section of this guide. |
| Is there a limit to the number of devices that can be listed in the CSV file? | Yes, the CSV file can only contain 1,000 devices to apply to a 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 should provide the CSV file to their customers? | Microsoft recommends encrypting the CSV file when sending to the business customer to self-register their Windows Autopilot devices (either through MPC, MSfB, or Intune). |
## Hardware hash
| Question | Answer |
| --- | --- |
| Must every Hardware Hash submitted by the OEM contain the SMBIOS UUID (universally unique identifier), MAC (media access control) address and unique disk serial number (if using Windows 10, version 1703 and above OEM Activation 3.0 tool)? | Yes. Since Windows Autopilot is based on the ability to uniquely identify devices applying for cloud configuration, it is critical to submit Hardware Hashes which meet the outlined requirement. |
| What is the reason for needing the SMBIOS UUID, MAC Address and Disk Serial Number in the Hardware Hash details? | For creating the Hardware Hash, these are the fields that are needed to identify a device, as parts of the device are added/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 Hash, and Windows Autopilot Hardware Hash? | None. They’re different names for the same thing. The Windows 10, 1703 version of the OA3 tool output is called the OA3 Hash, which is 4K in size, which is usable for the Windows Autopilot deployment scenario. Note: When using a non-1703 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/or repair for the NIC (network interface controller) and/or Disk? Will the Hardware Hash become invalid? | Yes. If you replace parts, you need to gather the new Hardware Hash, though it depends on what is replaced, and the characteristics of the parts. For example, if you replace the TPM or motherboard, it’s a new device – 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 Microsoft’s strong recommendation any time you replace parts. |
## Motherboard replacement
| Question | Answer |
| --- | --- |
| How does Autopilot handle motherboard replacement scenarios?” | Motherboard replacement is out for scope for Autopilot. Any 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. <br><br>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 HH (or device ID). <br><br>**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 HH info via a CSV file to customer, and let customer reregister the device via MSfB or Intune.|
## SMBIOS
| Question | Answer |
| --- | --- |
| 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 Windows Autopilot Hardware Hash need? | It must meet all the Windows 10 hardware requirements. Additional details may be found [here](https://msdn.microsoft.com/library/jj128256(v=vs.85).aspx). |
| If the SMBIOS supports UUID and Serial Number, is it enough for the OA3 tool to generate the Hardware Hash? | No. At a minimum, the following SMBIOS fields need to be populated with unique values: ProductKeyID SmbiosSystemManufacturer SmbiosSystemProductName SmbiosSystemSerialNumber SmbiosSkuNumber SmbiosSystemFamily MacAddress SmbiosUuid DiskSerialNumber TPM EkPub |
## Technical interface
| Question | Answer |
| --- | --- |
| What is the interface to get the MAC Address and Disk Serial Number? How does the OA tool get MAC and Disk Serial #? | Disk serial number is found from IOCTL_STORAGE_QUERY_PROPERTY with StorageDeviceProperty/PropertyStandardQuery. Network MAC address is IOCTL_NDIS_QUERY_GLOBAL_STATS from OID_802_3_PERMANENT_ADDRESS. However the exact mechanisms/”interface” for doing this operation varies depending on the exact scenario being discussed. |
| Follow up clarification: If we have 2-3 MACs on the system, how does OA Tool choose which MAC Address and Disk Serial Number on the system since there are multiple instances of each? If a platform has LAN And WLAN, which MAC is chosen? | In short, all available values are used. In detail, there may be extra specific usage rules. The System disk serial number is more important than any other disks available. Network interfaces that are removable should not be used if detected as they are removable. LAN vs WLAN should not matter, both will be used. |
## The end user experience
|Question|Answer|
|----|-----|
|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 AAD 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) file that is generated to AutopilotHelp@microsoft.com. If possible, collect an ETL from WPR. Often in these cases, users are not signing into the right AAD tenant, or are creating local user accounts. For a complete list of support options, refer to [Windows Autopilot support](autopilot-support.md). |
| If an Administrator makes changes to an existing profile, will the changes take effect on devices that have that profile assigned to them that have already been deployed? |No. Windows Autopilot profiles are not resident on the device. They are downloaded during OOBE, the settings defined at the time are applied. Then, the profile is discarded on the device. If the device is re-imaged 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 Admin doesn’t configure Windows Autopilot prior to an end user attempting to self-deploy? |If the device isn’t registered, it will not receive the Windows Autopilot experience and the end user will go through normal 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 enrol that device into the MDM, after which—the next time that device is “reset”—it will go through the Windows Autopilot OOBE experience.|
|What may be a reason why I did not receive a customized sign-in screen during Autopilot? |Tenant branding must be configured in portal.azure.com to receive a customized sign-in experience.|
|What happens if a device is registered with Azure AD but does not have an Windows Autopilot profile assigned? |The regular AAD OOBE will occur since no Windows 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 Windows Performance Recorder (WPR) trace during OOBE. The XML file (WPRP extension) for this trace may be provided upon request.|
## MDM
| Question | Answer |
| --- | --- |
| Must we use Intune for our MDM? | No. 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-premise configuration tool like System Center Configuration Manager (SCCM). You only need to use SCCM if Intune can’t support what you want to do with your profile. If you choose to co-manage using Intune + SCCM, you do it by including an SCCM agent in your Intune profile. When that profile is pushed to the device, the device will see the SCCM agent and go out to SCCM to pull down any additional profile settings. |
| Must we use System Center Configuration Manager (SCCM) for Windows Autopilot | No. Co-management (described above) is optional. |
## Features
| Question | Answer |
| --- | --- |
| 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 (e.g., shared devices, or KIOSK devices). |
| Hybrid Azure Active Directory join | Allows Windows Autopilot devices to connect to an on-premise Active Directory domain controller (in addition to being Azure AD joined). |
| Windows Autopilot reset | Removes user apps and settings from a device, but maintains AAD 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](existing-devices.md) | Offers an upgrade path to Windows Autopilot for all existing Win 7/8 devices. |
## General
|Question|Answer
|------------------|-----------------|
|If I wipe the machine and restart, will I still receive Windows Autopilot?|Yes, if the device is still registered for Windows Autopilot and is running Windows 10, version 1703 7B and above releases, it will receive the Windows Autopilot experience.|
|Can I harvest the device fingerprint on existing machines?|Yes, if the device is running Windows 10, version 1703 and above, you can harvest device fingerprints for registration. There are no plans to backport the functionality to previous releases and no way to harvest them on pre-Windows 10 Windows 10, version 1703 devices that have not been updated to Windows 10, version 1703.|
|What is Windows 10, version 1703 7B and why does it matter?| Windows 10, version 1703 7B is a Windows 10, version 1703 image bundled with cumulative updates. To receive Autopilot, clients **must** run Windows 10, version 1703 7B or later. These cumulative updates contain a critical fix for Autopilot. Consider the following:<br><br><I>Windows Autopilot will not apply its profiles to the machine unless AAD credentials match the expected AAD tenant. For the Windows 10, version 1703 release, it was assumed that would be determined by the domain name, so the domain name used to register (for example contoso.com) should match the domain name used to sign in (for example user@contoso.com). But what happens if your tenant has multiple domains (for example us.contoso.com, or fr.contoso.com)? Since these domain names do not match, the device will not be configured for Autopilot. However, both domains are part of the same AAD tenant, and as such it was determined the matching scheme was not useful. This was improved upon by making use of the tenant ID. By using the tenant ID, we can determine that if the user signs into a domain with a tenant matching the one they registered with, we can safely consider this to be a match. The fix for this problem already exists in Windows 10, version 1709 and was backported into the Windows 10, version 1703 7B release.</I> <br><br>**Key Take-Aways**: When using pre-Windows 10, version 1703 7B clients the user’s domain **must** match the domain they registered with. This functionality is found in Windows 10 version 1709 clients using build >= 16215, and Windows 10, version 1703 clients >= 7B. |
|What is the impact of not updating to 7B?|See the detailed scenario described directly above.|
|Is Windows Autopilot supported on other SKUs, e.g. Surface Hub, HoloLens, Windows Mobile.|No, Windows Autopilot isn’t supported on other SKUs.|
|Does Windows Autopilot work after MBR or image re-installation?|Yes.|
| Can machines that have reimaged a few times go through Autopilot? What does the error message "This user is not authorized to enroll" mean? Error code 801c0003. |There are limits to the number of devices a particular AAD user can enroll in AAD, as well as the number of devices that are supported per user in Intune. (These are somewhat configurable but not “infinite.”) You’ll run into this 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 via the AAD sign-in process. What occurs is illustrated below. If badguys.com registers a device owned by contoso.com, at worst, the user would be directed to sign into badguys.com. When the user enters their email/password, the sign-in information is redirected through AAD to the proper AAD 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 AAD 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 AAD 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 sovereign cloud?|It is not customer data that we store, but business data which enables Microsoft to provide a service, therefore it is okay for the data to reside in the US. Customers can stop subscribing to the service any time, and, in that event, the business data is removed by Microsoft.|
|How many ways are there to register a device for Windows Autopilot|There are six ways to register a device, depending on who is doing the registering: <br><br>1. OEM Direct API (only available to TVOs) <br>2. MPC via the MPC API (must be a CSP) <br>3. MPC via manual upload of CSV file in the UI (must be a CSP) <br>4. MSfB via CSV file upload <br>5. Intune via CSV file upload <br>6. Microsoft 365 Business portal via CSV file upload|
|How many ways are there to create a Windows Autopilot profile?|There are four ways to create & assign an Windows Autopilot profile: <br><br>1. Through MPC (must be a CSP) <br>2. Through MSfB <br>3. Through Intune (or another MDM) <br>4. Microsoft 365 Business portal <br><br>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 <br>2. Hidden special characters in CSV files. <br><br>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 public Azure. Public Azure does not include the three entities listed below:<br>- Azure Germany <br>- Azure China<br>- Azure Government<br>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, the Contoso employees would not be able to use Autopilot.|
## Glossary
| Term | Meaning |
| --- | --- |
| 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 |
| AAD | 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 |

841
windows/deployment/windows-autopilot/autopilot-mbr.md
View File

@ -1,421 +1,420 @@
---
title: Windows Autopilot motherboard replacement
ms.reviewer:
manager: laurawi
description: Windows Autopilot deployment MBR scenarios
keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: medium
ms.sitesec: library
ms.pagetype: deploy
author: greg-lindsay
audience: itpro
ms.author: greglin
ms.collection: M365-modern-desktop
ms.topic: article
---
# 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’s require strict uniqueness across motherboards, MAC addresses, etc., while Windows Autopilot requires strict uniqueness at the Hardware ID level for each device to enable successful registration. The Hardware ID does not always accommodate all the OEM hardware component requirements, thus these requirements are sometimes at odds, causing issues with some repair scenarios.
**Motherboard Replacement (MBR)**
If a motherboard replacement is needed on a Windows Autopilot device, the following process is recommended:
1. [Deregister the device](#deregister-the-autopilot-device-from-the-autopilot-program) from Windows Autopilot
2. [Replace the motherboard](#replace-the-motherboard)
3. [Capture a new device ID (4K HH)](#capture-a-new-autopilot-device-id-4k-hh-from-the-device)
4. [Reregister the device](#reregister-the-repaired-device-using-the-new-device-id) with Windows Autopilot
5. [Reset the device](#reset-the-device)
6. [Return the device](#return-the-repaired-device-to-the-customer)
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. Only the entity that registered the device can deregister it. This might be the customer IT Admin, the OEM, or the CSP partner. If the IT Admin registered the device, they likely did so via Intune (or possibly the Microsoft Store for Business). In that case, they should deregister the device from Intune (or MSfB). This is necessary because devices registered in Intune will not show up in MPC. However, if the OEM or CSP partner registered the device, they likely did so via the Microsoft Partner Center (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.
**NOTE**: When possible, an OEM or CSP should register Autopilot devices, rather than having the customer do it. This will avoid problems where OEMs or CSPs may not be able to deregister a device if, for example, a customer leasing a device goes out of business before deregistering it themselves.
**EXCEPTION**: If a customer grants an OEM permission to register devices on their behalf via the automated consent process, then an OEM can use the API to deregister devices they didn’t register themselves (instead, the customer registered the devices). But keep in mind that this would only remove those devices from the Autopilot program, it would not disenroll them from Intune or disjoin them from AAD. The customer must do those steps, if desired, 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 desired 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 in order 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
**NOTE**: These steps deregister the device from Autopilot, but also unenroll the device from Intune, and disjoin the device from AAD. While it may appear that only deregistering the device from Autopilot is needed, there are certain barriers in place within Intune that necessitate all the steps above be done, which is best practice anyway in case the device gets lost or becomes unrecoverable, to eliminate the possibility of orphaned devices existing in the Autopilot database, or Intune, or AAD. If a device gets into an unrecoverable state, you can contact the appropriate [Microsoft support alias](autopilot-support.md) 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](https://docs.microsoft.com/intune/enrollment-autopilot#create-an-autopilot-device-group).
### 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
![devices](images/devices.png)
**NOTE**: Deregistering a device from Autopilot in MPC does only that; it does not also unenroll the device from the MDM (Intune), nor does it disjoin the device from AAD. Therefore, 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.
Alternatively, an OEM partner that has integrated the OEM Direct APIs can deregister a device by calling the AutopilotDeviceRegistration API with the TenantID and TenantDomain fields left blank in the request call.
Because the repair facility will not have access to the user’s login credentials, the repair facility will have to reimage the device as part of the repair process. This means that the customer should do three things before sending the device off for repair:
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 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. This means that the quality of the data in the BIOS after a MBR varies. To ensure the repaired device will still be Autopilot-capable following its repair, the new (post-repair) BIOS should be able to successfully gather and populate the following information at a minimum:
- DiskSerialNumber
- SmbiosSystemSerialNumber
- SmbiosSystemManufacturer
- SmbiosSystemProductName
- SmbiosUuid
- TPM EKPub
- MacAddress
- ProductKeyID
- OSType
**NOTE**: For simplicity, and because processes vary between repair facilities, we have excluded many of the additional steps often used in a 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 disbled if the technician has the ability to 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. Assuming the repair technician does NOT have access to the customer’s login credentials, they will have to reimage the device in order to gain access, per the following steps:
1. The repair technician creates a [WinPE bootable USB drive](https://docs.microsoft.com/windows-hardware/manufacture/desktop/oem-deployment-of-windows-10-for-desktop-editions#create-a-bootable-windows-pe-winpe-partition).
2. The repair technician boots the device to WinPE.
3. The repair technician [applies a new Windows image to the device](https://docs.microsoft.com/windows-hardware/manufacture/desktop/work-with-windows-images).
**NOTE**: Ideally, the same version of Windows should be reimaged onto the device that was originally on the device, so some coordination will be required between the repair facility and customer to capture this information at the time the device arrives for repair. This 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).
Alternatively, the [WindowsAutoPilotInfo Powershell script](https://www.powershellgallery.com/packages/Get-WindowsAutoPilotInfo) can be used to capture the 4K HH by following these steps:
1. Install the script from the [PowerShell Gallery](https://www.powershellgallery.com/packages/Get-WindowsAutoPilotInfo) 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.
```powershell
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**.<br>
>If, after installing the script you get an error that Get-WindowsAutopilotInfo.ps1 is not found, verify that C:\Program Files\WindowsPowerShell\Scripts is present in your PATH variable.<br>
>If the Install-Script cmdlet fails, verify that you have the default PowerShell repository registered (**Get-PSRepository**) or register the default repository with **Register-PSRepository -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. Do not attempt to pipe the command output to a file manually.
**NOTE**: If the repair facility does not have the ability to run the OA3 tool or PowerShell script to capture the new 4K HH, then the CSP (or OEM) partners must do this for them. Without some entity capturing the new 4K HH, there is no way to reregister this device as an Autopilot device.
## Reregister the repaired device using the new device ID
If an OEM is not able to reregister the device, then the repair facility or CSP should reregister the device using MPC, or the customer IT Admin should be advised to 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 **Import** 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.<br>
> [!VIDEO https://www.youtube.com/embed/IpLIZU_j7Z0]
### 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.
![device](images/device2.png)<br>
![device](images/device3.png)
In the case of 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 were used, the Autopilot service would be unable to find a match in the Autopilot database, since no 4K HH info was ever previously submitted for this essentially “new” device, and the upload will fail, likely returning a ZtdDeviceNotFound error. So, again, only upload the 4K HH, not the Tuple or PKID.
**NOTE**: When including the 4K HH in the csv file, you do NOT also need to include the PKID or Tuple. Those columns may be left blank, as shown below:
![hash](images/hh.png)
## Reset the device
Since the device was required to be in Full OS or Audit Mode to capture the 4K HH, the repair facility must reset the image back to a pre-OOBE state before returning it to the customer. One way this can be accomplished 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.
![reset](images/reset.png)
However, it’s likely the repair facility won’t have access to Windows because they lack the user credentials to login, in which case they need to use other means to reimage the device, such as the [Deployment Image Servicing and Management tool](https://docs.microsoft.com/windows-hardware/manufacture/desktop/oem-deployment-of-windows-10-for-desktop-editions#use-a-deployment-script-to-apply-your-image).
## Return the repaired device to the customer
After completing the previous steps, the repaired device can now be returned to the customer, and will be auto-enrolled into the Autopilot program on first boot-up during OOBE.
**NOTE**: If the repair facility did NOT reimage the device, they could be sending it back in a potentially broken state (e.g., there’s no way to log into the device because it’s been dissociated from the only known user account), in which case they should tell the organization that they need to fix the registration and OS themselves.
**IMPORTANT**: A device can be “registered” for Autopilot prior to being powered-on, but the device isn’t actually “deployed” to Autopilot (i.e., enabled as an Autopilot device) until it goes through OOBE, which is why 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, so repair centers or customers should be reminded to backup data (if possible) prior to repair.
- In the cases where a repair facility does not have the ability to 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:<br>
- Supported = **Yes**: the device can be reenabled for Autopilot
- Supported = **No**: the device cannot be reenabled for Autopilot
<table border="1">
<th>Scenario<th>Supported<th>Microsoft Recommendation
<tr><td>Motherboard Replacement (MBR) in general<td>Yes<td>The recommended course of action for MBR scenarios is:
1. Autopilot device is deregistered from the Autopilot program
2. The motherboard is replace
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 do a successful MBR and Autopilot re-enablement without keys or certain BIOS info (e.g., serial #, model name, etc.), but doing so is only recommended for testing/educational purposes.
<tr><td>MBR when motherboard has a TPM chip (enabled) and only one onboard network card (that also gets replaced)<td>Yes<td>
1. Deregister damaged device
2. Replace motherboard
3. Reimage device (to gain access), unless 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
<tr><td>MBR when motherboard has a TPM chip (enabled) and a second network card (or network interface) that is not replaced along with the motherboard<td>No<td>This scenario is not recommended, as it breaks the Autopilot experience, because the resulting Device ID will not be stable until after TPM attestation has completed, and even then registration may give incorrect results because of ambiguity with MAC Address resolution.
<tr><td>MBR where the NIC card, HDD, and WLAN all remain the same after the repair<td>Yes<td>
1. Deregister damaged device
2. Replace motherboard (with new RDPK preinjected in BIOS)
3. Reimage device (to gain access), unless have access to customers’ login credentials
4. Write old device info into BIOS (same s/n, model, etc.)*
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
*Note that for this and subsequent scenarios, rewriting old device info would not include the TPM 2.0 endorsement key, as the associated private key is locked to the TPM device
<tr><td>MBR where the NIC card remains the same, but the HDD and WLAN are replaced<td>Yes<td>
1. Deregister damaged device
2. Replace motherboard (with new RDPK preinjected in BIOS)
3. Insert new HDD and WLAN
4. Write old device info into BIOS (same s/n, model, etc.)
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
<tr><td>MBR where the NIC card and WLAN remains the same, but the HDD is replaced<td>Yes<td>
1. Deregister damaged device
2. Replace motherboard (with new RDPK preinjected in BIOS)
3. Insert new HDD
4. Write old device info into BIOS (same s/n, model, etc.)
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
<tr><td>MBR where only the MB is replaced (all other parts remain same) but new MB was taken from a previously used device that had NOT been Autopilot-enabled before.<td>Yes<td>
1. Deregister damaged device
2. Replace motherboard (with new RDPK preinjected in BIOS)
3. Reimage device (to gain access), unless have access to customers’ login credentials
4. Write old device info into BIOS (same s/n, model, etc.)
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
<tr><td>MBR where only the MB is replaced (all other parts remain same) but new MB was taken from a previously used device that HAD been Autopilot-enabled before.<td>Yes<td>
1. Deregister old device from which MB will be taken
2. Deregister damaged device (that you want to repair)
3. Replace motherboard in repair device with MB from other Autopilot device (with new RDPK preinjected in BIOS)
4. Reimage device (to gain access), unless have access to customers’ login credentials
5. Write old device info into BIOS (same s/n, model, etc.)
6. Capture new 4K HH
7. Reregister repaired device
8. Reset device back to OOBE
9. Go through Autopilot OOBE (customer)
10. Autopilot successfully enabled
<b>NOTE</b>: The repaired device can also be used successfully as a normal, non-Autopilot device.
<tr><td>BIOS info excluded from MBR device<td>No<td>Repair facility does not 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
4. Capture new 4K HH
5. Reregister repaired device
6. Create Autopilot profile for device
7. Go through Autopilot OOBE (customer)
8. Autopilot FAILS to recognize repaired device
<tr><td>MBR when there is no TPM chip<td>Yes<td>Though we do not recommend enabling an Autopilot devices without a TPM chip (which is recommended for BitLocker encryption), it is possible to enable an Autopilot devices in “standard user” mode (but NOT Self-deploying mode) that does not have a TPM chip. In this case, you would:
1. Deregister damaged device
2. Replace motherboard
3. Reimage device (to gain access), unless have access to customers’ login credentials
4. Write old device info into BIOS (same s/n, model, etc.)
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
<tr><td>New DPK written into image on repaired Autopilot device with a new MB<td>Yes<td>Repair facility replaces normal MB on damaged device. MB does not contain any DPK in the BIOS. Repair facility writes DPK into image after MBR.
1. Deregister damaged device
2. Replace motherboard – BIOS does NOT contain DPK info
3. Reimage device (to gain access), unless have access to customers’ login credentials
4. Write device info into BIOS (same s/n, model, etc.)
5. Capture new 4K HH
6. Reset or reimage device to pre-OOBE and write DPK into image
7. Reregister repaired device
8. Go through Autopilot OOBE
9. Autopilot successfully enabled
<tr><td>New Repair Product Key (RDPK)<td>Yes<td>Using a MB with a new RDPK preinjected results in a successful Autopilot refurbishment scenario.
1. Deregister damaged device
2. Replace motherboard (with new RDPK preinjected in BIOS)
3. Reimage or rest image to pre-OOBE
4. Write device info into BIOS
5. Capture new 4K HH
6. Reregister repaired device
7. Reimage or reset image to pre-OOBE
8. Go through Autopilot OOBE
9. Autopilot successfully enabled
<tr><td>No Repair Product Key (RDPK) injected<td>No<td>This scenario violates Microsoft policy and breaks the Windows Autopilot experience.
<tr><td>Reimage damaged Autopilot device that was not deregistered prior to repair<td>Yes, but the device will still be associated with previous tenant ID, so should only be returned to same customer<td>
1. Reimage damaged device
2. Write DPK into image
3. Go through Autopilot OOBE
4. Autopilot successfully enabled (to previous tenant ID)
<tr><td>Disk replacement from a non-Autopilot device to an Autopilot device<td>Yes<td>
1. Do not deregister damaged device prior to repair
2. Replace HDD on damaged device
3. Reimage or reset image back to OOBE
4. Go through Autopilot OOBE (customer)
5. Autopilot successfully enabled (repaired device recognized as its previous self)
<tr><td>Disk replacement from one Autopilot device to another Autopilot device<td>Maybe<td>If the device from which the HDD is taken was itself previously deregistered from Autopilot, then that HDD can be used in a repair device. But if the HDD was never previously deregistered from Autopilot before being used in a repaired device, the newly repaired device will not have the proper Autopilot experience.
Assuming the used HDD was previously deregistered (before being used in this repair):
1. Deregister damaged device
2. Replace HDD on damaged device using a HDD from another deregistered Autopilot device
3. Reimage or rest the repaired device back to a pre-OOBE state
4. Go through Autopilot OOBE (customer)
5. Autopilot successfully enabled
<tr><td>Third party network card replacement <td>No<td>Whether from a non-Autopilot device to an Autopilot device, from one Autopilot device to another Autopilot device, or from an Autopilot device to a non-Autopilot device, any scenario where a 3rd party (not onboard) Network card is replaced will break the Autopilot experience, and is not recommended.
<tr><td>A device repaired more than 3 times<td>No<td>Autopilot is not supported when a device is repeatedly repaired, so that whatever parts NOT replaced become associated with too many parts that have been replaced, which would make it difficult to uniquely identify that device in the future.
<tr><td>Memory replacement<td>Yes<td>Replacing the memory on a damaged device does not negatively affect the Autopilot experience on that device. No de/reregistration is needed. The repair technician simply needs to replace the memory.
<tr><td>GPU replacement<td>Yes<td>Replacing the GPU(s) on a damaged device does not negatively affect the Autopilot experience on that device. No de/reregistration is needed. The repair technician simply needs to replace the GPU.
</table>
>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.
**NOTE**: 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
| Question | Answer |
| --- | --- |
| If we have a tool that programs product information into the BIOS after the MBR, do we still need to submit a CBR report for the device to be Autopilot-capable? | No. Not if the in-house tool writes the minimum necessary information into the BIOS that the Autopilot program looks for to identify the device, as described earlier in this document. |
| What if only some components are replaced rather than the full motherboard? | While it’s true that some limited repairs do not prevent the Autopilot algorithm from successfully matching the post-repair device with the pre-repair device, it is 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 they don’t have the customer’s login credentials? | The technician will have to reimage the device and use their own credentials during the repair process. |
## Related topics
[Device guidelines](autopilot-device-guidelines.md)<br>
---
title: Windows Autopilot motherboard replacement
ms.reviewer:
manager: laurawi
description: Windows Autopilot deployment MBR scenarios
keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: medium
ms.sitesec: library
ms.pagetype: deploy
audience: itpro
author: greg-lindsay
ms.author: greglin
ms.collection: M365-modern-desktop
ms.topic: article
---
# 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’s require strict uniqueness across motherboards, MAC addresses, etc., while Windows Autopilot requires strict uniqueness at the Hardware ID level for each device to enable successful registration. The Hardware ID does not always accommodate all the OEM hardware component requirements, thus these requirements are sometimes at odds, causing issues with some repair scenarios.
**Motherboard Replacement (MBR)**
If a motherboard replacement is needed on a Windows Autopilot device, the following process is recommended:
1. [Deregister the device](#deregister-the-autopilot-device-from-the-autopilot-program) from Windows Autopilot
2. [Replace the motherboard](#replace-the-motherboard)
3. [Capture a new device ID (4K HH)](#capture-a-new-autopilot-device-id-4k-hh-from-the-device)
4. [Reregister the device](#reregister-the-repaired-device-using-the-new-device-id) with Windows Autopilot
5. [Reset the device](#reset-the-device)
6. [Return the device](#return-the-repaired-device-to-the-customer)
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. Only the entity that registered the device can deregister it. This might be the customer IT Admin, the OEM, or the CSP partner. If the IT Admin registered the device, they likely did so via Intune (or possibly the Microsoft Store for Business). In that case, they should deregister the device from Intune (or MSfB). This is necessary because devices registered in Intune will not show up in MPC. However, if the OEM or CSP partner registered the device, they likely did so via the Microsoft Partner Center (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.
**NOTE**: When possible, an OEM or CSP should register Autopilot devices, rather than having the customer do it. This will avoid problems where OEMs or CSPs may not be able to deregister a device if, for example, a customer leasing a device goes out of business before deregistering it themselves.
**EXCEPTION**: If a customer grants an OEM permission to register devices on their behalf via the automated consent process, then an OEM can use the API to deregister devices they didn’t register themselves (instead, the customer registered the devices). But keep in mind that this would only remove those devices from the Autopilot program, it would not disenroll them from Intune or disjoin them from AAD. The customer must do those steps, if desired, 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 desired 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 in order 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
**NOTE**: These steps deregister the device from Autopilot, but also unenroll the device from Intune, and disjoin the device from AAD. While it may appear that only deregistering the device from Autopilot is needed, there are certain barriers in place within Intune that necessitate all the steps above be done, which is best practice anyway in case the device gets lost or becomes unrecoverable, to eliminate the possibility of orphaned devices existing in the Autopilot database, or Intune, or AAD. If a device gets into an unrecoverable state, you can contact the appropriate [Microsoft support alias](autopilot-support.md) 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](https://docs.microsoft.com/intune/enrollment-autopilot#create-an-autopilot-device-group).
### 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
![devices](images/devices.png)
**NOTE**: Deregistering a device from Autopilot in MPC does only that; it does not also unenroll the device from the MDM (Intune), nor does it disjoin the device from AAD. Therefore, 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.
Alternatively, an OEM partner that has integrated the OEM Direct APIs can deregister a device by calling the AutopilotDeviceRegistration API with the TenantID and TenantDomain fields left blank in the request call.
Because the repair facility will not have access to the user’s login credentials, the repair facility will have to reimage the device as part of the repair process. This means that the customer should do three things before sending the device off for repair:
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 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. This means that the quality of the data in the BIOS after a MBR varies. To ensure the repaired device will still be Autopilot-capable following its repair, the new (post-repair) BIOS should be able to successfully gather and populate the following information at a minimum:
- DiskSerialNumber
- SmbiosSystemSerialNumber
- SmbiosSystemManufacturer
- SmbiosSystemProductName
- SmbiosUuid
- TPM EKPub
- MacAddress
- ProductKeyID
- OSType
**NOTE**: For simplicity, and because processes vary between repair facilities, we have excluded many of the additional steps often used in a 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 disbled if the technician has the ability to 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. Assuming the repair technician does NOT have access to the customer’s login credentials, they will have to reimage the device in order to gain access, per the following steps:
1. The repair technician creates a [WinPE bootable USB drive](https://docs.microsoft.com/windows-hardware/manufacture/desktop/oem-deployment-of-windows-10-for-desktop-editions#create-a-bootable-windows-pe-winpe-partition).
2. The repair technician boots the device to WinPE.
3. The repair technician [applies a new Windows image to the device](https://docs.microsoft.com/windows-hardware/manufacture/desktop/work-with-windows-images).
**NOTE**: Ideally, the same version of Windows should be reimaged onto the device that was originally on the device, so some coordination will be required between the repair facility and customer to capture this information at the time the device arrives for repair. This 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).
Alternatively, the [WindowsAutoPilotInfo Powershell script](https://www.powershellgallery.com/packages/Get-WindowsAutoPilotInfo) can be used to capture the 4K HH by following these steps:
1. Install the script from the [PowerShell Gallery](https://www.powershellgallery.com/packages/Get-WindowsAutoPilotInfo) 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.
```powershell
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**.<br>
>If, after installing the script you get an error that Get-WindowsAutopilotInfo.ps1 is not found, verify that C:\Program Files\WindowsPowerShell\Scripts is present in your PATH variable.<br>
>If the Install-Script cmdlet fails, verify that you have the default PowerShell repository registered (**Get-PSRepository**) or register the default repository with **Register-PSRepository -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. Do not attempt to pipe the command output to a file manually.
**NOTE**: If the repair facility does not have the ability to run the OA3 tool or PowerShell script to capture the new 4K HH, then the CSP (or OEM) partners must do this for them. Without some entity capturing the new 4K HH, there is no way to reregister this device as an Autopilot device.
## Reregister the repaired device using the new device ID
If an OEM is not able to reregister the device, then the repair facility or CSP should reregister the device using MPC, or the customer IT Admin should be advised to 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 **Import** 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.<br>
> [!VIDEO https://www.youtube.com/embed/IpLIZU_j7Z0]
### 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.
![device](images/device2.png)<br>
![device](images/device3.png)
In the case of 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 were used, the Autopilot service would be unable to find a match in the Autopilot database, since no 4K HH info was ever previously submitted for this essentially “new” device, and the upload will fail, likely returning a ZtdDeviceNotFound error. So, again, only upload the 4K HH, not the Tuple or PKID.
**NOTE**: When including the 4K HH in the csv file, you do NOT also need to include the PKID or Tuple. Those columns may be left blank, as shown below:
![hash](images/hh.png)
## Reset the device
Since the device was required to be in Full OS or Audit Mode to capture the 4K HH, the repair facility must reset the image back to a pre-OOBE state before returning it to the customer. One way this can be accomplished 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.
![reset](images/reset.png)
However, it’s likely the repair facility won’t have access to Windows because they lack the user credentials to login, in which case they need to use other means to reimage the device, such as the [Deployment Image Servicing and Management tool](https://docs.microsoft.com/windows-hardware/manufacture/desktop/oem-deployment-of-windows-10-for-desktop-editions#use-a-deployment-script-to-apply-your-image).
## Return the repaired device to the customer
After completing the previous steps, the repaired device can now be returned to the customer, and will be auto-enrolled into the Autopilot program on first boot-up during OOBE.
**NOTE**: If the repair facility did NOT reimage the device, they could be sending it back in a potentially broken state (e.g., there’s no way to log into the device because it’s been dissociated from the only known user account), in which case they should tell the organization that they need to fix the registration and OS themselves.
**IMPORTANT**: A device can be “registered” for Autopilot prior to being powered-on, but the device isn’t actually “deployed” to Autopilot (i.e., enabled as an Autopilot device) until it goes through OOBE, which is why 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, so repair centers or customers should be reminded to backup data (if possible) prior to repair.
- In the cases where a repair facility does not have the ability to 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:<br>
- Supported = **Yes**: the device can be reenabled for Autopilot
- Supported = **No**: the device cannot be reenabled for Autopilot
<table border="1">
<th>Scenario<th>Supported<th>Microsoft Recommendation
<tr><td>Motherboard Replacement (MBR) in general<td>Yes<td>The recommended course of action for MBR scenarios is:
1. Autopilot device is deregistered from the Autopilot program
2. The motherboard is replace
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 do a successful MBR and Autopilot re-enablement without keys or certain BIOS info (e.g., serial #, model name, etc.), but doing so is only recommended for testing/educational purposes.
<tr><td>MBR when motherboard has a TPM chip (enabled) and only one onboard network card (that also gets replaced)<td>Yes<td>
1. Deregister damaged device
2. Replace motherboard
3. Reimage device (to gain access), unless 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
<tr><td>MBR when motherboard has a TPM chip (enabled) and a second network card (or network interface) that is not replaced along with the motherboard<td>No<td>This scenario is not recommended, as it breaks the Autopilot experience, because the resulting Device ID will not be stable until after TPM attestation has completed, and even then registration may give incorrect results because of ambiguity with MAC Address resolution.
<tr><td>MBR where the NIC card, HDD, and WLAN all remain the same after the repair<td>Yes<td>
1. Deregister damaged device
2. Replace motherboard (with new RDPK preinjected in BIOS)
3. Reimage device (to gain access), unless have access to customers’ login credentials
4. Write old device info into BIOS (same s/n, model, etc.)*
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
*Note that for this and subsequent scenarios, rewriting old device info would not include the TPM 2.0 endorsement key, as the associated private key is locked to the TPM device
<tr><td>MBR where the NIC card remains the same, but the HDD and WLAN are replaced<td>Yes<td>
1. Deregister damaged device
2. Replace motherboard (with new RDPK preinjected in BIOS)
3. Insert new HDD and WLAN
4. Write old device info into BIOS (same s/n, model, etc.)
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
<tr><td>MBR where the NIC card and WLAN remains the same, but the HDD is replaced<td>Yes<td>
1. Deregister damaged device
2. Replace motherboard (with new RDPK preinjected in BIOS)
3. Insert new HDD
4. Write old device info into BIOS (same s/n, model, etc.)
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
<tr><td>MBR where only the MB is replaced (all other parts remain same) but new MB was taken from a previously used device that had NOT been Autopilot-enabled before.<td>Yes<td>
1. Deregister damaged device
2. Replace motherboard (with new RDPK preinjected in BIOS)
3. Reimage device (to gain access), unless have access to customers’ login credentials
4. Write old device info into BIOS (same s/n, model, etc.)
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
<tr><td>MBR where only the MB is replaced (all other parts remain same) but new MB was taken from a previously used device that HAD been Autopilot-enabled before.<td>Yes<td>
1. Deregister old device from which MB will be taken
2. Deregister damaged device (that you want to repair)
3. Replace motherboard in repair device with MB from other Autopilot device (with new RDPK preinjected in BIOS)
4. Reimage device (to gain access), unless have access to customers’ login credentials
5. Write old device info into BIOS (same s/n, model, etc.)
6. Capture new 4K HH
7. Reregister repaired device
8. Reset device back to OOBE
9. Go through Autopilot OOBE (customer)
10. Autopilot successfully enabled
<b>NOTE</b>: The repaired device can also be used successfully as a normal, non-Autopilot device.
<tr><td>BIOS info excluded from MBR device<td>No<td>Repair facility does not 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
4. Capture new 4K HH
5. Reregister repaired device
6. Create Autopilot profile for device
7. Go through Autopilot OOBE (customer)
8. Autopilot FAILS to recognize repaired device
<tr><td>MBR when there is no TPM chip<td>Yes<td>Though we do not recommend enabling an Autopilot devices without a TPM chip (which is recommended for BitLocker encryption), it is possible to enable an Autopilot devices in “standard user” mode (but NOT Self-deploying mode) that does not have a TPM chip. In this case, you would:
1. Deregister damaged device
2. Replace motherboard
3. Reimage device (to gain access), unless have access to customers’ login credentials
4. Write old device info into BIOS (same s/n, model, etc.)
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
<tr><td>New DPK written into image on repaired Autopilot device with a new MB<td>Yes<td>Repair facility replaces normal MB on damaged device. MB does not contain any DPK in the BIOS. Repair facility writes DPK into image after MBR.
1. Deregister damaged device
2. Replace motherboard – BIOS does NOT contain DPK info
3. Reimage device (to gain access), unless have access to customers’ login credentials
4. Write device info into BIOS (same s/n, model, etc.)
5. Capture new 4K HH
6. Reset or reimage device to pre-OOBE and write DPK into image
7. Reregister repaired device
8. Go through Autopilot OOBE
9. Autopilot successfully enabled
<tr><td>New Repair Product Key (RDPK)<td>Yes<td>Using a MB with a new RDPK preinjected results in a successful Autopilot refurbishment scenario.
1. Deregister damaged device
2. Replace motherboard (with new RDPK preinjected in BIOS)
3. Reimage or rest image to pre-OOBE
4. Write device info into BIOS
5. Capture new 4K HH
6. Reregister repaired device
7. Reimage or reset image to pre-OOBE
8. Go through Autopilot OOBE
9. Autopilot successfully enabled
<tr><td>No Repair Product Key (RDPK) injected<td>No<td>This scenario violates Microsoft policy and breaks the Windows Autopilot experience.
<tr><td>Reimage damaged Autopilot device that was not deregistered prior to repair<td>Yes, but the device will still be associated with previous tenant ID, so should only be returned to same customer<td>
1. Reimage damaged device
2. Write DPK into image
3. Go through Autopilot OOBE
4. Autopilot successfully enabled (to previous tenant ID)
<tr><td>Disk replacement from a non-Autopilot device to an Autopilot device<td>Yes<td>
1. Do not deregister damaged device prior to repair
2. Replace HDD on damaged device
3. Reimage or reset image back to OOBE
4. Go through Autopilot OOBE (customer)
5. Autopilot successfully enabled (repaired device recognized as its previous self)
<tr><td>Disk replacement from one Autopilot device to another Autopilot device<td>Maybe<td>If the device from which the HDD is taken was itself previously deregistered from Autopilot, then that HDD can be used in a repair device. But if the HDD was never previously deregistered from Autopilot before being used in a repaired device, the newly repaired device will not have the proper Autopilot experience.
Assuming the used HDD was previously deregistered (before being used in this repair):
1. Deregister damaged device
2. Replace HDD on damaged device using a HDD from another deregistered Autopilot device
3. Reimage or rest the repaired device back to a pre-OOBE state
4. Go through Autopilot OOBE (customer)
5. Autopilot successfully enabled
<tr><td>Third party network card replacement <td>No<td>Whether from a non-Autopilot device to an Autopilot device, from one Autopilot device to another Autopilot device, or from an Autopilot device to a non-Autopilot device, any scenario where a 3rd party (not onboard) Network card is replaced will break the Autopilot experience, and is not recommended.
<tr><td>A device repaired more than 3 times<td>No<td>Autopilot is not supported when a device is repeatedly repaired, so that whatever parts NOT replaced become associated with too many parts that have been replaced, which would make it difficult to uniquely identify that device in the future.
<tr><td>Memory replacement<td>Yes<td>Replacing the memory on a damaged device does not negatively affect the Autopilot experience on that device. No de/reregistration is needed. The repair technician simply needs to replace the memory.
<tr><td>GPU replacement<td>Yes<td>Replacing the GPU(s) on a damaged device does not negatively affect the Autopilot experience on that device. No de/reregistration is needed. The repair technician simply needs to replace the GPU.
</table>
>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.
**NOTE**: 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
| Question | Answer |
| --- | --- |
| If we have a tool that programs product information into the BIOS after the MBR, do we still need to submit a CBR report for the device to be Autopilot-capable? | No. Not if the in-house tool writes the minimum necessary information into the BIOS that the Autopilot program looks for to identify the device, as described earlier in this document. |
| What if only some components are replaced rather than the full motherboard? | While it’s true that some limited repairs do not prevent the Autopilot algorithm from successfully matching the post-repair device with the pre-repair device, it is 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 they don’t have the customer’s login credentials? | The technician will have to reimage the device and use their own credentials during the repair process. |
## Related topics

86
windows/deployment/windows-autopilot/autopilot-support.md
View File

@ -1,43 +1,43 @@
---
title: Windows Autopilot support
description: Support information for Windows Autopilot
keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: low
ms.sitesec: library
ms.pagetype: deploy
author: greg-lindsay
ms.author: greglin
ms.date: 10/31/2018
ms.reviewer:
manager: laurawi
ms.collection: M365-modern-desktop
ms.topic: article
---
# Windows Autopilot support information
**Applies to: Windows 10**
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](autopilot-faq.md).
| Audience | Support contact |
|---------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| OEM or Channel Partner registering devices as a CSP (via MPC) | Use the help resources available in MPC. Whether you are a 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 MSOEMOPS@microsoft.com. Response time depends on priority: <br>Low – 120 hours <br>Normal – 72 hours <br>High – 24 hours <br>Immediate – 4 hours |
| OEM with a PFE | Reach out to your PFE for support. |
| Partners with a Partner Technology Strategist (PTS) | If you have a PTS (whether you’re a CSP or not), you may first try working through your account’s specific Partner Technology Strategist (PTS). |
| Partners with an Ecosystem PM | If you have an Ecosystem PM (whether you’re a CSP or not), you may first try working through your account’s specific Ecosystem PM, especially for technical issues. |
| 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](https://partner.microsoft.com/support) 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](https://portal.azure.com/#blade/Microsoft_Azure_Support/HelpAndSupportBlade/overview). |
| Microsoft 365 Business | Support is accessible directly through the Microsoft 365 Business portal when logged in: https://support.microsoft.com/en-us. |
| Queries relating to MDA testing | Contact MDAHelp@microsoft.com. |
| All other queries, or when unsure who to contact | Contact msoemops@microsoft.com. |
---
title: Windows Autopilot support
description: Support information for Windows Autopilot
keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: low
ms.sitesec: library
ms.pagetype: deploy
audience: itpro
author: greg-lindsay
ms.author: greglin
ms.date: 10/31/2018
ms.reviewer:
manager: laurawi
ms.collection: M365-modern-desktop
ms.topic: article
---
# Windows Autopilot support information
**Applies to: Windows 10**
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](autopilot-faq.md).
| Audience | Support contact |
|---------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| OEM or Channel Partner registering devices as a CSP (via MPC) | Use the help resources available in MPC. Whether you are a 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 MSOEMOPS@microsoft.com. Response time depends on priority: <br>Low – 120 hours <br>Normal – 72 hours <br>High – 24 hours <br>Immediate – 4 hours |
| OEM with a PFE | Reach out to your PFE for support. |
| Partners with a Partner Technology Strategist (PTS) | If you have a PTS (whether you’re a CSP or not), you may first try working through your account’s specific Partner Technology Strategist (PTS). |
| Partners with an Ecosystem PM | If you have an Ecosystem PM (whether you’re a CSP or not), you may first try working through your account’s specific Ecosystem PM, especially for technical issues. |
| 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](https://partner.microsoft.com/support) 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](https://portal.azure.com/#blade/Microsoft_Azure_Support/HelpAndSupportBlade/overview). |
| Microsoft 365 Business | Support is accessible directly through the Microsoft 365 Business portal when logged in: https://support.microsoft.com/en-us. |
| Queries relating to MDA testing | Contact MDAHelp@microsoft.com. |
| All other queries, or when unsure who to contact | Contact msoemops@microsoft.com. |

108
windows/deployment/windows-autopilot/bitlocker.md
View File

@ -1,54 +1,54 @@
---
title: Setting the BitLocker encryption algorithm for Autopilot devices
ms.reviewer:
manager: laurawi
description: Microsoft Intune provides a comprehensive set of configuration options to manage BitLocker on Windows 10 devices.
keywords: Autopilot, BitLocker, encryption, 256-bit, Windows 10
ms.prod: w10
ms.technology: Windows
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: deploy
ms.localizationpriority: medium
author: greg-lindsay
ms.author: greglin
ms.collection: M365-modern-desktop
ms.topic: article
---
# Setting the BitLocker encryption algorithm for Autopilot devices
**Applies to**
- Windows 10
With Windows Autopilot, you can configure the BitLocker encryption settings to be applied before automatic encryption is started. This ensures that the default encrytion algorithm is not applied automatically when this is not the desired setting. Other BitLocker policies that must be applied prior to encryption can also be delivered before automatic BitLocker encryption begins.
The BitLocker encryption algorithm is used when BitLocker is first enabled, and sets the strength to which full volume encryption should occur. 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](https://docs.microsoft.com/windows/client-management/mdm/bitlocker-csp) for information about the recommended encryption algorithms to use.
To ensure the desired BitLocker encryption algorithm is set before automatic encryption occurs for Autopilot devices:
1. Configure the [encryption method settings](https://docs.microsoft.com/intune/endpoint-protection-windows-10#windows-encryption) in the Windows 10 Endpoint Protection profile to the desired encryption algorithm.
2. [Assign the policy](https://docs.microsoft.com/intune/device-profile-assign) to your Autopilot device group.
- **IMPORTANT**: The encryption policy must be assigned to **devices** in the group, not users.
3. Enable the Autopilot [Enrollment Status Page](https://docs.microsoft.com/windows/deployment/windows-autopilot/enrollment-status) (ESP) for these devices.
- **IMPORTANT**: If the ESP is not enabled, the policy will not apply before encryption starts.
An example of Microsoft Intune Windows Encryption settings is shown below.
![BitLocker encryption settings](images/bitlocker-encryption.png)
Note that a device which is encrypted automatically will need to be decrypted prior to changing the encyption algorithm.
The settings are available under Device Configuration -> Profiles -> Create profile -> Platform = Windows 10 and later, Profile type = Endpoint protection -> Configure -> Windows Encryption -> BitLocker base settings, Configure encryption methods = Enable.
Note: It is also recommended to set Windows Encryption -> Windows Settings -> Encrypt = **Require**.
## Requirements
Windows 10, version 1809 or later.
## See also
[Bitlocker overview](https://docs.microsoft.com/windows/security/information-protection/bitlocker/bitlocker-overview)
---
title: Setting the BitLocker encryption algorithm for Autopilot devices
ms.reviewer:
manager: laurawi
description: Microsoft Intune provides a comprehensive set of configuration options to manage BitLocker on Windows 10 devices.
keywords: Autopilot, BitLocker, encryption, 256-bit, Windows 10
ms.prod: w10
ms.technology: Windows
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: deploy
ms.localizationpriority: medium
audience: itpro
author: greg-lindsay
ms.author: greglin
ms.collection: M365-modern-desktop
ms.topic: article
---
# Setting the BitLocker encryption algorithm for Autopilot devices
**Applies to**
- Windows 10
With Windows Autopilot, you can configure the BitLocker encryption settings to be applied before automatic encryption is started. This ensures that the default encrytion algorithm is not applied automatically when this is not the desired setting. Other BitLocker policies that must be applied prior to encryption can also be delivered before automatic BitLocker encryption begins.
The BitLocker encryption algorithm is used when BitLocker is first enabled, and sets the strength to which full volume encryption should occur. 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](https://docs.microsoft.com/windows/client-management/mdm/bitlocker-csp) for information about the recommended encryption algorithms to use.
To ensure the desired BitLocker encryption algorithm is set before automatic encryption occurs for Autopilot devices:
1. Configure the [encryption method settings](https://docs.microsoft.com/intune/endpoint-protection-windows-10#windows-encryption) in the Windows 10 Endpoint Protection profile to the desired encryption algorithm.
2. [Assign the policy](https://docs.microsoft.com/intune/device-profile-assign) to your Autopilot device group.
- **IMPORTANT**: The encryption policy must be assigned to **devices** in the group, not users.
3. Enable the Autopilot [Enrollment Status Page](https://docs.microsoft.com/windows/deployment/windows-autopilot/enrollment-status) (ESP) for these devices.
- **IMPORTANT**: If the ESP is not enabled, the policy will not apply before encryption starts.
An example of Microsoft Intune Windows Encryption settings is shown below.
![BitLocker encryption settings](images/bitlocker-encryption.png)
Note that a device which is encrypted automatically will need to be decrypted prior to changing the encyption algorithm.
The settings are available under Device Configuration -> Profiles -> Create profile -> Platform = Windows 10 and later, Profile type = Endpoint protection -> Configure -> Windows Encryption -> BitLocker base settings, Configure encryption methods = Enable.
Note: It is also recommended to set Windows Encryption -> Windows Settings -> Encrypt = **Require**.
## Requirements
Windows 10, version 1809 or later.
## See also

1700
windows/deployment/windows-autopilot/demonstrate-deployment-on-vm.md
View File

File diff suppressed because it is too large Load Diff

78
windows/deployment/windows-autopilot/enrollment-status.md
View File

@ -1,39 +1,39 @@
---
title: Windows Autopilot Enrollment Status Page
ms.reviewer:
manager: laurawi
description: Gives an overview of the Enrollment Status Page capabilities, configuration
keywords: Autopilot Plug and Forget, Windows 10
ms.prod: w10
ms.technology: Windows
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: deploy
ms.localizationpriority: medium
author: greg-lindsay
ms.author: greglin
ms.collection: M365-modern-desktop
ms.topic: article
---
# 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. Within 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](https://docs.microsoft.com/intune/windows-enrollment-status).
![Enrollment Status Page](images/enrollment-status-page.png)
## More information
For more information on configuring the Enrollment Status Page, see the [Microsoft Intune documentation](https://docs.microsoft.com/intune/windows-enrollment-status).<br>
For details about the underlying implementation, see the [FirstSyncStatus details in the DMClient CSP documentation](https://docs.microsoft.com/windows/client-management/mdm/dmclient-csp).<br>
For more information about blocking for app installation:
- [Blocking for app installation using Enrollment Status Page](https://blogs.technet.microsoft.com/mniehaus/2018/12/06/blocking-for-app-installation-using-enrollment-status-page/).
- [Support Tip: Office C2R installation is now tracked during ESP](https://techcommunity.microsoft.com/t5/Intune-Customer-Success/Support-Tip-Office-C2R-installation-is-now-tracked-during-ESP/ba-p/295514).
---
title: Windows Autopilot Enrollment Status Page
ms.reviewer:
manager: laurawi
description: Gives an overview of the Enrollment Status Page capabilities, configuration
keywords: Autopilot Plug and Forget, Windows 10
ms.prod: w10
ms.technology: Windows
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: deploy
ms.localizationpriority: medium
audience: itpro
author: greg-lindsay
ms.author: greglin
ms.collection: M365-modern-desktop
ms.topic: article
---
# 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. Within 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](https://docs.microsoft.com/intune/windows-enrollment-status).
![Enrollment Status Page](images/enrollment-status-page.png)
## More information
For more information on configuring the Enrollment Status Page, see the [Microsoft Intune documentation](https://docs.microsoft.com/intune/windows-enrollment-status).<br>
For details about the underlying implementation, see the [FirstSyncStatus details in the DMClient CSP documentation](https://docs.microsoft.com/windows/client-management/mdm/dmclient-csp).<br>
For more information about blocking for app installation:
- [Blocking for app installation using Enrollment Status Page](https://blogs.technet.microsoft.com/mniehaus/2018/12/06/blocking-for-app-installation-using-enrollment-status-page/).

630
windows/deployment/windows-autopilot/existing-devices.md
View File

@ -1,315 +1,315 @@
---
title: Windows Autopilot for existing devices
description: Windows Autopilot deployment
keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune
ms.reviewer: mniehaus
manager: laurawi
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: medium
ms.sitesec: library
ms.pagetype: deploy
author: greg-lindsay
ms.author: greglin
ms.collection: M365-modern-desktop
ms.topic: article
---
# Windows Autopilot for existing devices
**Applies to: Windows 10**
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
- System Center Configuration Manager Current Branch (1806) OR System Center Configuration Manager Technical Preview (1808)
- The [Windows ADK](https://developer.microsoft.com/en-us/windows/hardware/windows-assessment-deployment-kit) 1803 or later
- Note: Config Mgr 1806 or later is required to [support](https://docs.microsoft.com/sccm/core/plan-design/configs/support-for-windows-10#windows-10-adk) the Windows ADK 1809.
- Assigned Microsoft Intune Licenses
- Azure Active Directory Premium
- Windows 10 version 1809 or later imported into Config Mgr as an Operating System Image
## Procedures
### Configure the Enrollment Status Page (optional)
If desired, you can set up an [enrollment status page](https://docs.microsoft.com/windows/deployment/windows-autopilot/enrollment-status) for Autopilot using Intune.
To enable and configure the enrollment and status page:
1. Open [Intune in the Azure portal](https://aka.ms/intuneportal).
2. Access **Intune > Device enrollment > Windows enrollment** and [Set up an enrollment status page](https://docs.microsoft.com/intune/windows-enrollment-status).
3. Access **Azure Active Directory > Mobility (MDM and MAM) > Microsoft Intune** and [Configure automatic MDM enrollment](https://docs.microsoft.com/sccm/mdm/deploy-use/enroll-hybrid-windows#enable-windows-10-automatic-enrollment) and configure the MDM user scope for some or all users.
See the following examples.
![enrollment status page](images/esp-config.png)<br><br>
![mdm](images/mdm-config.png)
### 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](https://www.microsoft.com/en-us/download/details.aspx?id=54616).
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
```powershell
Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force
Install-Module AzureAD -Force
Install-Module WindowsAutopilotIntune -Force
```
3. Enter the following lines and provide Intune administrative credentials
- In the following command, replace the example user principal name for Azure authentication (admin@M365x373186.onmicrosoft.com) with your user account. Be sure that the user account you specify has sufficient administrative rights.
```powershell
Connect-AutopilotIntune -user admin@M365x373186.onmicrosoft.com
```
The password for your account will be requested using a standard Azure AD form. Type your password and then click **Sign in**.
<br>See the following example:
![Azure AD authentication](images/pwd.png)
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
```powershell
Get-AutopilotProfile | ConvertTo-AutopilotConfigurationJSON
```
See the following sample output: (use the horizontal scroll bar at the bottom to view long lines)
<pre style="overflow-y: visible">
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\":\"M365x373186.onmicrosoft.com\"}}",
"CloudAssignedTenantDomain": "M365x373186.onmicrosoft.com",
"CloudAssignedDomainJoinMethod": 0,
"CloudAssignedOobeConfig": 28,
"ZtdCorrelationId": "7F9E6025-1E13-45F3-BF82-A3E8C5B59EAC"
}</pre>
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.
| Property | Description |
|------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Version (number, optional) | The version number that identifies the format of the JSON file. For Windows 10 1809, the version specified must be 2049. |
| 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, e.g. 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. <br>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, required) | An embedded JSON string used for branding. It requires AAD corp branding enabled. <br> Example value: "CloudAssignedAadServerData": "{\"ZeroTouchConfig\":{\"CloudAssignedTenantUpn\":\"\",\"CloudAssignedTenantDomain\":\"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)
```powershell
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.
![Notepad JSON](images/notepad.png)
After saving the file, move the file to a location suitable as an SCCM 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. <br><br>**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**.<br>
### Create a package containing the JSON file
1. In Configuration Manager, navigate to **\Software Library\Overview\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:<br>
- <u>Name</u>: **Autopilot for existing devices config**
- Select the **This package contains source files** checkbox
- <u>Source folder</u>: Click **Browse** and specify a UNC path containing the AutopilotConfigurationFile.json file.
- Click **OK** and then click **Next**.
- <u>Program Type</u>: **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 Config Mgr package.
### Create a target collection
>[!NOTE]
>You can also choose to reuse an existing collection
1. Navigate to **\Assets and Compliance\Overview\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:
- <u>Name</u>: **Autopilot for existing devices collection**
- Comment: (optional)
- <u>Limiting collection</u>: 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.
![Named resource1](images/pc-01a.png)
![Named resource2](images/pc-01b.png)
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 Library\Overview\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 Library\Overview\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:
- <u>Task sequence name</u>: **Autopilot for existing devices**
- <u>Boot Image</u>: 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 **Partition 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.
- <u>Product Key</u> and <u>Server licensing mode</u>: Optionally enter a product key and server licencing mode.
- <u>Randomly generate the local administrator password and disable the account on all support platforms (recommended)</u>: Optional.
- <u>Enable the account and specify the local administrator password</u>: 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 calls the System Preparation Tool (syeprep). This action will fail if the target machine is joined to a domain.
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]
>The Autopilot for existing devices task sequence will result in an Azure Active Directory Domain (AAD) joined device. The User State Migration Toolkit (USMT) does not support AAD joined or hybrid AAD 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:
- <u>Automatically build mass storage driver list</u>: **Not selected**
- <u>Do not reset activation flag</u>: **Not selected**
- <u>Shutdown the computer after running this action</u>: **Optional**
![Autopilot task sequence](images/ap-ts-1.png)
25. Click **OK** to close the Task Sequence Editor.
### 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 a 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:
- <u>Task Sequence</u>: **Autopilot for existing devices**.
- <u>Collection</u>: Click **Browse** and then select **Autopilot for existing devices collection** (or another collection you prefer).
- Click **Next** to specify **Deployment Settings**.
- <u>Action</u>: **Install**.
- <u>Purpose</u>: **Available**. You can optionally select **Required** instead of **Available**. This is not recommended during the test owing to the potential impact of inadvertent configurations.
- <u>Make available to the following</u>: **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.
- <u>Schedule when this deployment will become available</u>: Optional
- <u>Schedule when this deployment will expire</u>: Optional
- Click **Next** to specify **User Experience** details.
- <u>Show Task Sequence progress</u>: Selected.
- <u>Software Installation</u>: Not selected.
- <u>System restart (if required to complete the installation)</u>: Not selected.
- <u>Commit changed at deadline or during a maintenance windows (requires restart)</u>: Optional.
- <u>Allow task sequence to be run for client on the Internet</u>: Optional
- Click **Next** to specify **Alerts** details.
- <u>Create a deployment alert when the threshold is higher than the following</u>: Optional.
- Click **Next** to specify **Distribution Points** details.
- <u>Deployment options</u>: **Download content locally when needed by the running task sequence**.
- <u>When no local distribution point is available use a remote distribution point</u>: Optional.
- <u>Allow clients to use distribution points from the default site boundary group</u>: 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:
![Named resource2](images/sc.png)
![Named resource2](images/sc1.png)
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.
![refresh-1](images/up-1.png)
![refresh-2](images/up-2.png)
![refresh-3](images/up-3.png)
>[!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](https://docs.microsoft.com/windows/deployment/windows-autopilot/user-driven#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 **Convert all targeted devices to Autopilot** setting. For more information, see [Create an Autopilot deployment profile](https://docs.microsoft.com/intune/enrollment-autopilot#create-an-autopilot-deployment-profile).
Also see [Adding devices to Windows Autopilot](https://docs.microsoft.com/windows/deployment/windows-autopilot/add-devices).
## 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](https://blogs.technet.microsoft.com/mniehaus/2018/10/25/speeding-up-windows-autopilot-for-existing-devices/).
---
title: Windows Autopilot for existing devices
description: Windows Autopilot deployment
keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune
ms.reviewer: mniehaus
manager: laurawi
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: medium
ms.sitesec: library
ms.pagetype: deploy
audience: itpro
author: greg-lindsay
ms.author: greglin
ms.collection: M365-modern-desktop
ms.topic: article
---
# Windows Autopilot for existing devices
**Applies to: Windows 10**
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
- System Center Configuration Manager Current Branch (1806) OR System Center Configuration Manager Technical Preview (1808)
- The [Windows ADK](https://developer.microsoft.com/en-us/windows/hardware/windows-assessment-deployment-kit) 1803 or later
- Note: Config Mgr 1806 or later is required to [support](https://docs.microsoft.com/sccm/core/plan-design/configs/support-for-windows-10#windows-10-adk) the Windows ADK 1809.
- Assigned Microsoft Intune Licenses
- Azure Active Directory Premium
- Windows 10 version 1809 or later imported into Config Mgr as an Operating System Image
## Procedures
### Configure the Enrollment Status Page (optional)
If desired, you can set up an [enrollment status page](https://docs.microsoft.com/windows/deployment/windows-autopilot/enrollment-status) for Autopilot using Intune.
To enable and configure the enrollment and status page:
1. Open [Intune in the Azure portal](https://aka.ms/intuneportal).
2. Access **Intune > Device enrollment > Windows enrollment** and [Set up an enrollment status page](https://docs.microsoft.com/intune/windows-enrollment-status).
3. Access **Azure Active Directory > Mobility (MDM and MAM) > Microsoft Intune** and [Configure automatic MDM enrollment](https://docs.microsoft.com/sccm/mdm/deploy-use/enroll-hybrid-windows#enable-windows-10-automatic-enrollment) and configure the MDM user scope for some or all users.
See the following examples.
![enrollment status page](images/esp-config.png)<br><br>
![mdm](images/mdm-config.png)
### 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](https://www.microsoft.com/en-us/download/details.aspx?id=54616).
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
```powershell
Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force
Install-Module AzureAD -Force
Install-Module WindowsAutopilotIntune -Force
```
3. Enter the following lines and provide Intune administrative credentials
- In the following command, replace the example user principal name for Azure authentication (admin@M365x373186.onmicrosoft.com) with your user account. Be sure that the user account you specify has sufficient administrative rights.
```powershell
Connect-AutopilotIntune -user admin@M365x373186.onmicrosoft.com
```
The password for your account will be requested using a standard Azure AD form. Type your password and then click **Sign in**.
<br>See the following example:
![Azure AD authentication](images/pwd.png)
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
```powershell
Get-AutopilotProfile | ConvertTo-AutopilotConfigurationJSON
```
See the following sample output: (use the horizontal scroll bar at the bottom to view long lines)
<pre style="overflow-y: visible">
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\":\"M365x373186.onmicrosoft.com\"}}",
"CloudAssignedTenantDomain": "M365x373186.onmicrosoft.com",
"CloudAssignedDomainJoinMethod": 0,
"CloudAssignedOobeConfig": 28,
"ZtdCorrelationId": "7F9E6025-1E13-45F3-BF82-A3E8C5B59EAC"
}</pre>
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.
| Property | Description |
|------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Version (number, optional) | The version number that identifies the format of the JSON file. For Windows 10 1809, the version specified must be 2049. |
| 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, e.g. 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. <br>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, required) | An embedded JSON string used for branding. It requires AAD corp branding enabled. <br> Example value: "CloudAssignedAadServerData": "{\"ZeroTouchConfig\":{\"CloudAssignedTenantUpn\":\"\",\"CloudAssignedTenantDomain\":\"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)
```powershell
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.
![Notepad JSON](images/notepad.png)
After saving the file, move the file to a location suitable as an SCCM 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. <br><br>**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**.<br>
### Create a package containing the JSON file
1. In Configuration Manager, navigate to **\Software Library\Overview\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:<br>
- <u>Name</u>: **Autopilot for existing devices config**
- Select the **This package contains source files** checkbox
- <u>Source folder</u>: Click **Browse** and specify a UNC path containing the AutopilotConfigurationFile.json file.
- Click **OK** and then click **Next**.
- <u>Program Type</u>: **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 Config Mgr package.
### Create a target collection
>[!NOTE]
>You can also choose to reuse an existing collection
1. Navigate to **\Assets and Compliance\Overview\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:
- <u>Name</u>: **Autopilot for existing devices collection**
- Comment: (optional)
- <u>Limiting collection</u>: 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.
![Named resource1](images/pc-01a.png)
![Named resource2](images/pc-01b.png)
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 Library\Overview\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 Library\Overview\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:
- <u>Task sequence name</u>: **Autopilot for existing devices**
- <u>Boot Image</u>: 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 **Partition 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.
- <u>Product Key</u> and <u>Server licensing mode</u>: Optionally enter a product key and server licencing mode.
- <u>Randomly generate the local administrator password and disable the account on all support platforms (recommended)</u>: Optional.
- <u>Enable the account and specify the local administrator password</u>: 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 calls the System Preparation Tool (syeprep). This action will fail if the target machine is joined to a domain.
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]
>The Autopilot for existing devices task sequence will result in an Azure Active Directory Domain (AAD) joined device. The User State Migration Toolkit (USMT) does not support AAD joined or hybrid AAD 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:
- <u>Automatically build mass storage driver list</u>: **Not selected**
- <u>Do not reset activation flag</u>: **Not selected**
- <u>Shutdown the computer after running this action</u>: **Optional**
![Autopilot task sequence](images/ap-ts-1.png)
25. Click **OK** to close the Task Sequence Editor.
### 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 a 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:
- <u>Task Sequence</u>: **Autopilot for existing devices**.
- <u>Collection</u>: Click **Browse** and then select **Autopilot for existing devices collection** (or another collection you prefer).
- Click **Next** to specify **Deployment Settings**.
- <u>Action</u>: **Install**.
- <u>Purpose</u>: **Available**. You can optionally select **Required** instead of **Available**. This is not recommended during the test owing to the potential impact of inadvertent configurations.
- <u>Make available to the following</u>: **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.
- <u>Schedule when this deployment will become available</u>: Optional
- <u>Schedule when this deployment will expire</u>: Optional
- Click **Next** to specify **User Experience** details.
- <u>Show Task Sequence progress</u>: Selected.
- <u>Software Installation</u>: Not selected.
- <u>System restart (if required to complete the installation)</u>: Not selected.
- <u>Commit changed at deadline or during a maintenance windows (requires restart)</u>: Optional.
- <u>Allow task sequence to be run for client on the Internet</u>: Optional
- Click **Next** to specify **Alerts** details.
- <u>Create a deployment alert when the threshold is higher than the following</u>: Optional.
- Click **Next** to specify **Distribution Points** details.
- <u>Deployment options</u>: **Download content locally when needed by the running task sequence**.
- <u>When no local distribution point is available use a remote distribution point</u>: Optional.
- <u>Allow clients to use distribution points from the default site boundary group</u>: 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:
![Named resource2](images/sc.png)
![Named resource2](images/sc1.png)
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.
![refresh-1](images/up-1.png)
![refresh-2](images/up-2.png)
![refresh-3](images/up-3.png)
>[!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](https://docs.microsoft.com/windows/deployment/windows-autopilot/user-driven#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 **Convert all targeted devices to Autopilot** setting. For more information, see [Create an Autopilot deployment profile](https://docs.microsoft.com/intune/enrollment-autopilot#create-an-autopilot-deployment-profile).
Also see [Adding devices to Windows Autopilot](https://docs.microsoft.com/windows/deployment/windows-autopilot/add-devices).
## Speeding up the deployment process

1
windows/deployment/windows-autopilot/index.md
View File

@ -9,6 +9,7 @@ ms.mktglfcycl: deploy
ms.localizationpriority: medium
ms.sitesec: library
ms.pagetype: deploy
audience: itpro
author: greg-lindsay
ms.author: greglin
ms.collection: M365-modern-desktop

93
windows/deployment/windows-autopilot/known-issues.md
View File

@ -1,47 +1,46 @@
---
title: Windows Autopilot known issues
ms.reviewer:
manager: laurawi
description: Windows Autopilot deployment
keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: medium
ms.sitesec: library
ms.pagetype: deploy
audience: itpro
author: greg-lindsay
ms.author: greglin
ms.collection: M365-modern-desktop
ms.topic: article
---
# Windows Autopilot - known issues
**Applies to**
- Windows 10
<table>
<th>Issue<th>More information
<tr><td>The following known issues are resolved by installing the July 26, 2019 KB4505903 update (OS Build 18362.267):
- Windows Autopilot white glove does not work for a non-English OS and you see a red screen that says "Success."
- Windows Autopilot reports an AUTOPILOTUPDATE error during OOBE after sysprep, reset or other variations. This typically happens if you reset the OS or used a custom sysprepped image.
- BitLocker encryption is not correctly configured. Ex: BitLocker didn’t get an expected notification after policies were applied to begin encryption.
- You are unable to install UWP apps from the Microsoft Store, causing failures during Windows Autopilot. If you are deploying Company Portal as a blocking app during Windows Autopilot ESP, you’ve probably seen this error.
- A user is not granted administrator rights in the Windows Autopilot user-driven Hybrid Azure AD join scenario. This is another non-English OS issue.
<td>Download and install the <a href="https://support.microsoft.com/help/4505903">KB4505903 update</a>. <br><br>See the section: <b>How to get this update</b> for information on specific release channels you can use to obtain the update.
<tr><td>White glove gives a red screen and the <b>Microsoft-Windows-User Device Registration/Admin</b> event log displays <b>HResult error code 0x801C03F3</b><td>This can happen if Azure AD can’t find an AAD device object for the device that you are trying to deploy. This will occur if you manually delete the object. To fix it, remove the device from AAD, Intune, and Autopilot, then re-register it with Autopilot, which will recreate the AAD device object.<br>
<br>To obtain troubleshooting logs use: <b>Mdmdiagnosticstool.exe -area Autopilot;TPM -cab c:\autopilot.cab</b>
<tr><td>White glove gives a red screen<td>White glove is not supported on a VM.
<tr><td>Error importing Windows Autopilot devices from a .csv file<td>Ensure that you have not 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.
<tr><td>Windows Autopilot for existing devices does not follow the Autopilot OOBE experience.<td>Ensure that the JSON profile file is saved in <b>ANSI/ASCII</b> format, not Unicode or UTF-8.
<tr><td><b>Something went wrong</b> is displayed page during OOBE.<td>The client is likely unable to access all the required AAD/MSA-related URLs. For more information, see <a href="windows-autopilot-requirements.md#networking-requirements">Networking requirements</a>.
</table>
## Related topics
[Diagnose MDM failures in Windows 10](https://docs.microsoft.com/windows/client-management/mdm/diagnose-mdm-failures-in-windows-10)<br>
[Troubleshooting Windows Autopilot](troubleshooting.md)
---
title: Windows Autopilot known issues
ms.reviewer:
manager: laurawi
description: Windows Autopilot deployment
keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: medium
ms.sitesec: library
ms.pagetype: deploy
audience: itpro
author: greg-lindsay
ms.author: greglin
ms.collection: M365-modern-desktop
ms.topic: article
---
# Windows Autopilot - known issues
**Applies to**
- Windows 10
<table>
<th>Issue<th>More information
<tr><td>The following known issues are resolved by installing the July 26, 2019 KB4505903 update (OS Build 18362.267):
- Windows Autopilot white glove does not work for a non-English OS and you see a red screen that says "Success."
- Windows Autopilot reports an AUTOPILOTUPDATE error during OOBE after sysprep, reset or other variations. This typically happens if you reset the OS or used a custom sysprepped image.
- BitLocker encryption is not correctly configured. Ex: BitLocker didn’t get an expected notification after policies were applied to begin encryption.
- You are unable to install UWP apps from the Microsoft Store, causing failures during Windows Autopilot. If you are deploying Company Portal as a blocking app during Windows Autopilot ESP, you’ve probably seen this error.
- A user is not granted administrator rights in the Windows Autopilot user-driven Hybrid Azure AD join scenario. This is another non-English OS issue.
<td>Download and install the <a href="https://support.microsoft.com/help/4505903">KB4505903 update</a>. <br><br>See the section: <b>How to get this update</b> for information on specific release channels you can use to obtain the update.
<tr><td>White glove gives a red screen and the <b>Microsoft-Windows-User Device Registration/Admin</b> event log displays <b>HResult error code 0x801C03F3</b><td>This can happen if Azure AD can’t find an AAD device object for the device that you are trying to deploy. This will occur if you manually delete the object. To fix it, remove the device from AAD, Intune, and Autopilot, then re-register it with Autopilot, which will recreate the AAD device object.<br>
<br>To obtain troubleshooting logs use: <b>Mdmdiagnosticstool.exe -area Autopilot;TPM -cab c:\autopilot.cab</b>
<tr><td>White glove gives a red screen<td>White glove is not supported on a VM.
<tr><td>Error importing Windows Autopilot devices from a .csv file<td>Ensure that you have not 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.
<tr><td>Windows Autopilot for existing devices does not follow the Autopilot OOBE experience.<td>Ensure that the JSON profile file is saved in <b>ANSI/ASCII</b> format, not Unicode or UTF-8.
<tr><td><b>Something went wrong</b> is displayed page during OOBE.<td>The client is likely unable to access all the required AAD/MSA-related URLs. For more information, see <a href="windows-autopilot-requirements.md#networking-requirements">Networking requirements</a>.
</table>
## Related topics
[Diagnose MDM failures in Windows 10](https://docs.microsoft.com/windows/client-management/mdm/diagnose-mdm-failures-in-windows-10)<br>

96
windows/deployment/windows-autopilot/profiles.md
View File

@ -1,48 +1,48 @@
---
title: Configure Autopilot profiles
description: Windows Autopilot deployment
keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune
ms.reviewer: mniehaus
manager: laurawi
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: medium
ms.sitesec: library
ms.pagetype: deploy
author: greg-lindsay
ms.author: greglin
ms.collection: M365-modern-desktop
ms.topic: article
---
# 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](add-devices.md#registering-devices).
## Profile settings
The following profile settings are available:
- **Skip Cortana, 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 setup for work or school**. All devices registered with Autopilot will automatically be considered work or school devices, so this question will not be asked 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 automatically present a customized sign-in page with the organization’s name, logon, and additional help text, as configured in Azure Active Directory. See [Add company branding to your directory](https://docs.microsoft.com/azure/active-directory/customize-branding#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 (EULA)**. Starting in Windows 10 version 1709, 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**. Starting in Windows 10 version 1803, 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. See the [MDM documentation](https://docs.microsoft.com/windows/client-management/mdm/policy-csp-experience#experience-allowwindowsconsumerfeatures) for more details.
## Related topics
[Profile download](troubleshooting.md#profile-download)
[Registering devices](add-devices.md)
---
title: Configure Autopilot profiles
description: Windows Autopilot deployment
keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune
ms.reviewer: mniehaus
manager: laurawi
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: medium
ms.sitesec: library
ms.pagetype: deploy
audience: itpro
author: greg-lindsay
ms.author: greglin
ms.collection: M365-modern-desktop
ms.topic: article
---
# 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](add-devices.md#registering-devices).
## Profile settings
The following profile settings are available:
- **Skip Cortana, 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 setup for work or school**. All devices registered with Autopilot will automatically be considered work or school devices, so this question will not be asked 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 automatically present a customized sign-in page with the organization’s name, logon, and additional help text, as configured in Azure Active Directory. See [Add company branding to your directory](https://docs.microsoft.com/azure/active-directory/customize-branding#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 (EULA)**. Starting in Windows 10 version 1709, 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**. Starting in Windows 10 version 1803, 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. See the [MDM documentation](https://docs.microsoft.com/windows/client-management/mdm/policy-csp-experience#experience-allowwindowsconsumerfeatures) for more details.
## Related topics
[Profile download](troubleshooting.md#profile-download)

162
windows/deployment/windows-autopilot/registration-auth.md
View File

@ -1,81 +1,81 @@
---
title: Windows Autopilot customer consent
description: Windows Autopilot deployment
keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune
ms.reviewer: mniehaus
manager: laurawi
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: medium
ms.sitesec: library
ms.pagetype: deploy
author: greg-lindsay
ms.author: greglin
ms.collection: M365-modern-desktop
ms.topic: article
---
# Windows Autopilot customer consent
**Applies to: Windows 10**
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:
<table>
<tr><td>Direct CSP<td>Gets direct authorization from the customer to register devices.
<tr><td>Indirect CSP Provider<td>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.
<tr><td>Indirect CSP Reseller<td>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.
</table>
### 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:
![Request a reseller relationship](images/csp1.png)
- Select the checkbox indicating whether or not you want delegated admin rights:
![Delegated rights](images/csp2.png)
- 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 Store for Business or the Office 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 Store for Business (MSfB) clicks the link in the body of the email once they receive it from the CSP, which takes them directly to the following MSfB page:
![Global admin](images/csp3.png)
NOTE: A user without global admin privileges who clicks the link will see a message similar to the following:
![Not global admin](images/csp4.png)
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:
![Customers](images/csp5.png)
## OEM authorization
Each OEM has a unique link to provide to their respective customers, which the OEM can request from Microsoft via msoemops@microsoft.com.
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:
![Global admin](images/csp6.png)
NOTE: A user without global admin privileges who clicks the link will see a message similar to the following:
![Not global admin](images/csp7.png)
3. Customer selects the **Yes** checkbox, followed by the **Accept** button, and they’re done. Authorization happens instantaneously.
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](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.
## 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.
---
title: Windows Autopilot customer consent
description: Windows Autopilot deployment
keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune
ms.reviewer: mniehaus
manager: laurawi
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: medium
ms.sitesec: library
ms.pagetype: deploy
audience: itpro
author: greg-lindsay
ms.author: greglin
ms.collection: M365-modern-desktop
ms.topic: article
---
# Windows Autopilot customer consent
**Applies to: Windows 10**
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:
<table>
<tr><td>Direct CSP<td>Gets direct authorization from the customer to register devices.
<tr><td>Indirect CSP Provider<td>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.
<tr><td>Indirect CSP Reseller<td>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.
</table>
### 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:
![Request a reseller relationship](images/csp1.png)
- Select the checkbox indicating whether or not you want delegated admin rights:
![Delegated rights](images/csp2.png)
- 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 Store for Business or the Office 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 Store for Business (MSfB) clicks the link in the body of the email once they receive it from the CSP, which takes them directly to the following MSfB page:
![Global admin](images/csp3.png)
NOTE: A user without global admin privileges who clicks the link will see a message similar to the following:
![Not global admin](images/csp4.png)
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:
![Customers](images/csp5.png)
## OEM authorization
Each OEM has a unique link to provide to their respective customers, which the OEM can request from Microsoft via msoemops@microsoft.com.
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:
![Global admin](images/csp6.png)
NOTE: A user without global admin privileges who clicks the link will see a message similar to the following:
![Not global admin](images/csp7.png)
3. Customer selects the **Yes** checkbox, followed by the **Accept** button, and they’re done. Authorization happens instantaneously.
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](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.
## 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.

3
windows/deployment/windows-autopilot/self-deploying.md
View File

@ -9,6 +9,7 @@ ms.mktglfcycl: deploy
ms.localizationpriority: medium
ms.sitesec: library
ms.pagetype: deploy
audience: itpro
author: greg-lindsay
ms.author: greglin
ms.collection: M365-modern-desktop
@ -29,7 +30,7 @@ Self-deploying mode joins the device into Azure Active Directory, enrolls the de
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](https://docs.microsoft.com/windows/configuration/setup-kiosk-digital-signage#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](windows-autopilot-scenarios.md) and [Setting the BitLocker encryption algorithm for Autopilot devices](bitlocker.md).
>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](windows-autopilot-scenarios.md) and [Setting the BitLocker encryption algorithm for Autopilot devices](bitlocker.md).
![The user experience with Windows Autopilot self-deploying mode](images/self-deploy-welcome.png)

242
windows/deployment/windows-autopilot/troubleshooting.md
View File

@ -1,121 +1,121 @@
---
title: Troubleshooting Windows Autopilot
description: Windows Autopilot deployment
keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune
ms.reviewer: mniehaus
manager: laurawi
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: medium
ms.sitesec: library
ms.pagetype: deploy
author: greg-lindsay
ms.author: greglin
ms.collection: M365-modern-desktop
ms.topic: article
---
# Troubleshooting Windows Autopilot
**Applies to: Windows 10**
Windows Autopilot is designed to simplify all parts of the Windows device lifecycle, but there are always situations where issues may arise, either due to configuration or other issues. To assist with troubleshooting efforts, review the following information.
## Troubleshooting process
Regardless of whether performing user-driven or self-deploying device deployments, the troubleshooting process is the mostly the same. It is useful to understand the flow for a specific device:
- Network connection established. This can be a wireless (Wi-fi) or wired (Ethernet) connection.
- Windows Autopilot profile downloaded. Whether using a wired connection or manually establishing a wireless connection, the Windows Autopilot profile will be downloaded from the Autopilot deployment service as soon as the network connection is in place.
- User authentication. When performing a user-driven deployment, the user will enter their Azure Active Directory credentials, which will be validated.
- Azure Active Directory join. 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.
- Automatic MDM enrollment. As part of the Azure AD join process, the device will enroll in the MDM service configured in Azure AD (e.g. Microsoft Intune).
- Settings are applied. If the [enrollment status page](enrollment-status.md) 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](windows-autopilot-requirements.md)?
- Network connectivity. Can the device access the services described in [Windows Autopilot networking requirements](windows-autopilot-requirements.md)?
- Autopilot 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 OOBE issues
If the expected Autopilot behavior does not occur during the out-of-box experience (OOBE), it is useful to see whether the device received an Autopilot profile and what settings that profile contained. Depending on the Windows 10 release, there are different mechanisms available to do that.
### Windows 10 version 1803 and above
To see details related to the Autopilot profile settings and OOBE flow, Windows 10 version 1803 and above adds event log entries. These can be viewed using Event Viewer, navigating to the log at **Application and Services Logs –> Microsoft –> Windows –> Provisioning-Diagnostics-Provider –> AutoPilot**. The following events may be recorded, depending on the scenario and profile configuration.
| Event ID | Type | Description |
|----------|------|-------------|
| 100 | Warning | “AutoPilot policy [name] not found.” This 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 shows Autopilot retrieving and processing numeric OOBE settings. |
| 103 | Info | “AutoPilotGetPolicyStringByName succeeded: policy name = [name]; value = [value].” This 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 shows Autopilot retrieving and processing state-related OOBE settings. |
| 111 | Info | “AutoPilotRetrieveSettings succeeded.” This 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].” Typically this should say “ProfileState_Unknown” to “ProfileState_Available” to show that a profile was available for the device and downloaded, so the device is ready to be deployed using Autopilot. |
| 160 | Info | “AutoPilotRetrieveSettings beginning acquisition.” This 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 is not 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. |
| 164 | Info | “AutoPilotManager determined Internet is available to attempt policy download.” |
| 171 | Error | “AutoPilotManager failed to set TPM identity confirmed. HRESULT=[error code].” This 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 is typically related to event ID 171. |
In addition to the event log entries, the registry and ETW trace options described below also work with Windows 10 version 1803 and above.
### Windows 10 version 1709 and above
On Windows 10 version 1709 and above, information about the Autopilot profile settings are stored in the registry on the device after they are received from the Autopilot deployment service. These can be found at **HKLM\SOFTWARE\Microsoft\Provisioning\Diagnostics\AutoPilot**. Available registry entries include:
| Value | Description |
|-------|-------------|
| AadTenantId | The GUID of the Azure AD tenant the user signed into. This should match the tenant that the device was registered with; if it does not match the user will receive an error. |
| CloudAssignedTenantDomain | The Azure AD tenant the device has been registered with, e.g. “contosomn.onmicrosoft.com.” If the device is not registered with Autopilot, this value will be blank. |
| CloudAssignedTenantId | The GUID of the Azure AD tenant the device has been 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 indicates that the device is not registered with Autopilot. This could also indicate that the Autopilot profile could not be downloaded due to network connectivity or firewall issues, or network timeouts. |
| TenantMatched | This will be set to 1 if the tenant ID of the user matches the tenant ID that the device was registered with. If this is 0, the user would be shown an error and forced to start over. |
| CloudAssignedOobeConfig | This is a bitmap that shows which Autopilot settings were configured. Values include: SkipCortanaOptIn = 1, OobeUserNotLocalAdmin = 2, SkipExpressSettings = 4, SkipOemRegistration = 8, SkipEula = 16 |
### Windows 10 version 1703 and above
On Windows 10 version 1703 and above, ETW tracing can be used to capture detailed information from Autopilot and related components. The resulting ETW trace files can then be viewed using the Windows Performance Analyzer or similar tools. See [the advanced troubleshooting blog](https://blogs.technet.microsoft.com/mniehaus/2017/12/13/troubleshooting-windows-autopilot-level-300400/) for more information.
## Troubleshooting Azure AD Join issues
The most common issue joining a device to Azure AD is related to Azure AD permissions. Ensure [the correct configuration is in place](windows-autopilot-requirements.md) to allow users to join devices to Azure AD. Errors can also happen if the user has exceeded the number of devices that they are allowed to join, as configured in Azure AD.
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](https://support.microsoft.com/help/4089533/troubleshooting-windows-device-enrollment-problems-in-microsoft-intune) for assistance with Intune enrollment issues. Common issues include incorrect or missing licenses assigned to the user or 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 an error "Ran into trouble. Please sign in with an administrator account to see why and reset manually," see [Troubleshoot Autopilot Reset](https://docs.microsoft.com/education/windows/autopilot-reset#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 is important that a profile exists at this stage so that a blank profile is not cached locally on the PC. To remove the currently cached local profile in Windows 10 version 1803 and earlier, it is 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 on the version of Windows 10 that is running on the PC. See the following table.
| Windows 10 version | Profile download behavior |
| --- | --- |
| 1703 and 1709 | The profile is downloaded after the OOBE network connection page. This page is not displayed when using a wired connection. In this case, the profile is downloaded just prior to the EULA screen. |
| 1803 | The profile is downloaded as soon as possible. If wired, it is downloaded at the start of OOBE. If wireless, it is 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 shutdown immediately.
For more information, see [Windows Setup Command-Line Options](https://docs.microsoft.com/windows-hardware/manufacture/desktop/windows-setup-command-line-options).
## Related topics
[Windows Autopilot - known issues](known-issues.md)<br>
[Diagnose MDM failures in Windows 10](https://docs.microsoft.com/windows/client-management/mdm/diagnose-mdm-failures-in-windows-10)<br>
---
title: Troubleshooting Windows Autopilot
description: Windows Autopilot deployment
keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune
ms.reviewer: mniehaus
manager: laurawi
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: medium
ms.sitesec: library
ms.pagetype: deploy
audience: itpro
author: greg-lindsay
ms.author: greglin
ms.collection: M365-modern-desktop
ms.topic: article
---
# Troubleshooting Windows Autopilot
**Applies to: Windows 10**
Windows Autopilot is designed to simplify all parts of the Windows device lifecycle, but there are always situations where issues may arise, either due to configuration or other issues. To assist with troubleshooting efforts, review the following information.
## Troubleshooting process
Regardless of whether performing user-driven or self-deploying device deployments, the troubleshooting process is the mostly the same. It is useful to understand the flow for a specific device:
- Network connection established. This can be a wireless (Wi-fi) or wired (Ethernet) connection.
- Windows Autopilot profile downloaded. Whether using a wired connection or manually establishing a wireless connection, the Windows Autopilot profile will be downloaded from the Autopilot deployment service as soon as the network connection is in place.
- User authentication. When performing a user-driven deployment, the user will enter their Azure Active Directory credentials, which will be validated.
- Azure Active Directory join. 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.
- Automatic MDM enrollment. As part of the Azure AD join process, the device will enroll in the MDM service configured in Azure AD (e.g. Microsoft Intune).
- Settings are applied. If the [enrollment status page](enrollment-status.md) 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](windows-autopilot-requirements.md)?
- Network connectivity. Can the device access the services described in [Windows Autopilot networking requirements](windows-autopilot-requirements.md)?
- Autopilot 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 OOBE issues
If the expected Autopilot behavior does not occur during the out-of-box experience (OOBE), it is useful to see whether the device received an Autopilot profile and what settings that profile contained. Depending on the Windows 10 release, there are different mechanisms available to do that.
### Windows 10 version 1803 and above
To see details related to the Autopilot profile settings and OOBE flow, Windows 10 version 1803 and above adds event log entries. These can be viewed using Event Viewer, navigating to the log at **Application and Services Logs –> Microsoft –> Windows –> Provisioning-Diagnostics-Provider –> AutoPilot**. The following events may be recorded, depending on the scenario and profile configuration.
| Event ID | Type | Description |
|----------|------|-------------|
| 100 | Warning | “AutoPilot policy [name] not found.” This 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 shows Autopilot retrieving and processing numeric OOBE settings. |
| 103 | Info | “AutoPilotGetPolicyStringByName succeeded: policy name = [name]; value = [value].” This 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 shows Autopilot retrieving and processing state-related OOBE settings. |
| 111 | Info | “AutoPilotRetrieveSettings succeeded.” This 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].” Typically this should say “ProfileState_Unknown” to “ProfileState_Available” to show that a profile was available for the device and downloaded, so the device is ready to be deployed using Autopilot. |
| 160 | Info | “AutoPilotRetrieveSettings beginning acquisition.” This 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 is not 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. |
| 164 | Info | “AutoPilotManager determined Internet is available to attempt policy download.” |
| 171 | Error | “AutoPilotManager failed to set TPM identity confirmed. HRESULT=[error code].” This 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 is typically related to event ID 171. |
In addition to the event log entries, the registry and ETW trace options described below also work with Windows 10 version 1803 and above.
### Windows 10 version 1709 and above
On Windows 10 version 1709 and above, information about the Autopilot profile settings are stored in the registry on the device after they are received from the Autopilot deployment service. These can be found at **HKLM\SOFTWARE\Microsoft\Provisioning\Diagnostics\AutoPilot**. Available registry entries include:
| Value | Description |
|-------|-------------|
| AadTenantId | The GUID of the Azure AD tenant the user signed into. This should match the tenant that the device was registered with; if it does not match the user will receive an error. |
| CloudAssignedTenantDomain | The Azure AD tenant the device has been registered with, e.g. “contosomn.onmicrosoft.com.” If the device is not registered with Autopilot, this value will be blank. |
| CloudAssignedTenantId | The GUID of the Azure AD tenant the device has been 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 indicates that the device is not registered with Autopilot. This could also indicate that the Autopilot profile could not be downloaded due to network connectivity or firewall issues, or network timeouts. |
| TenantMatched | This will be set to 1 if the tenant ID of the user matches the tenant ID that the device was registered with. If this is 0, the user would be shown an error and forced to start over. |
| CloudAssignedOobeConfig | This is a bitmap that shows which Autopilot settings were configured. Values include: SkipCortanaOptIn = 1, OobeUserNotLocalAdmin = 2, SkipExpressSettings = 4, SkipOemRegistration = 8, SkipEula = 16 |
### Windows 10 version 1703 and above
On Windows 10 version 1703 and above, ETW tracing can be used to capture detailed information from Autopilot and related components. The resulting ETW trace files can then be viewed using the Windows Performance Analyzer or similar tools. See [the advanced troubleshooting blog](https://blogs.technet.microsoft.com/mniehaus/2017/12/13/troubleshooting-windows-autopilot-level-300400/) for more information.
## Troubleshooting Azure AD Join issues
The most common issue joining a device to Azure AD is related to Azure AD permissions. Ensure [the correct configuration is in place](windows-autopilot-requirements.md) to allow users to join devices to Azure AD. Errors can also happen if the user has exceeded the number of devices that they are allowed to join, as configured in Azure AD.
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](https://support.microsoft.com/help/4089533/troubleshooting-windows-device-enrollment-problems-in-microsoft-intune) for assistance with Intune enrollment issues. Common issues include incorrect or missing licenses assigned to the user or 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 an error "Ran into trouble. Please sign in with an administrator account to see why and reset manually," see [Troubleshoot Autopilot Reset](https://docs.microsoft.com/education/windows/autopilot-reset#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 is important that a profile exists at this stage so that a blank profile is not cached locally on the PC. To remove the currently cached local profile in Windows 10 version 1803 and earlier, it is 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 on the version of Windows 10 that is running on the PC. See the following table.
| Windows 10 version | Profile download behavior |
| --- | --- |
| 1703 and 1709 | The profile is downloaded after the OOBE network connection page. This page is not displayed when using a wired connection. In this case, the profile is downloaded just prior to the EULA screen. |
| 1803 | The profile is downloaded as soon as possible. If wired, it is downloaded at the start of OOBE. If wireless, it is 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 shutdown immediately.
For more information, see [Windows Setup Command-Line Options](https://docs.microsoft.com/windows-hardware/manufacture/desktop/windows-setup-command-line-options).
## Related topics
[Windows Autopilot - known issues](known-issues.md)<br>

198
windows/deployment/windows-autopilot/user-driven.md
View File

@ -1,99 +1,99 @@
---
title: Windows Autopilot User-Driven Mode
description: Windows Autopilot deployment
keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune
ms.reviewer: mniehaus
manager: laurawi
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: medium
ms.sitesec: library
ms.pagetype: deploy
author: greg-lindsay
ms.author: greglin
ms.collection: M365-modern-desktop
ms.topic: article
---
# Windows Autopilot user-driven mode
Windows Autopilot user-driven mode is designed to enable new Windows 10 devices to be transformed from their initial state, directly from the factory, into a ready-to-use state without requiring that IT personnel ever touch the device. The process is designed to be simple so that anyone can complete it, enabling devices to be shipped or distributed to the end user directly with simple instructions:
- Unbox the device, plug it in, and turn it on.
- Choose a language, locale and keyboard.
- Connect it to a wireless or wired network with internet access.
- Specify your e-mail address and password for your organization account.
After completing those simple steps, the remainder of the process is completely automated, with the device being joined to the organization, enrolled in Intune (or another MDM service), and fully configured as defined by the organization. Any additional prompts during the Out-of-Box Experience (OOBE) can be supressed; see [Configuring Autopilot Profiles](profiles.md) for options that are available.
Today, Windows Autopilot user-driven mode supports joining devices to Azure Active Directory. Support for Hybrid Azure Active Directory Join (with devices joined to an on-premises Active Directory domain) will be available in a future Windows 10 release. See [Introduction to device management in Azure Active Directory](https://docs.microsoft.com/azure/active-directory/device-management-introduction) for more information about the differences between these two join options.
## Available user-driven modes
The following options are available for user-driven deployment:
- [Azure Active Directory join](#user-driven-mode-for-azure-active-directory-join) is available if devices do not need to be joined to an on-prem Active Directory domain.
- [Hybrid Azure Active Directory join](#user-driven-mode-for-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
In order to perform a user-driven deployment using Windows Autopilot, the following preparation steps need to be completed:
- Ensure that the users who will be performing user-driven mode deployments are able to join devices to Azure Active Directory. See [Configure device settings](https://docs.microsoft.com/azure/active-directory/device-management-azure-portal#configure-device-settings) in the Azure Active Directory documentation for more information.
- 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 does not need to be selected.
- 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:
- Ensure that the device has been added to Windows Autopilot. This can be done automatically by an OEM or partner at the time the device is purchased, or it can be done through a manual harvesting process later. See [Adding devices to Windows Autopilot](add-devices.md) for more information.
- Ensure an Autopilot profile has been assigned to the device:
- If using Intune and Azure Active Directory dynamic device groups, this 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 (e.g. Microsoft Store for Business or Partner Center), manually assign an Autopilot profile to the device.
Also see the [Validation](#validation) section below.
### 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 and want to also join devices to your on-premises domain, you can accomplish this by configuring Autopilot devices to be [hybrid Azure Active Directory (AAD) joined](https://docs.microsoft.com/azure/active-directory/devices/hybrid-azuread-join-plan).
#### Requirements
To perform a user-driven hybrid AAD joined deployment using Windows Autopilot:
- 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.
- The device must be running Windows 10, version 1809 or later.
- The device must be able to access 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).
- The device must be able to access the Internet, following the [documented Windows Autopilot network requirements](windows-autopilot-requirements.md).
- The Intune Connector for Active Directory must be installed.
- Note: The Intune Connector will perform an on-prem AD join, therefore users do not need on-prem AD-join permission, assuming the Connector is [configured to perform this action](https://docs.microsoft.com/intune/windows-autopilot-hybrid#increase-the-computer-account-limit-in-the-organizational-unit) on the user's behalf.
- If using Proxy, WPAD Proxy settings option must be enabled and configured.
**AAD device join**: The hybrid AAD join process uses the system context to perform device AAD join, therefore it is not affected by user based AAD join permission settings. In addition, all users are enabled to join devices to AAD by default.
#### Step by step instructions
See [Deploy hybrid Azure AD joined devices using Intune and Windows Autopilot](https://docs.microsoft.com/intune/windows-autopilot-hybrid).
Also see the **Validation** section in the [Windows Autopilot user-driven mode](user-driven.md) topic.
## Validation
When performing a user-driven deployment using Windows Autopilot, the following end-user experience should be observed:
- 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.
- Once connected to a network, the Autopilot profile will be downloaded.
- Windows 10 will check for critical OOBE updates, and if any are available they will be automatically installed (rebooting if required).
- The user will be prompted for Azure Active Directory credentials, with a customized user experience showing the Azure AD tenant name, logo, and sign-in text.
- Once correct credentials have been entered, the device will join Azure Active Directory.
- After joining Azure Active Directory, the device will enroll in Intune (or other configured MDM services).
- If configured, the [enrollment status page](enrollment-status.md) will be displayed.
- Once the device configuration tasks have completed, the user will be signed into Windows 10 using the credentials they previously provided.
- Once signed in, the enrollment status page will again be displayed for user-targeted configuration tasks.
In case the observed results do not match these expectations, consult the [Windows Autopilot Troubleshooting](troubleshooting.md) documentation.
---
title: Windows Autopilot User-Driven Mode
description: Windows Autopilot deployment
keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune
ms.reviewer: mniehaus
manager: laurawi
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: medium
ms.sitesec: library
ms.pagetype: deploy
audience: itpro
author: greg-lindsay
ms.author: greglin
ms.collection: M365-modern-desktop
ms.topic: article
---
# Windows Autopilot user-driven mode
Windows Autopilot user-driven mode is designed to enable new Windows 10 devices to be transformed from their initial state, directly from the factory, into a ready-to-use state without requiring that IT personnel ever touch the device. The process is designed to be simple so that anyone can complete it, enabling devices to be shipped or distributed to the end user directly with simple instructions:
- Unbox the device, plug it in, and turn it on.
- Choose a language, locale and keyboard.
- Connect it to a wireless or wired network with internet access.
- Specify your e-mail address and password for your organization account.
After completing those simple steps, the remainder of the process is completely automated, with the device being joined to the organization, enrolled in Intune (or another MDM service), and fully configured as defined by the organization. Any additional prompts during the Out-of-Box Experience (OOBE) can be supressed; see [Configuring Autopilot Profiles](profiles.md) for options that are available.
Today, Windows Autopilot user-driven mode supports joining devices to Azure Active Directory. Support for Hybrid Azure Active Directory Join (with devices joined to an on-premises Active Directory domain) will be available in a future Windows 10 release. See [Introduction to device management in Azure Active Directory](https://docs.microsoft.com/azure/active-directory/device-management-introduction) for more information about the differences between these two join options.
## Available user-driven modes
The following options are available for user-driven deployment:
- [Azure Active Directory join](#user-driven-mode-for-azure-active-directory-join) is available if devices do not need to be joined to an on-prem Active Directory domain.
- [Hybrid Azure Active Directory join](#user-driven-mode-for-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
In order to perform a user-driven deployment using Windows Autopilot, the following preparation steps need to be completed:
- Ensure that the users who will be performing user-driven mode deployments are able to join devices to Azure Active Directory. See [Configure device settings](https://docs.microsoft.com/azure/active-directory/device-management-azure-portal#configure-device-settings) in the Azure Active Directory documentation for more information.
- 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 does not need to be selected.
- 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:
- Ensure that the device has been added to Windows Autopilot. This can be done automatically by an OEM or partner at the time the device is purchased, or it can be done through a manual harvesting process later. See [Adding devices to Windows Autopilot](add-devices.md) for more information.
- Ensure an Autopilot profile has been assigned to the device:
- If using Intune and Azure Active Directory dynamic device groups, this 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 (e.g. Microsoft Store for Business or Partner Center), manually assign an Autopilot profile to the device.
Also see the [Validation](#validation) section below.
### 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 and want to also join devices to your on-premises domain, you can accomplish this by configuring Autopilot devices to be [hybrid Azure Active Directory (AAD) joined](https://docs.microsoft.com/azure/active-directory/devices/hybrid-azuread-join-plan).
#### Requirements
To perform a user-driven hybrid AAD joined deployment using Windows Autopilot:
- 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.
- The device must be running Windows 10, version 1809 or later.
- The device must be able to access 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).
- The device must be able to access the Internet, following the [documented Windows Autopilot network requirements](windows-autopilot-requirements.md).
- The Intune Connector for Active Directory must be installed.
- Note: The Intune Connector will perform an on-prem AD join, therefore users do not need on-prem AD-join permission, assuming the Connector is [configured to perform this action](https://docs.microsoft.com/intune/windows-autopilot-hybrid#increase-the-computer-account-limit-in-the-organizational-unit) on the user's behalf.
- If using Proxy, WPAD Proxy settings option must be enabled and configured.
**AAD device join**: The hybrid AAD join process uses the system context to perform device AAD join, therefore it is not affected by user based AAD join permission settings. In addition, all users are enabled to join devices to AAD by default.
#### Step by step instructions
See [Deploy hybrid Azure AD joined devices using Intune and Windows Autopilot](https://docs.microsoft.com/intune/windows-autopilot-hybrid).
Also see the **Validation** section in the [Windows Autopilot user-driven mode](user-driven.md) topic.
## Validation
When performing a user-driven deployment using Windows Autopilot, the following end-user experience should be observed:
- 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.
- Once connected to a network, the Autopilot profile will be downloaded.
- Windows 10 will check for critical OOBE updates, and if any are available they will be automatically installed (rebooting if required).
- The user will be prompted for Azure Active Directory credentials, with a customized user experience showing the Azure AD tenant name, logo, and sign-in text.
- Once correct credentials have been entered, the device will join Azure Active Directory.
- After joining Azure Active Directory, the device will enroll in Intune (or other configured MDM services).
- If configured, the [enrollment status page](enrollment-status.md) will be displayed.
- Once the device configuration tasks have completed, the user will be signed into Windows 10 using the credentials they previously provided.
- Once signed in, the enrollment status page will again be displayed for user-targeted configuration tasks.

4
windows/deployment/windows-autopilot/white-glove.md
View File

@ -7,9 +7,11 @@ ms.mktglfcycl: deploy
ms.localizationpriority: low
ms.sitesec: library
ms.pagetype: deploy
audience: itpro
author: greg-lindsay
manager: laurawi
ms.author: greg-lindsay
ms.audience: itpro
author: greg-lindsay
ms.collection: M365-modern-desktop
ms.topic: article
---

242
windows/deployment/windows-autopilot/windows-autopilot-requirements.md
View File

@ -1,121 +1,121 @@
---
title: Windows Autopilot requirements
ms.reviewer:
manager: laurawi
description: Windows Autopilot deployment
keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: medium
ms.sitesec: library
ms.pagetype: deploy
author: greg-lindsay
ms.author: greglin
ms.collection: M365-modern-desktop
ms.topic: article
---
# Windows Autopilot requirements
**Applies to: Windows 10**
Windows Autopilot depends on specific capabilities available in Windows 10, Azure Active Directory, and MDM services such as Microsoft Intune. In order to use Windows Autopilot and leverage these capabilities, some requirements must be met.
**Note**: For a list of OEMs that currently support Windows Autopilot, see the Participant device manufacturers section at [Windows Autopilot](https://aka.ms/windowsautopilot).
## Software requirements
- Windows 10 version 1703 (semi-annual channel) or higher is required.
- 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
## 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:
- Ensure DNS name resolution for internet DNS names
- Allow access to all hosts via port 80 (HTTP), 443 (HTTPS), and 123 (UDP/NTP)
In environments that have more restrictive Internet access, or for those that require authentication before internet access can be obtained, additional configuration may be required to whitelist access to the required services. For additional details about each of these services and their specific requirements, review the following details:
<table><th>Service<th>Information
<tr><td><b>Windows Autopilot Deployment Service and Windows Activation<b><td>After a network connection is in place, each Windows 10 device will contact the Windows Autopilot Deployment Service. With Windows 10 builds 18204 and above, the following URLs are used: https://ztd.dds.microsoft.com, https://cs.dds.microsoft.com. <br>
For all supported Windows 10 releases, Windows Autopilot also uses Windows Activation services. See <a href="https://support.microsoft.com/help/921471/windows-activation-or-validation-fails-with-error-code-0x8004fe33">Windows activation or validation fails with error code 0x8004FE33</a> for details about problems that might occur when you connect to the Internet through a proxy server.
<tr><td><b>Azure Active Directory<b><td>User credentials are validated by Azure Active Directory, and the device can also be joined to Azure Active Directory. See <a href="https://docs.microsoft.com/office365/enterprise/office-365-ip-web-service">Office 365 IP Address and URL Web service</a> for more information.
<tr><td><b>Intune<b><td>Once authenticated, Azure Active Directory will trigger enrollment of the device into the Intune MDM service. See the following link for details about network communication requirements: <a href="https://docs.microsoft.com/intune/network-bandwidth-use#network-communication-requirements">Intune network configuration requirements and bandwidth</a>.
<tr><td><b>Windows Update<b><td>During the OOBE process, as well as after the Windows 10 OS is fully configured, the Windows Update service is leveraged to retrieve needed updates. If there are problems connecting to Windows Update, see <a href="https://support.microsoft.com/help/818018/how-to-solve-connection-problems-concerning-windows-update-or-microsof">How to solve connection problems concerning Windows Update or Microsoft Update</a>.<br>
If Windows Update is inaccessible, the AutoPilot process will still continue but critical updates will not be available.
<tr><td><b>Delivery Optimization<b><td>When downloading Windows Updates, Microsoft Store apps and app updates, Office Updates and Intune Win32 Apps, the <a href="https://docs.microsoft.com/windows/deployment/update/waas-delivery-optimization">Delivery Optimization</a> service is contacted to enable peer-to-peer sharing of content so that only a few devices need to download it from the internet.<br>
If the Delivery Optimization Service is inaccessible, the AutoPilot process will still continue with Delivery Optimization downloads from the cloud (without peer-to-peer).
<tr><td><b>Network Time Protocol (NTP) Sync<b><td>When a Windows device starts up, it will talk to a network time server to ensure that the time on the device is accurate. Ensure that UDP port 123 to time.windows.com is accessible.
<tr><td><b>Domain Name Services (DNS)<b><td>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.
<tr><td><b>Diagnostics data<b><td>Starting in Windows 10, 1903, diagnostic data collection will be enabled by default. To disable Windows Analytics and related diagnostics capabilities, see <a href="https://docs.microsoft.com/windows/privacy/configure-windows-diagnostic-data-in-your-organization#manage-enterprise-diagnostic-data-level">Manage enterprise diagnostic data level</a>.<br>
If diagnostic data cannot be sent, the Autopilot process will still continue, but services that depend on diagnostic data, such as Windows Analytics, will not work.
<tr><td><b>Network Connection Status Indicator (NCSI)<b><td>Windows must be able to tell that the device is able to access the internet. For more information, see <a href="https://docs.microsoft.com/windows/privacy/manage-windows-1709-endpoints#network-connection-status-indicator-ncsi">Network Connection Status Indicator (NCSI)</a>.
<a href="http://www.msftconnecttest.com">www.msftconnecttest.com</a> must be resolvable via DNS and accessible via HTTP.
<tr><td><b>Windows Notification Services (WNS)<b><td>This service is used to enable Windows to receive notifications from apps and services. See <a href="https://docs.microsoft.com/windows/privacy/manage-windows-1809-endpoints#microsoft-store">Microsoft Store</a> for more information.<br>
If the WNS services are not available, the Autopilot process will still continue without notifications.
<tr><td><b>Microsoft Store, Microsoft Store for Business<b><td>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 <a href="https://docs.microsoft.com/microsoft-store/prerequisites-microsoft-store-for-business">Prerequisites for Microsoft Store for Business and Education</a> (also includes Azure AD and Windows Notification Services).<br>
If the Microsoft Store is not accessible, the AutoPilot process will still continue without Microsoft Store apps.
<tr><td><b>Office 365<b><td>As part of the Intune device configuration, installation of Office 365 ProPlus may be required. For more information, see <a href="https://support.office.com/en-us/article/Office-365-URLs-and-IP-address-ranges-8548a211-3fe7-47cb-abb1-355ea5aa88a2">Office 365 URLs and IP address ranges</a> (includes all Office services, DNS names, IP addresses; includes Azure AD and other services that may overlap with those listed above).
<tr><td><b>Certificate revocation lists (CRLs)<b><td>Some of these services will also need to check certificate revocation lists (CRLs) for certificates used in the services.  A full list of these is documented at <a href="https://support.office.com/en-us/article/Office-365-URLs-and-IP-address-ranges-8548a211-3fe7-47cb-abb1-355ea5aa88a2#bkmk_crl">Office 365 URLs and IP address ranges</a> and <a href="https://aka.ms/o365chains">Office 365 Certificate Chains</a>.
<tr><td><b>Hybrid AAD join<b><td>Hybrid AAD can be join, the machine should be on corporate network for hybrid AAD join to work. See details at <a href="https://docs.microsoft.com/windows/deployment/windows-autopilot/user-driven-hybrid">Windows Autopilot user-driven mode</a>
</table>
## 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 is required:
- [Microsoft 365 Business subscriptions](https://www.microsoft.com/en-us/microsoft-365/business)
- [Microsoft 365 F1 subscriptions](https://www.microsoft.com/en-us/microsoft-365/enterprise/firstline)
- [Microsoft 365 Academic A1, A3, or A5 subscriptions](https://www.microsoft.com/en-us/education/buy-license/microsoft365/default.aspx)
- [Microsoft 365 Enterprise E3 or E5 subscriptions](https://www.microsoft.com/en-us/microsoft-365/enterprise), which include all Windows 10, Office 365, and EM+S features (Azure AD and Intune).
- [Enterprise Mobility + Security E3 or E5 subscriptions](https://www.microsoft.com/en-us/cloud-platform/enterprise-mobility-security), which include all needed Azure AD and Intune features.
- [Intune for Education subscriptions](https://docs.microsoft.com/intune-education/what-is-intune-for-education), which include all needed Azure AD and Intune features.
- [Azure Active Directory Premium P1 or P2](https://azure.microsoft.com/services/active-directory/) and [Microsoft Intune subscriptions](https://www.microsoft.com/en-us/cloud-platform/microsoft-intune) (or an alternative MDM service).
Additionally, the following are also recommended (but not required):
- [Office 365 ProPlus](https://www.microsoft.com/en-us/p/office-365-proplus/CFQ7TTC0K8R0), which can be deployed easily via Intune (or other MDM services).
- [Windows Subscription Activation](https://docs.microsoft.com/windows/deployment/windows-10-enterprise-subscription-activation), to automatically step up devices from Windows 10 Pro to Windows 10 Enterprise.
## 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](https://docs.microsoft.com/intune/windows-enroll#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. In order to display an organization-specific logon page during the Autopilot process, Azure Active Directory 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](https://docs.microsoft.com/azure/active-directory/fundamentals/customize-branding) for more details. Note that the "square logo" and "sign-in page text" are the key elements for Autopilot, as well as the Azure Active Directory tenant name (configured separately in the Azure AD tenant properties).
- Enable [Windows Subscription Activation](https://docs.microsoft.com/windows/deployment/windows-10-enterprise-subscription-activation) if desired, in order to automatically step up from Windows 10 Pro to Windows 10 Enterprise.
Specific scenarios will then have additional requirements. Generally, there are two specific tasks:
- Device registration. Devices need to be added to Windows Autopilot to support most Windows Autopilot scenarios. See [Adding devices to Windows Autopilot](add-devices.md) for more details.
- 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](profiles.md) for details. Note that Microsoft Intune can automate this profile assignment; see [Create an AutoPilot device group](https://docs.microsoft.com/intune/enrollment-autopilot#create-an-autopilot-device-group) and [Assign an AutoPilot deployment profile to a device group](https://docs.microsoft.com/intune/enrollment-autopilot#assign-an-autopilot-deployment-profile-to-a-device-group) for more information.
See [Windows Autopilot Scenarios](windows-autopilot-scenarios.md) for additional details.
For a walkthrough for some of these and related steps, see this video:
<br>&nbsp;<br>
<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/KYVptkpsOqs" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
There are no additional hardware requirements to use Windows 10 Autopilot, beyond the [requirements to run Windows 10](https://www.microsoft.com/windows/windows-10-specifications).
## Related topics
[Configure Autopilot deployment](configure-autopilot.md)
---
title: Windows Autopilot requirements
ms.reviewer:
manager: laurawi
description: Windows Autopilot deployment
keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: medium
ms.sitesec: library
ms.pagetype: deploy
audience: itpro
author: greg-lindsay
ms.author: greglin
ms.collection: M365-modern-desktop
ms.topic: article
---
# Windows Autopilot requirements
**Applies to: Windows 10**
Windows Autopilot depends on specific capabilities available in Windows 10, Azure Active Directory, and MDM services such as Microsoft Intune. In order to use Windows Autopilot and leverage these capabilities, some requirements must be met.
**Note**: For a list of OEMs that currently support Windows Autopilot, see the Participant device manufacturers section at [Windows Autopilot](https://aka.ms/windowsautopilot).
## Software requirements
- Windows 10 version 1703 (semi-annual channel) or higher is required.
- 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
## 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:
- Ensure DNS name resolution for internet DNS names
- Allow access to all hosts via port 80 (HTTP), 443 (HTTPS), and 123 (UDP/NTP)
In environments that have more restrictive Internet access, or for those that require authentication before internet access can be obtained, additional configuration may be required to whitelist access to the required services. For additional details about each of these services and their specific requirements, review the following details:
<table><th>Service<th>Information
<tr><td><b>Windows Autopilot Deployment Service and Windows Activation<b><td>After a network connection is in place, each Windows 10 device will contact the Windows Autopilot Deployment Service. With Windows 10 builds 18204 and above, the following URLs are used: https://ztd.dds.microsoft.com, https://cs.dds.microsoft.com. <br>
For all supported Windows 10 releases, Windows Autopilot also uses Windows Activation services. See <a href="https://support.microsoft.com/help/921471/windows-activation-or-validation-fails-with-error-code-0x8004fe33">Windows activation or validation fails with error code 0x8004FE33</a> for details about problems that might occur when you connect to the Internet through a proxy server.
<tr><td><b>Azure Active Directory<b><td>User credentials are validated by Azure Active Directory, and the device can also be joined to Azure Active Directory. See <a href="https://docs.microsoft.com/office365/enterprise/office-365-ip-web-service">Office 365 IP Address and URL Web service</a> for more information.
<tr><td><b>Intune<b><td>Once authenticated, Azure Active Directory will trigger enrollment of the device into the Intune MDM service. See the following link for details about network communication requirements: <a href="https://docs.microsoft.com/intune/network-bandwidth-use#network-communication-requirements">Intune network configuration requirements and bandwidth</a>.
<tr><td><b>Windows Update<b><td>During the OOBE process, as well as after the Windows 10 OS is fully configured, the Windows Update service is leveraged to retrieve needed updates. If there are problems connecting to Windows Update, see <a href="https://support.microsoft.com/help/818018/how-to-solve-connection-problems-concerning-windows-update-or-microsof">How to solve connection problems concerning Windows Update or Microsoft Update</a>.<br>
If Windows Update is inaccessible, the AutoPilot process will still continue but critical updates will not be available.
<tr><td><b>Delivery Optimization<b><td>When downloading Windows Updates, Microsoft Store apps and app updates, Office Updates and Intune Win32 Apps, the <a href="https://docs.microsoft.com/windows/deployment/update/waas-delivery-optimization">Delivery Optimization</a> service is contacted to enable peer-to-peer sharing of content so that only a few devices need to download it from the internet.<br>
If the Delivery Optimization Service is inaccessible, the AutoPilot process will still continue with Delivery Optimization downloads from the cloud (without peer-to-peer).
<tr><td><b>Network Time Protocol (NTP) Sync<b><td>When a Windows device starts up, it will talk to a network time server to ensure that the time on the device is accurate. Ensure that UDP port 123 to time.windows.com is accessible.
<tr><td><b>Domain Name Services (DNS)<b><td>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.
<tr><td><b>Diagnostics data<b><td>Starting in Windows 10, 1903, diagnostic data collection will be enabled by default. To disable Windows Analytics and related diagnostics capabilities, see <a href="https://docs.microsoft.com/windows/privacy/configure-windows-diagnostic-data-in-your-organization#manage-enterprise-diagnostic-data-level">Manage enterprise diagnostic data level</a>.<br>
If diagnostic data cannot be sent, the Autopilot process will still continue, but services that depend on diagnostic data, such as Windows Analytics, will not work.
<tr><td><b>Network Connection Status Indicator (NCSI)<b><td>Windows must be able to tell that the device is able to access the internet. For more information, see <a href="https://docs.microsoft.com/windows/privacy/manage-windows-1709-endpoints#network-connection-status-indicator-ncsi">Network Connection Status Indicator (NCSI)</a>.
<a href="http://www.msftconnecttest.com">www.msftconnecttest.com</a> must be resolvable via DNS and accessible via HTTP.
<tr><td><b>Windows Notification Services (WNS)<b><td>This service is used to enable Windows to receive notifications from apps and services. See <a href="https://docs.microsoft.com/windows/privacy/manage-windows-1809-endpoints#microsoft-store">Microsoft Store</a> for more information.<br>
If the WNS services are not available, the Autopilot process will still continue without notifications.
<tr><td><b>Microsoft Store, Microsoft Store for Business<b><td>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 <a href="https://docs.microsoft.com/microsoft-store/prerequisites-microsoft-store-for-business">Prerequisites for Microsoft Store for Business and Education</a> (also includes Azure AD and Windows Notification Services).<br>
If the Microsoft Store is not accessible, the AutoPilot process will still continue without Microsoft Store apps.
<tr><td><b>Office 365<b><td>As part of the Intune device configuration, installation of Office 365 ProPlus may be required. For more information, see <a href="https://support.office.com/en-us/article/Office-365-URLs-and-IP-address-ranges-8548a211-3fe7-47cb-abb1-355ea5aa88a2">Office 365 URLs and IP address ranges</a> (includes all Office services, DNS names, IP addresses; includes Azure AD and other services that may overlap with those listed above).
<tr><td><b>Certificate revocation lists (CRLs)<b><td>Some of these services will also need to check certificate revocation lists (CRLs) for certificates used in the services.  A full list of these is documented at <a href="https://support.office.com/en-us/article/Office-365-URLs-and-IP-address-ranges-8548a211-3fe7-47cb-abb1-355ea5aa88a2#bkmk_crl">Office 365 URLs and IP address ranges</a> and <a href="https://aka.ms/o365chains">Office 365 Certificate Chains</a>.
<tr><td><b>Hybrid AAD join<b><td>Hybrid AAD can be join, the machine should be on corporate network for hybrid AAD join to work. See details at <a href="https://docs.microsoft.com/windows/deployment/windows-autopilot/user-driven-hybrid">Windows Autopilot user-driven mode</a>
</table>
## 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 is required:
- [Microsoft 365 Business subscriptions](https://www.microsoft.com/en-us/microsoft-365/business)
- [Microsoft 365 F1 subscriptions](https://www.microsoft.com/en-us/microsoft-365/enterprise/firstline)
- [Microsoft 365 Academic A1, A3, or A5 subscriptions](https://www.microsoft.com/en-us/education/buy-license/microsoft365/default.aspx)
- [Microsoft 365 Enterprise E3 or E5 subscriptions](https://www.microsoft.com/en-us/microsoft-365/enterprise), which include all Windows 10, Office 365, and EM+S features (Azure AD and Intune).
- [Enterprise Mobility + Security E3 or E5 subscriptions](https://www.microsoft.com/en-us/cloud-platform/enterprise-mobility-security), which include all needed Azure AD and Intune features.
- [Intune for Education subscriptions](https://docs.microsoft.com/intune-education/what-is-intune-for-education), which include all needed Azure AD and Intune features.
- [Azure Active Directory Premium P1 or P2](https://azure.microsoft.com/services/active-directory/) and [Microsoft Intune subscriptions](https://www.microsoft.com/en-us/cloud-platform/microsoft-intune) (or an alternative MDM service).
Additionally, the following are also recommended (but not required):
- [Office 365 ProPlus](https://www.microsoft.com/en-us/p/office-365-proplus/CFQ7TTC0K8R0), which can be deployed easily via Intune (or other MDM services).
- [Windows Subscription Activation](https://docs.microsoft.com/windows/deployment/windows-10-enterprise-subscription-activation), to automatically step up devices from Windows 10 Pro to Windows 10 Enterprise.
## 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](https://docs.microsoft.com/intune/windows-enroll#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. In order to display an organization-specific logon page during the Autopilot process, Azure Active Directory 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](https://docs.microsoft.com/azure/active-directory/fundamentals/customize-branding) for more details. Note that the "square logo" and "sign-in page text" are the key elements for Autopilot, as well as the Azure Active Directory tenant name (configured separately in the Azure AD tenant properties).
- Enable [Windows Subscription Activation](https://docs.microsoft.com/windows/deployment/windows-10-enterprise-subscription-activation) if desired, in order to automatically step up from Windows 10 Pro to Windows 10 Enterprise.
Specific scenarios will then have additional requirements. Generally, there are two specific tasks:
- Device registration. Devices need to be added to Windows Autopilot to support most Windows Autopilot scenarios. See [Adding devices to Windows Autopilot](add-devices.md) for more details.
- 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](profiles.md) for details. Note that Microsoft Intune can automate this profile assignment; see [Create an AutoPilot device group](https://docs.microsoft.com/intune/enrollment-autopilot#create-an-autopilot-device-group) and [Assign an AutoPilot deployment profile to a device group](https://docs.microsoft.com/intune/enrollment-autopilot#assign-an-autopilot-deployment-profile-to-a-device-group) for more information.
See [Windows Autopilot Scenarios](windows-autopilot-scenarios.md) for additional details.
For a walkthrough for some of these and related steps, see this video:
<br>&nbsp;<br>
<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/KYVptkpsOqs" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
There are no additional hardware requirements to use Windows 10 Autopilot, beyond the [requirements to run Windows 10](https://www.microsoft.com/windows/windows-10-specifications).
## Related topics

270
windows/deployment/windows-autopilot/windows-autopilot-reset.md
View File

@ -1,135 +1,135 @@
---
title: Windows Autopilot Reset
description: Windows Autopilot deployment
keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune
ms.reviewer: mniehaus
manager: laurawi
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: medium
ms.sitesec: library
ms.pagetype: deploy
author: greg-lindsay
ms.author: greglin
ms.collection: M365-modern-desktop
ms.topic: article
---
# 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.
>[!NOTE]
>The Autopilot Reset does not support Hybrid Azure AD joined devices.
## Scenarios
Windows Autopilot Reset supports two scenarios:
- [Local reset](#reset-devices-with-local-windows-autopilot-reset) initiated by IT personnel or other administrators from the organization.
- [Remote reset](#reset-devices-with-remote-windows-autopilot-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](https://docs.microsoft.com/intune/users-add).
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](#enable-local-windows-autopilot-reset)
2. [Trigger a reset for each device](#trigger-local-windows-autopilot-reset)
### 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](https://docs.microsoft.com/windows/client-management/mdm/policy-csp-credentialproviders), **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](https://docs.microsoft.com/windows/configuration/provisioning-packages/provisioning-create-package) 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 + ![Windows key](images/windows_glyph.png) + R**.
![Enter CTRL+Windows key+R on the Windows lockscreen](images/autopilot-reset-lockscreen.png)
This will open up a custom login screen for the local Autopilot Reset. The screen serves two purposes:
1. Confirm/verify that the end user has the right to trigger Local Autopilot Reset
2. Notify the user in case a provisioning package, created using Windows Configuration Designer, will be used as part of the process.
![Custom login screen for local Autopilot Reset](images/autopilot-reset-customlogin.png)
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
**Applies to: Windows 10, version 1809 or later**
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](self-deploying.md).
### 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)](https://docs.microsoft.com/windows-hardware/manufacture/desktop/windows-recovery-environment--windows-re--technical-reference) 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](https://docs.microsoft.com/windows-hardware/manufacture/desktop/reagentc-command-line-options) 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](https://support.microsoft.com) for assistance.
---
title: Windows Autopilot Reset
description: Windows Autopilot deployment
keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune
ms.reviewer: mniehaus
manager: laurawi
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: medium
ms.sitesec: library
ms.pagetype: deploy
audience: itpro
author: greg-lindsay
ms.author: greglin
ms.collection: M365-modern-desktop
ms.topic: article
---
# 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.
>[!NOTE]
>The Autopilot Reset does not support Hybrid Azure AD joined devices.
## Scenarios
Windows Autopilot Reset supports two scenarios:
- [Local reset](#reset-devices-with-local-windows-autopilot-reset) initiated by IT personnel or other administrators from the organization.
- [Remote reset](#reset-devices-with-remote-windows-autopilot-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](https://docs.microsoft.com/intune/users-add).
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](#enable-local-windows-autopilot-reset)
2. [Trigger a reset for each device](#trigger-local-windows-autopilot-reset)
### 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](https://docs.microsoft.com/windows/client-management/mdm/policy-csp-credentialproviders), **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](https://docs.microsoft.com/windows/configuration/provisioning-packages/provisioning-create-package) 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 + ![Windows key](images/windows_glyph.png) + R**.
![Enter CTRL+Windows key+R on the Windows lockscreen](images/autopilot-reset-lockscreen.png)
This will open up a custom login screen for the local Autopilot Reset. The screen serves two purposes:
1. Confirm/verify that the end user has the right to trigger Local Autopilot Reset
2. Notify the user in case a provisioning package, created using Windows Configuration Designer, will be used as part of the process.
![Custom login screen for local Autopilot Reset](images/autopilot-reset-customlogin.png)
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
**Applies to: Windows 10, version 1809 or later**
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](self-deploying.md).
### 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)](https://docs.microsoft.com/windows-hardware/manufacture/desktop/windows-recovery-environment--windows-re--technical-reference) 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](https://docs.microsoft.com/windows-hardware/manufacture/desktop/reagentc-command-line-options) to run the following command:
```
reagentc /enable
```

134
windows/deployment/windows-autopilot/windows-autopilot-scenarios.md
View File

@ -1,67 +1,67 @@
---
title: Windows Autopilot scenarios and capabilities
description: Windows Autopilot deployment
keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune
ms.reviewer: mniehaus
manager: laurawi
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: medium
ms.sitesec: library
ms.pagetype: deploy
author: greg-lindsay
ms.author: greglin
ms.collection: M365-modern-desktop
ms.topic: article
---
# 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 which can vary based on the type of organization and their progress moving to Windows 10 and [transitioning to modern management](https://docs.microsoft.com/windows/client-management/manage-windows-10-in-your-organization-modern-management).
The following Windows Autopilot scenarios are described in this guide:
| Scenario | More information |
| --- | --- |
| Deploy devices that will be set up by a member of the organization and configured for that person | [Windows Autopilot user-driven mode](user-driven.md) |
| Deploy devices that will be automatically configured for shared use, as a kiosk, or as a digital signage device.| [Windows Autopilot self-deploying mode](self-deploying.md) |
| Re-deploy a device in a business-ready state.| [Windows Autopilot Reset](windows-autopilot-reset.md) |
| Pre-provision a device with up-to-date applications, policies and settings.| [White glove](white-glove.md) |
| Deploy Windows 10 on an existing Windows 7 or 8.1 device | [Windows Autopilot for existing devices](existing-devices.md) |
## 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 gets connected to a network and the [critical driver and Windows zero-day patch (ZDP) updates](https://docs.microsoft.com/windows-hardware/customize/desktop/windows-updates-during-oobe) have completed. The user or IT admin cannot opt-out of these Autopilot updates; 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.
### 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.
If desired, you can 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.
| Value | Description |
| --- | --- |
| 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](https://docs.microsoft.com/windows/configuration/wcd/wcd-oobe#nforce).
### 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](bitlocker.md)
## Related topics
[Windows Autopilot: What's new](windows-autopilot-whats-new.md)
---
title: Windows Autopilot scenarios and capabilities
description: Windows Autopilot deployment
keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune
ms.reviewer: mniehaus
manager: laurawi
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: medium
ms.sitesec: library
ms.pagetype: deploy
audience: itpro
author: greg-lindsay
ms.author: greglin
ms.collection: M365-modern-desktop
ms.topic: article
---
# 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 which can vary based on the type of organization and their progress moving to Windows 10 and [transitioning to modern management](https://docs.microsoft.com/windows/client-management/manage-windows-10-in-your-organization-modern-management).
The following Windows Autopilot scenarios are described in this guide:
| Scenario | More information |
| --- | --- |
| Deploy devices that will be set up by a member of the organization and configured for that person | [Windows Autopilot user-driven mode](user-driven.md) |
| Deploy devices that will be automatically configured for shared use, as a kiosk, or as a digital signage device.| [Windows Autopilot self-deploying mode](self-deploying.md) |
| Re-deploy a device in a business-ready state.| [Windows Autopilot Reset](windows-autopilot-reset.md) |
| Pre-provision a device with up-to-date applications, policies and settings.| [White glove](white-glove.md) |
| Deploy Windows 10 on an existing Windows 7 or 8.1 device | [Windows Autopilot for existing devices](existing-devices.md) |
## 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 gets connected to a network and the [critical driver and Windows zero-day patch (ZDP) updates](https://docs.microsoft.com/windows-hardware/customize/desktop/windows-updates-during-oobe) have completed. The user or IT admin cannot opt-out of these Autopilot updates; 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.
### 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.
If desired, you can 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.
| Value | Description |
| --- | --- |
| 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](https://docs.microsoft.com/windows/configuration/wcd/wcd-oobe#nforce).
### 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](bitlocker.md)
## Related topics

103
windows/deployment/windows-autopilot/windows-autopilot-whats-new.md
View File

@ -1,52 +1,51 @@
---
title: Windows Autopilot what's new
ms.reviewer:
manager: laurawi
description: Windows Autopilot deployment
keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: medium
ms.sitesec: library
ms.pagetype: deploy
author: greg-lindsay
audience: itpro
ms.author: greglin
ms.collection: M365-modern-desktop
ms.topic: article
---
# Windows Autopilot: What's new
**Applies to**
- Windows 10
## New in Windows 10, version 1903
[Windows Autopilot for white glove deployment](white-glove.md) is new in Windows 10, version 1903. See the following video:
<br>
> [!VIDEO https://www.youtube.com/embed/nE5XSOBV0rI]
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](windows-autopilot-scenarios.md#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](windows-autopilot-scenarios.md#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.
## New in Windows 10, version 1809
Windows Autopilot [self-deploying mode](self-deploying.md) 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](https://docs.microsoft.com/intune/whats-new)<br>
[What's new in Windows 10](https://docs.microsoft.com/windows/whats-new/)
---
title: Windows Autopilot what's new
ms.reviewer:
manager: laurawi
description: Windows Autopilot deployment
keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: medium
ms.sitesec: library
ms.pagetype: deploy
audience: itpro
author: greg-lindsay
ms.author: greglin
ms.collection: M365-modern-desktop
ms.topic: article
---
# Windows Autopilot: What's new
**Applies to**
- Windows 10
## New in Windows 10, version 1903
[Windows Autopilot for white glove deployment](white-glove.md) is new in Windows 10, version 1903. See the following video:
<br>
> [!VIDEO https://www.youtube.com/embed/nE5XSOBV0rI]
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](windows-autopilot-scenarios.md#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](windows-autopilot-scenarios.md#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.
## New in Windows 10, version 1809
Windows Autopilot [self-deploying mode](self-deploying.md) 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](https://docs.microsoft.com/intune/whats-new)<br>

130
windows/deployment/windows-autopilot/windows-autopilot.md
View File

@ -1,65 +1,65 @@
---
title: Overview of Windows Autopilot
description: Windows Autopilot deployment
keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune
ms.reviewer: mniehaus
manager: laurawi
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: medium
ms.sitesec: library
ms.pagetype: deploy
author: greg-lindsay
ms.author: greglin
ms.collection: M365-modern-desktop
ms.topic: article
---
# 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 is designed to simplify all parts of the lifecycle of Windows devices, for both IT and end users, from initial deployment through the eventual end of life. Leveraging cloud-based services, it can reduce the overall costs for deploying, managing, and retiring devices by reducing the amount of time that IT needs to spend on these processes and the amount of infrastructure that they need to maintain, while ensuring ease of use for all types of end users. See the following diagram:
![Process overview](images/image1.png)
When initially deploying new Windows devices, Windows Autopilot leverages the OEM-optimized version of Windows 10 that is preinstalled on the device, saving organizations the effort of having to maintain custom images and drivers for every model of device being used. Instead of re-imaging the device, your existing Windows 10 installation can be transformed into a “business-ready” state, applying settings and policies, installing apps, and even changing the edition of Windows 10 being used (e.g. from Windows 10 Pro to Windows 10 Enterprise) to support advanced features.
Once deployed, Windows 10 devices can be managed by tools such as Microsoft Intune, Windows Update for Business, System Center Configuration Manager, and other similar tools. Windows Autopilot can also be used to re-purpose a device by leveraging Windows Autopilot Reset to quickly prepare a device for a new user, or in break/fix scenarios to enable a device to quickly be brought 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). See [Introduction to device management in Azure Active Directory](https://docs.microsoft.com/azure/active-directory/device-management-introduction) for more information about the differences between these two join options.
* Auto-enroll devices into MDM services, such as Microsoft Intune ([*Requires an Azure AD Premium subscription*](windows-autopilot-requirements-configuration.md)).
* 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.
## Windows Autopilot walkthrough
The following video shows the process of setting up Windows Autopilot:
</br>
<iframe width="560" height="315" src="https://www.youtube.com/embed/4K4hC5NchbE" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
## Benefits of Windows Autopilot
Traditionally, IT pros spend a lot of 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
Windows 10 version 1703 or higher is required to use Windows Autopilot. See [Windows Autopilot requirements](windows-autopilot-requirements.md) for detailed information on software, configuration, network, and licensing requirements.
## Related topics
[Enroll Windows devices in Intune by using Windows Autopilot](https://docs.microsoft.com/intune/enrollment-autopilot)<br>
[Windows Autopilot scenarios and capabilities](windows-autopilot-scenarios.md)
---
title: Overview of Windows Autopilot
description: Windows Autopilot deployment
keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune
ms.reviewer: mniehaus
manager: laurawi
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: medium
ms.sitesec: library
ms.pagetype: deploy
audience: itpro
author: greg-lindsay
ms.author: greglin
ms.collection: M365-modern-desktop
ms.topic: article
---
# 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 is designed to simplify all parts of the lifecycle of Windows devices, for both IT and end users, from initial deployment through the eventual end of life. Leveraging cloud-based services, it can reduce the overall costs for deploying, managing, and retiring devices by reducing the amount of time that IT needs to spend on these processes and the amount of infrastructure that they need to maintain, while ensuring ease of use for all types of end users. See the following diagram:
![Process overview](images/image1.png)
When initially deploying new Windows devices, Windows Autopilot leverages the OEM-optimized version of Windows 10 that is preinstalled on the device, saving organizations the effort of having to maintain custom images and drivers for every model of device being used. Instead of re-imaging the device, your existing Windows 10 installation can be transformed into a “business-ready” state, applying settings and policies, installing apps, and even changing the edition of Windows 10 being used (e.g. from Windows 10 Pro to Windows 10 Enterprise) to support advanced features.
Once deployed, Windows 10 devices can be managed by tools such as Microsoft Intune, Windows Update for Business, System Center Configuration Manager, and other similar tools. Windows Autopilot can also be used to re-purpose a device by leveraging Windows Autopilot Reset to quickly prepare a device for a new user, or in break/fix scenarios to enable a device to quickly be brought 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). See [Introduction to device management in Azure Active Directory](https://docs.microsoft.com/azure/active-directory/device-management-introduction) for more information about the differences between these two join options.
* Auto-enroll devices into MDM services, such as Microsoft Intune ([*Requires an Azure AD Premium subscription*](windows-autopilot-requirements-configuration.md)).
* 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.
## Windows Autopilot walkthrough
The following video shows the process of setting up Windows Autopilot:
</br>
<iframe width="560" height="315" src="https://www.youtube.com/embed/4K4hC5NchbE" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
## Benefits of Windows Autopilot
Traditionally, IT pros spend a lot of 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
Windows 10 version 1703 or higher is required to use Windows Autopilot. See [Windows Autopilot requirements](windows-autopilot-requirements.md) for detailed information on software, configuration, network, and licensing requirements.
## Related topics
[Enroll Windows devices in Intune by using Windows Autopilot](https://docs.microsoft.com/intune/enrollment-autopilot)<br>