deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-05-12 13:27:23 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Merge pull request #3146 from MicrosoftDocs/minorupdate

Browse Source 
Autopilot content fixes, improvements
This commit is contained in:
Greg Lindsay 2020-06-23 09:31:07 -07:00 committed by GitHub
commit 49d6f4fb03
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
9 changed files with 483 additions and 476 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -1,420 +1,421 @@
---
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
[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 an 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 an MBR, such as:
- Verify that the device is still functional
- Disable BitLocker*
- Repair the Boot Configuration Data (BCD)
- Repair and verify the network driver operation
*BitLocker can be suspended rather than disabled if the technician 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 was 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 sign in, 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 back up 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 you have access to customers’ login credentials
4. Write device info into BIOS
5. Capture new 4K HH
6. Reregister repaired device
7. Reset device back to OOBE
8. Go through Autopilot OOBE (customer)
9. Autopilot successfully enabled
<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 you 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 you 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 you 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 Autopilot devices without a TPM chip (which is recommended for BitLocker encryption), it is possible to enable an Autopilot device 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 you 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 you 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 motherboard 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>Non-Microsoft 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>

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

@ -23,9 +23,9 @@ ms.topic: article
- 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.
With Windows Autopilot, you can configure the BitLocker encryption settings to be applied before automatic encryption is started. This ensures that the default encryption algorithm isn't 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.
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:
@ -39,11 +39,11 @@ 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 encryption algorithm.
**Note**: A device that is encrypted automatically will need to be decrypted prior to changing the encryption algorithm.
The settings are available under Device Configuration -> Profiles -> Create profile -> Platform = Windows 10 and later, Profile type = Endpoint protection -> Configure -> Windows Encryption -> BitLocker base settings, Configure encryption methods = Enable.
Note: It is also recommended to set Windows Encryption -> Windows Settings -> Encrypt = **Require**.
**Note**: It is also recommended to set Windows Encryption -> Windows Settings -> Encrypt = **Require**.
## Requirements
@ -51,4 +51,4 @@ Windows 10, version 1809 or later.
## See also
[Bitlocker overview](https://docs.microsoft.com/windows/security/information-protection/bitlocker/bitlocker-overview)
[BitLocker overview](https://docs.microsoft.com/windows/security/information-protection/bitlocker/bitlocker-overview)

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

@ -28,7 +28,7 @@ To get started with Windows Autopilot, you should try it out with a virtual mach
In this topic you'll learn how to set-up a Windows Autopilot deployment for a VM using Hyper-V.
> [!NOTE]
> Although there are [multiple platforms](administer.md) available to enable Autopilot, this lab primarily uses Intune.
> Although there are [multiple platforms](add-devices.md#registering-devices) available to enable Autopilot, this lab primarily uses Intune.
> Hyper-V and a VM are not required for this lab. You can also use a physical device. However, the instructions assume that you are using a VM. To use a physical device, skip the instructions to install Hyper-V and create a VM. All references to 'device' in the guide refer to the client device, either physical or virtual.
@ -43,7 +43,7 @@ The following video provides an overview of the process:
These are the things you'll need to complete this lab:
<table><tr><td>Windows 10 installation media</td><td>Windows 10 Professional or Enterprise (ISO file) for a supported version of Windows 10, semi-annual channel. If you do not already have an ISO to use, a link is provided to download an <a href="https://www.microsoft.com/evalcenter/evaluate-windows-10-enterprise" data-raw-source="[evaluation version of Windows 10 Enterprise](https://www.microsoft.com/evalcenter/evaluate-windows-10-enterprise)">evaluation version of Windows 10 Enterprise</a>.</td></tr>
<tr><td>Internet access</td><td>If you are behind a firewall, see the detailed <a href="windows-autopilot-requirements-network.md" data-raw-source="[networking requirements](windows-autopilot-requirements-network.md)">networking requirements</a>. Otherwise, just ensure that you have a connection to the Internet.</td></tr>
<tr><td>Internet access</td><td>If you are behind a firewall, see the detailed <a href="windows-autopilot-requirements.md#networking-requirements" data-raw-source="[networking requirements](windows-autopilot-requirements.md#networking-requirements)">networking requirements</a>. Otherwise, just ensure that you have a connection to the Internet.</td></tr>
<tr><td>Hyper-V or a physical device running Windows 10</td><td>The guide assumes that you will use a Hyper-V VM, and provides instructions to install and configure Hyper-V if needed. To use a physical device, skip the steps to install and configure Hyper-V.</td></tr>
<tr><td>A Premium Intune account</td><td>This guide will describe how to obtain a free 30-day trial premium account that can be used to complete the lab.</td></tr></table>
@ -110,9 +110,9 @@ When you are prompted to restart the computer, choose **Yes**. The computer migh
> Alternatively, you can install Hyper-V using the Control Panel in Windows under **Turn Windows features on or off** for a client operating system, or using Server Manager's **Add Roles and Features Wizard** on a server operating system, as shown below:
![hyper-v feature](../images/hyper-v-feature.png)
![Hyper-V feature](images/hyper-v-feature.png)
![hyper-v](../images/svr_mgr2.png)
![Hyper-V](images/svr_mgr2.png)
<P>If you choose to install Hyper-V using Server Manager, accept all default selections. Also be sure to install both items under <strong>Role Administration Tools\Hyper-V Management Tools</strong>.
@ -401,7 +401,7 @@ Optional: see the following video for an overview of the process.
First, you need a MSfB account. You can use the same one you created above for Intune, or follow [these instructions](https://docs.microsoft.com/microsoft-store/windows-store-for-business-overview) to create a new one.
Next, sign in to [Microsoft Store for Business](https://businessstore.microsoft.com/en-us/store) using your test account by clicking **Sign in** in the upper-right-corner of the main page.
Next, sign in to [Microsoft Store for Business](https://businessstore.microsoft.com/en-us/store) using your test account by clicking **Sign in** on the upper-right-corner of the main page.
Select **Manage** from the top menu, then click the **Windows Autopilot Deployment Program** link under the **Devices** card. See the following example:
@ -469,7 +469,7 @@ Click on **OK** and then click on **Create**.
Profiles can only be assigned to Groups, so first you must create a group that contains the devices to which the profile should be applied. This guide will provide simple instructions to assign a profile, for more detailed instructions, 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), as optional reading.
To create a Group, open the Azure Portal and select **Azure Active Directory** > **Groups** > **All groups**:
To create a Group, open the Azure portal and select **Azure Active Directory** > **Groups** > **All groups**:
![All groups](images/all-groups.png)

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

@ -59,7 +59,7 @@ See the following examples.
>[!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/download/details.aspx?id=54616).
1. On an Internet connected Windows PC or Server open an elevated Windows PowerShell command window
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
@ -118,7 +118,7 @@ See the following examples.
|------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 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. |
| CloudAssignedTenantDomain (string, required) | The Azure Active Directory tenant name that should be used, for example: tenant.onmicrosoft.com. |
| CloudAssignedOobeConfig (number, required) | This is a bitmap that shows which Autopilot settings were configured. Values include: SkipCortanaOptIn = 1, OobeUserNotLocalAdmin = 2, SkipExpressSettings = 4, SkipOemRegistration = 8, SkipEula = 16 |
| CloudAssignedDomainJoinMethod (number, required) | This property specifies whether the device should join Azure Active Directory or Active Directory (Hybrid Azure AD Join). Values include: Active AD Join = 0, Hybrid Azure AD Join = 1 |
| CloudAssignedForcedEnrollment (number, required) | Specifies that the device should require AAD Join and MDM enrollment. <br>0 = not required, 1 = required. |
@ -175,7 +175,7 @@ See the following examples.
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.
- 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)
@ -198,7 +198,7 @@ See the following examples.
- <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.
- 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 licensing 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.
@ -210,7 +210,7 @@ See the following examples.
>[!IMPORTANT]
> The System Preparation Tool (sysprep) will run with the /Generalize parameter which, on Windows 10 versions 1903 and 1909, will delete the Autopilot profile file and the machine will boot into OOBE phase instead of Autopilot phase. To fix this issue, please see [Windows Autopilot - known issues](https://docs.microsoft.com/windows/deployment/windows-autopilot/known-issues).
5. Click **Next** and then click **Next** again to accept the default settings on the Install Configuration Manager page.
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.
@ -222,7 +222,7 @@ See the following examples.
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**.
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**.
@ -245,7 +245,7 @@ See the following examples.
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**
- <u>Shut down the computer after running this action</u>: **Optional**
![Autopilot task sequence](images/ap-ts-1.png)
@ -259,9 +259,9 @@ See the following examples.
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**.
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.
4. On the Add Distribution Points or Add Distribution Point Groups wizard specify content destinations that will allow the JSON file to be retrieved when the task sequence is run.
5. When you are finished specifying content distribution, click **Next** twice then click **Close**.
### Deploy the OS with Autopilot Task Sequence

BIN
windows/deployment/windows-autopilot/images/hyper-v-feature.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 26 KiB

BIN
windows/deployment/windows-autopilot/images/svr_mgr2.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 61 KiB

4
windows/deployment/windows-autopilot/policy-conflicts.md
View File

@ -29,11 +29,11 @@ There are a significant number of policy settings available for Windows 10, both
<th>Policy<th>More information
<tr><td width="50%">Device restriction / <a href="https://docs.microsoft.com/windows/client-management/mdm/devicelock-csp">Password Policy</a></td>
<td>When certain <a href="https://docs.microsoft.com/windows/client-management/mdm/policy-csp-devicelock">DeviceLock policies</a>, such as minimum password length and password complexity, or any similar group policy settings, including any that disable auto-logon, are applied to a device, and that device reboots during the device Enrollment Status Page (ESP), the out-of-box experience or user desktop auto-logon could fail unexpectantly. This is especially true for kiosk scenarios where passwords are automatically generated.</td>
<td>When certain <a href="https://docs.microsoft.com/windows/client-management/mdm/policy-csp-devicelock">DeviceLock policies</a>, such as minimum password length and password complexity, or any similar group policy settings (including any that disable autologon) are applied to a device, and that device reboots during the device Enrollment Status Page (ESP), the out-of-box experience (OOBE) or user desktop autologon can fail unexpectantly. This is especially true for kiosk scenarios where passwords are automatically generated.</td>
<tr><td width="50%">Windows 10 Security Baseline / <a href="https://docs.microsoft.com/windows/client-management/mdm/policy-csp-localpoliciessecurityoptions">Administrator elevation prompt behavior</a>
<br>Windows 10 Security Baseline / <a href="https://docs.microsoft.com/windows/client-management/mdm/policy-csp-localpoliciessecurityoptions">Require admin approval mode for administrators</a></td>
<td>When modifying user account control (UAC) settings during the out-of-box experience (OOBE) using device Enrollment Status Page (ESP), additional UAC prompts may result, especially if the device reboots after these policies are applied enabling them to take effect. To work around this issue, the policies can be targeted to users instead of devices so that they apply later in the process.</td>
<td>When modifying user account control (UAC) settings during the OOBE using the device Enrollment Status Page (ESP), additional UAC prompts may result, especially if the device reboots after these policies are applied, enabling them to take effect. To work around this issue, the policies can be targeted to users instead of devices so that they apply later in the process.</td>
</table>

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

@ -25,34 +25,34 @@ Windows Autopilot is designed to simplify all parts of the Windows device lifecy
## 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:
Whether you are performing user-driven or self-deploying device deployments, the troubleshooting process is about the same. It is always 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).
- A network connection is established. This can be a wireless (Wi-fi) or wired (Ethernet) connection.
- The Windows Autopilot profile is 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 occurs. When performing a user-driven deployment, the user will enter their Azure Active Directory credentials, which will be validated.
- Azure Active Directory join occurs. For user-driven deployments, the device will be joined to Azure AD using the specified user credentials. For self-deploying scenarios, the device will be joined without specifying any user credentials.
- Automatic MDM enrollment occurs. As part of the Azure AD join process, the device will enroll in the MDM service configured in Azure AD (for example, Microsoft Intune).
- 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)?
- 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 Device Import
### Clicking Import after selecting CSV does nothing, '400' error appears in network trace with error body **"Cannot convert the literal '[DEVICEHASH]' to the expected type 'Edm.Binary'"**
This error points to the device hash being incorrectly formatted. This could be caused by anything that corrupts the collected hash, but one possibility is that the hash itself, even if completely valid, fails to be decoded.
This error points to the device hash being incorrectly formatted. This could be caused by anything that corrupts the collected hash, but one possibility is that the hash itself (even if it is completely valid) fails to be decoded.
The device hash is Base64. At the device level, it's encoded as unpadded Base64, but Autopilot expects padded Base64. In most cases, it seems the payload lines up to not require padding, so the process works, but sometimes it doesn't line up cleanly and padding is necessary. This is when you get the error above. Powershell's Base64 decoder also expects padded Base64, so we can use that to validate that the hash is properly padded.
The device hash is Base64. At the device level, it's encoded as unpadded Base64, but Autopilot expects padded Base64. In most cases, it seems the payload lines up to not require padding, so the process works, but sometimes it doesn't line up cleanly and padding is necessary. This is when you get the error above. PowerShell's Base64 decoder also expects padded Base64, so we can use that to validate that the hash is properly padded.
The "A" characters at the end of the hash are effectively empty data - Each character in Base64 is 6 bits, A in Base64 is 6 bits equal to 0. Deleting or adding "A"s at the end doesn't change the actual payload data.
The "A" characters at the end of the hash are effectively empty data - Each character in Base64 is 6 bits, A in Base64 is 6 bits equal to 0. Deleting or adding **A**'s at the end doesn't change the actual payload data.
To fix this, we'll need to modify the hash, then test the new value, until powershell succeeds in decoding the hash. The result is mostly illegible, this is fine - we're just looking for it to not throw the error "Invalid length for a Base-64 char array or string".
To fix this, we'll need to modify the hash, then test the new value, until PowerShell succeeds in decoding the hash. The result is mostly illegible, this is fine - we're just looking for it to not throw the error "Invalid length for a Base-64 char array or string".
To test the base64, you can use the following:
```powershell
@ -88,35 +88,35 @@ If the expected Autopilot behavior does not occur during the out-of-box experien
### 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** for versions before 1903, or **Application and Services Logs –> Microsoft –> Windows –> ModernDeployment-Diagnostics-Provider –> AutoPilot** for 1903 and above. The following events may be recorded, depending on the scenario and profile configuration.
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** for versions before 1903, or **Application and Services Logs –> Microsoft –> Windows –> ModernDeployment-Diagnostics-Provider –> Autopilot** for 1903 and above. 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. |
| 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:
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. |
| CloudAssignedTenantDomain | The Azure AD tenant the device has been registered with, for example, “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. |
| 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 |
@ -128,7 +128,7 @@ On devices running a [supported version](https://docs.microsoft.com/windows/rele
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.
An Azure AD device is created upon import - it's important that this object not be deleted. It acts as Autopilot's anchor in AAD for group membership and targeting (including the profile) and can lead to join errors if it's deleted. Once this object has been deleted, to fix the issue, deleting and reimporting this autopilot hash will be necessary so it can recreate the associated object.
An Azure AD device is created upon import - it's important that this object is not deleted. It acts as Autopilot's anchor in AAD for group membership and targeting (including the profile) and can lead to join errors if it's deleted. Once this object has been deleted, to fix the issue, deleting and reimporting this autopilot hash will be necessary so it can recreate the associated object.
Error code 801C0003 will typically be reported on an error page titled "Something went wrong". This error means that the Azure AD join failed.
@ -138,13 +138,13 @@ See [this knowledge base article](https://support.microsoft.com/help/4089533/tro
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.
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.
When a profile is downloaded depends upon the version of Windows 10 that is running on the PC. See the following table.
| Windows 10 version | Profile download behavior |
| --- | --- |

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

@ -29,6 +29,12 @@ The following [Windows Autopilot updates](autopilot-update.md) are available. **
No updates are available yet. Check back here later for more information.
## New in Windows 10, version 2004
With this release, you can configure Windows Autopilot [user-driven](user-driven.md) Hybrid Azure Active Directory join with VPN support. This support is also backported to Windows 10, version 1909 and 1903.
If you configure the language settings in the Autopilot profile and the device is connected to Ethernet, all scenarios will now skip the language, locale, and keyboard pages. In previous versions, this was only supported with self-deploying profiles.
## 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: