# Windows Autopilot motherboard replacement scenario guidance
**Applies to**
- Windows10
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
**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
>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>
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.
<br>
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:
## 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.
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
<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>
<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
---
title: Windows Autopilot motherboard replacement
ms.reviewer:
manager: laurawi
description: Find guidance for Windows Autopilot device repairs that Microsoft partners can use for servicing scenarios like Motherboard Replacement (MBR).
# Windows Autopilot motherboard replacement scenario guidance
**Applies to**
- Windows10
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
**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
>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>
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.
<br>
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:
## 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.
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
<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>
<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. |
| OEM or Channel Partner registering devices as a CSP (via MPC) | Use the help resources available in MPC. Whether you are a named partner or a channel partner (distributor, reseller, SI, etc.), if you’re a CSP registering Autopilot devices through MPC (either manually or through the MPC API), your first-line of support should be the help resources within MPC. |
| OEM or Channel Partner registering devices as a CSP (via MPC) | Use the help resources available in MPC. Whether you are a named partner or a channel partner (distributor, reseller, SI, etc.), if you're a CSP registering Autopilot devices through MPC (either manually or through the MPC API), your first-line of support should be the help resources within MPC. |
| OEM registering devices using OEM Direct API | Contact MSOEMOPS@microsoft.com. Response time depends on priority: <br>Low – 120 hours <br>Normal – 72 hours <br>High – 24 hours <br>Immediate – 4 hours |
| Partners with a Partner Technology Strategist (PTS) | If you have a PTS (whether you’re a CSP or not), you may first try working through your account’s specific Partner Technology Strategist (PTS). |
| Partners with an Ecosystem PM | If you have an Ecosystem PM (whether you’re a CSP or not), you may first try working through your account’s specific Ecosystem PM, especially for technical issues. To learn more about Ecosystem PMs and the services they offer, contact epsoinfo@microsoft.com. |
| Partners with a Partner Technology Strategist (PTS) | If you have a PTS (whether you're a CSP or not), you may first try working through your account's specific Partner Technology Strategist (PTS). |
| Partners with an Ecosystem PM | If you have an Ecosystem PM (whether you're a CSP or not), you may first try working through your account's specific Ecosystem PM, especially for technical issues. To learn more about Ecosystem PMs and the services they offer, contact epsoinfo@microsoft.com. |
| Enterprise customers | Contact your Technical Account Manager (TAM), or Account Technology Strategist (ATS), or Customer Service Support (CSS) representative. |
| End-user | Contact your IT administrator. |
| Microsoft Partner Center (MPC) users | Use the [help resources](https://partner.microsoft.com/support) available in MPC. |
@ -225,7 +227,7 @@ Ensure the VM booted from the installation ISO, click **Next** then click **Inst
After the VM restarts, during OOBE, it’s fine to select **Set up for personal use** or **Domain join instead** and then choose an offline account on the **Sign in** screen. This will offer the fastest way to the desktop. For example:
After the VM restarts, during OOBE, it's fine to select **Set up for personal use** or **Domain join instead** and then choose an offline account on the **Sign in** screen. This will offer the fastest way to the desktop. For example:
@ -244,7 +246,7 @@ Click on the **WindowsAutopilot** VM in Hyper-V Manager and verify that you see
## Capture the hardware ID
> [!NOTE]
> Normally, the Device ID is captured by the OEM as they run the OA3 Tool on each device in the factory. The OEM then submits the 4K HH created by the OA3 Tool to Microsoft by submitting it with a Computer Build Report (CBR). For purposes of this lab, you are acting as the OEM (capturing the 4K HH), but you’re not going to use the OA3 Tool to capture the full 4K HH for various reasons (you’d have to install the OA3 tool, your device couldn’t have a volume license version of Windows, it’s a more complicated process than using a PS script, etc.). Instead, you’ll simulate running the OA3 tool by running a PowerShell script, which captures the device 4K HH just like the OA3 tool.
> Normally, the Device ID is captured by the OEM as they run the OA3 Tool on each device in the factory. The OEM then submits the 4K HH created by the OA3 Tool to Microsoft by submitting it with a Computer Build Report (CBR). For purposes of this lab, you are acting as the OEM (capturing the 4K HH), but you're not going to use the OA3 Tool to capture the full 4K HH for various reasons (you'd have to install the OA3 tool, your device couldn't have a volume license version of Windows, it's a more complicated process than using a PS script, etc.). Instead, you'll simulate running the OA3 tool by running a PowerShell script, which captures the device 4K HH just like the OA3 tool.
Follow these steps to run the PS script:
@ -303,7 +305,7 @@ Verify that there is an **AutopilotHWID.csv** file in the **c:\HWID** directory
You will need to upload this data into Intune to register your device for Autopilot, so it needs to be transferred to the computer you will use to access the Azure portal. If you are using a physical device instead of a VM, you can copy the file to a USB stick. If you’re using a VM, you can right-click the AutopilotHWID.csv file and copy it, then right-click and paste the file to your desktop (outside the VM).
You will need to upload this data into Intune to register your device for Autopilot, so it needs to be transferred to the computer you will use to access the Azure portal. If you are using a physical device instead of a VM, you can copy the file to a USB stick. If you're using a VM, you can right-click the AutopilotHWID.csv file and copy it, then right-click and paste the file to your desktop (outside the VM).
If you have trouble copying and pasting the file, just view the contents in Notepad on the VM and copy the text into Notepad outside the VM. Do not use another text editor to do this.
@ -331,7 +333,7 @@ For this lab, you need an AAD Premium subscription. You can tell if you have a
If the configuration blade shown above does not appear, it’s likely that you don’t have a **Premium** subscription. Auto-enrollment is a feature only available in AAD Premium.
If the configuration blade shown above does not appear, it's likely that you don't have a **Premium** subscription. Auto-enrollment is a feature only available in AAD Premium.
To convert your Intune trial account to a free Premium trial account, navigate to **Azure Active Directory** > **Licenses** > **All products** > **Try / Buy** and select **Free trial** for Azure AD Premium, or EMS E5.
@ -376,7 +378,7 @@ Your VM (or device) can be registered either via Intune or Microsoft Store for B
> [!NOTE]
> If menu items like **Windows enrollment** are not active for you, then look to the far-right blade in the UI. You might need to provide Intune configuration privileges in a challenge window that appeared.
2. Under **Add Windows Autopilot devices** in the far right pane, browse to the **AutopilotHWID.csv** file you previously copied to your local computer. The file should contain the serial number and 4K HH of your VM (or device). It’s okay if other fields (Windows Product ID) are left blank.
2. Under **Add Windows Autopilot devices** in the far right pane, browse to the **AutopilotHWID.csv** file you previously copied to your local computer. The file should contain the serial number and 4K HH of your VM (or device). It's okay if other fields (Windows Product ID) are left blank.
@ -473,7 +475,7 @@ To create a Group, open the Azure Portal and select **Azure Active Directory** >
Select New group from the Groups blade to open the new groups UI. Select the “Security” group type, name the group, and select the “Assigned” membership type:
Select New group from the Groups blade to open the new groups UI. Select the "Security" group type, name the group, and select the "Assigned" membership type:
Before clicking **Create**, expand the **Members** panel, click your device's serial number (it will then appear under **Selected members**) and then click **Select** to add that device to this group.
@ -497,7 +499,7 @@ Click **Select** and then click **Save**.
It’s also possible to assign specific users to a profile, but we will not cover this scenario in the lab. For more detailed information, see [Enroll Windows devices in Intune by using Windows Autopilot](https://docs.microsoft.com/intune/enrollment-autopilot).
It's also possible to assign specific users to a profile, but we will not cover this scenario in the lab. For more detailed information, see [Enroll Windows devices in Intune by using Windows Autopilot](https://docs.microsoft.com/intune/enrollment-autopilot).
### Create a Windows Autopilot deployment profile using MSfB
@ -544,14 +546,14 @@ Confirm the profile was successfully assigned to the intended device by checking
## See Windows Autopilot in action
If you shut down your VM after the last reset, it’s time to start it back up again, so it can progress through the Autopilot OOBE experience but do not attempt to start your device again until the **PROFILE STATUS** for your device in Intune has changed from **Not assigned** to **Assigning** and finally **Assigned**:
If you shut down your VM after the last reset, it's time to start it back up again, so it can progress through the Autopilot OOBE experience but do not attempt to start your device again until the **PROFILE STATUS** for your device in Intune has changed from **Not assigned** to **Assigning** and finally **Assigned**:
Also, make sure to wait at least 30 minutes from the time you've [configured company branding](#configure-company-branding), otherwise these changes might not show up.
> [!TIP]
> If you reset your device previously after collecting the 4K HH info, and then let it restart back to the first OOBE screen, then you might need to restart the device again to ensure the device is recognized as an Autopilot device and displays the Autopilot OOBE experience you’re expecting. If you do not see the Autopilot OOBE experience, then reset the device again (Settings > Update & Security > Recovery and click on Get started. Under Reset this PC, select Remove everything and Just remove my files. Click on Reset).
> If you reset your device previously after collecting the 4K HH info, and then let it restart back to the first OOBE screen, then you might need to restart the device again to ensure the device is recognized as an Autopilot device and displays the Autopilot OOBE experience you're expecting. If you do not see the Autopilot OOBE experience, then reset the device again (Settings > Update & Security > Recovery and click on Get started. Under Reset this PC, select Remove everything and Just remove my files. Click on Reset).
- Ensure your device has an internet connection.
- Turn on the device
@ -610,7 +612,7 @@ If you also (optionally) want to remove your device from AAD, navigate to **Azur
## Appendix A: Verify support for Hyper-V
Starting with Windows 8, the host computer’s microprocessor must support second level address translation (SLAT) to install Hyper-V. See [Hyper-V: List of SLAT-Capable CPUs for Hosts](https://social.technet.microsoft.com/wiki/contents/articles/1401.hyper-v-list-of-slat-capable-cpus-for-hosts.aspx) for more information.
Starting with Windows 8, the host computer's microprocessor must support second level address translation (SLAT) to install Hyper-V. See [Hyper-V: List of SLAT-Capable CPUs for Hosts](https://social.technet.microsoft.com/wiki/contents/articles/1401.hyper-v-list-of-slat-capable-cpus-for-hosts.aspx) for more information.
To verify your computer supports SLAT, open an administrator command prompt, type **systeminfo**, press ENTER, scroll down, and review the section displayed at the bottom of the output, next to Hyper-V Requirements. See the following example:
Before we can pull an application into Intune to make it part of our AP profile, we need to “package” the application for delivery using the [IntuneWinAppUtil.exe command-line tool](https://github.com/Microsoft/Microsoft-Win32-Content-Prep-Tool). After downloading the tool, gather the following three bits of information to use the tool:
Before we can pull an application into Intune to make it part of our AP profile, we need to "package" the application for delivery using the [IntuneWinAppUtil.exe command-line tool](https://github.com/Microsoft/Microsoft-Win32-Content-Prep-Tool). After downloading the tool, gather the following three bits of information to use the tool:
1. The source folder for your application
2. The name of the setup executable file
3. The output folder for the new file
For the purposes of this lab, we’ll use the Notepad++ tool as our Win32 app.
For the purposes of this lab, we'll use the Notepad++ tool as our Win32 app.
Download the Notepad++ msi package [here](https://www.hass.de/content/notepad-msi-package-enterprise-deployment-available) and then copy the file to a known location, such as C:\Notepad++msi.
Simply using an install command like “notepad++.exe /S” will not actually install Notepad++; it will only launch the app. To actually install the program, we need to use the .msi file instead. Notepad++ doesn’t actually have an .msi version of their program, but we got an .msi version from a [third party provider](https://www.hass.de/content/notepad-msi-package-enterprise-deployment-available).
Simply using an install command like "notepad++.exe /S" will not actually install Notepad++; it will only launch the app. To actually install the program, we need to use the .msi file instead. Notepad++ doesn't actually have an .msi version of their program, but we got an .msi version from a [third party provider](https://www.hass.de/content/notepad-msi-package-enterprise-deployment-available).
Click **OK** to save your input and activate the **Requirements** blade.
<tr><td>TPM attestation fails on Windows 10 1903 due to missing AKI extension in EK certificate. (An additional validation added in Windows 10 1903 to check that the TPM EK certs had the proper attributes according to the TCG specifications uncovered that a number of them don’t, so that validation will be removed).
<tr><td>TPM attestation fails on Windows 10 1903 due to missing AKI extension in EK certificate. (An additional validation added in Windows 10 1903 to check that the TPM EK certs had the proper attributes according to the TCG specifications uncovered that a number of them don't, so that validation will be removed).
<td>Download and install the <ahref="https://support.microsoft.com/help/4517211/windows-10-update-kb4517211">KB4517211 update</a>.
<tr><td>The following known issues are resolved by installing the August 30, 2019 KB4512941 update (OS Build 18362.329):
- Windows Autopilot for existing devices feature does not properly suppress “Activities” page during OOBE. (Because of this, you’ll see that extra page during OOBE).
- TPM attestation state is not cleared by sysprep /generalize, causing TPM attestation failure during later OOBE flow. (This isn’t a particularly common issue, but you could run into it while testing if you are running sysprep /generalize and then rebooting or reimaging the device to go back through an Autopilot white glove or self-deploying scenario).
- Windows Autopilot for existing devices feature does not properly suppress "Activities" page during OOBE. (Because of this, you'll see that extra page during OOBE).
- TPM attestation state is not cleared by sysprep /generalize, causing TPM attestation failure during later OOBE flow. (This isn't a particularly common issue, but you could run into it while testing if you are running sysprep /generalize and then rebooting or reimaging the device to go back through an Autopilot white glove or self-deploying scenario).
- TPM attestation may fail if the device has a valid AIK cert but no EK cert. (This is related to the previous item).
- If TPM attestation fails during the Windows Autopilot white glove process, the landing page appears to be hung. (Basically, the white glove landing page, where you click “Provision” to start the white glove process, isn’t reporting errors properly).
- If TPM attestation fails during the Windows Autopilot white glove process, the landing page appears to be hung. (Basically, the white glove landing page, where you click "Provision" to start the white glove process, isn't reporting errors properly).
- TPM attestation fails on newer Infineon TPMs (firmware version > 7.69). (Prior to this fix, only a specific list of firmware versions was accepted).
- Device naming templates may truncate the computer name at 14 characters instead of 15.
- Assigned Access policies cause a reboot which can interfere with the configuration of single-app kiosk devices.
@ -58,8 +59,8 @@ This happens because Windows 10, version 1903 and 1909 deletes the AutopilotConf
- Windows Autopilot white glove does not work for a non-English OS and you see a red screen that says "Success."
- Windows Autopilot reports an AUTOPILOTUPDATE error during OOBE after sysprep, reset or other variations. This typically happens if you reset the OS or used a custom sysprepped image.
- BitLocker encryption is not correctly configured. Ex: BitLocker didn’t get an expected notification after policies were applied to begin encryption.
- You are unable to install UWP apps from the Microsoft Store, causing failures during Windows Autopilot. If you are deploying Company Portal as a blocking app during Windows Autopilot ESP, you’ve probably seen this error.
- BitLocker encryption is not correctly configured. Ex: BitLocker didn't get an expected notification after policies were applied to begin encryption.
- You are unable to install UWP apps from the Microsoft Store, causing failures during Windows Autopilot. If you are deploying Company Portal as a blocking app during Windows Autopilot ESP, you've probably seen this error.
- A user is not granted administrator rights in the Windows Autopilot user-driven Hybrid Azure AD join scenario. This is another non-English OS issue.
<td>Download and install the <ahref="https://support.microsoft.com/help/4505903">KB4505903 update</a>. <br><br>See the section: <b>How to get this update</b> for information on specific release channels you can use to obtain the update.
<tr><td>Windows Autopilot <ahref="https://docs.microsoft.com/windows/deployment/windows-autopilot/self-deploying">self-deploying mode</a> fails with an error code:
@ -68,7 +69,7 @@ This happens because Windows 10, version 1903 and 1909 deletes the AutopilotConf
<tr><td>0x801c03ea<td>This error indicates that TPM attestation failed, causing a failure to join Azure Active Directory with a device token.
<tr><td>0xc1036501<td>The device cannot do an automatic MDM enrollment because there are multiple MDM configurations in Azure AD. See <ahref="https://oofhours.com/2019/10/01/inside-windows-autopilot-self-deploying-mode/">Inside Windows Autopilot self-deploying mode</a>.
</table>
<tr><td>White glove gives a red screen and the <b>Microsoft-Windows-User Device Registration/Admin</b> event log displays <b>HResult error code 0x801C03F3</b><td>This can happen if Azure AD can’t find an AAD device object for the device that you are trying to deploy. This will occur if you manually delete the object. To fix it, remove the device from AAD, Intune, and Autopilot, then re-register it with Autopilot, which will recreate the AAD device object.<br>
<tr><td>White glove gives a red screen and the <b>Microsoft-Windows-User Device Registration/Admin</b> event log displays <b>HResult error code 0x801C03F3</b><td>This can happen if Azure AD can't find an AAD device object for the device that you are trying to deploy. This will occur if you manually delete the object. To fix it, remove the device from AAD, Intune, and Autopilot, then re-register it with Autopilot, which will recreate the AAD device object.<br>
<tr><td>White glove gives a red screen<td>White glove is not supported on a VM.
<tr><td>Error importing Windows Autopilot devices from a .csv file<td>Ensure that you have not edited the .csv file in Microsoft Excel or an editor other than Notepad. Some of these editors can introduce extra characters causing the file format to be invalid.
@ -33,7 +34,7 @@ The following profile settings are available:
-**Automatically setup for work or school**. All devices registered with Autopilot will automatically be considered work or school devices, so this question will not be asked during the OOBE process.
-**Sign in experience with company branding**. Instead of presenting a generic Azure Active Directory sign-in page, all devices registered with Autopilot will automatically present a customized sign-in page with the organization’s name, logon, and additional help text, as configured in Azure Active Directory. See [Add company branding to your directory](https://docs.microsoft.com/azure/active-directory/customize-branding#add-company-branding-to-your-directory) to customize these settings.
-**Sign in experience with company branding**. Instead of presenting a generic Azure Active Directory sign-in page, all devices registered with Autopilot will automatically present a customized sign-in page with the organization's name, logon, and additional help text, as configured in Azure Active Directory. See [Add company branding to your directory](https://docs.microsoft.com/azure/active-directory/customize-branding#add-company-branding-to-your-directory) to customize these settings.
-**Skip privacy settings**. This optional Autopilot profile setting enables organizations to not ask about privacy settings during the OOBE process. This is typically desirable so that the organization can configure these settings via Intune or other management tool.
@ -92,18 +93,18 @@ To see details related to the Autopilot profile settings and OOBE flow, Windows
| 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.
@ -114,8 +115,8 @@ On Windows 10 version 1709 and above, information about the Autopilot profile se
| Value | Description |
|-------|-------------|
| AadTenantId | The GUID of the Azure AD tenant the user signed into. This should match the tenant that the device was registered with; if it does not match the user will receive an error. |
| CloudAssignedTenantDomain | The Azure AD tenant the device has been registered with, e.g. “contosomn.onmicrosoft.com.” If the device is not registered with Autopilot, this value will be blank. |
| CloudAssignedTenantId | The GUID of the Azure AD tenant the device has been registered with (the GUID corresponds to the tenant domain from the CloudAssignedTenantDomain registry value). If the device isn’t registered with Autopilot, this value will be blank.|
| CloudAssignedTenantDomain | The Azure AD tenant the device has been registered with, e.g. "contosomn.onmicrosoft.com." If the device is not registered with Autopilot, this value will be blank. |
| CloudAssignedTenantId | The GUID of the Azure AD tenant the device has been registered with (the GUID corresponds to the tenant domain from the CloudAssignedTenantDomain registry value). If the device isn't registered with Autopilot, this value will be blank.|
| IsAutoPilotDisabled | If set to 1, this indicates that the device is not registered with Autopilot. This could also indicate that the Autopilot profile could not be downloaded due to network connectivity or firewall issues, or network timeouts. |
| TenantMatched | This will be set to 1 if the tenant ID of the user matches the tenant ID that the device was registered with. If this is 0, the user would be shown an error and forced to start over. |
| CloudAssignedOobeConfig | This is a bitmap that shows which Autopilot settings were configured. Values include: SkipCortanaOptIn = 1, OobeUserNotLocalAdmin = 2, SkipExpressSettings = 4, SkipOemRegistration = 8, SkipEula = 16 |
@ -24,7 +25,7 @@ Windows Autopilot enables organizations to easily provision new devices - levera
Windows Autopilot can also provide a <I>white glove</I> service that enables partners or IT staff to pre-provision a Windows 10 PC so that it is fully configured and business-ready. From the end user’s perspective, the Windows Autopilot user-driven experience is unchanged, but getting their device to a fully provisioned state is faster.
Windows Autopilot can also provide a <I>white glove</I> service that enables partners or IT staff to pre-provision a Windows 10 PC so that it is fully configured and business-ready. From the end user's perspective, the Windows Autopilot user-driven experience is unchanged, but getting their device to a fully provisioned state is faster.
With **Windows Autopilot for white glove deployment**, the provisioning process is split. The time-consuming portions are performed by IT, partners, or OEMs. The end user simply completes a few necessary settings and polices and then they can begin using their device.
@ -42,7 +43,7 @@ In addition to [Windows Autopilot requirements](windows-autopilot-requirements.m
- Physical devices with Ethernet connectivity; Wi-fi connectivity is not supported due to the requirement to choose a language, locale, and keyboard to make that Wi-fi connection; doing that in a pre-provisioning process could prevent the user from choosing their own language, locale, and keyboard when they receive the device.
>[!IMPORTANT]
>Because the OEM or vendor performs the white glove process, this <u>doesn’t require access to an end-user's on-prem domain infrastructure</u>. This is unlike a typical hybrid Azure AD-joined scenario because rebooting the device is postponed. The device is resealed prior to the time when connectivity to a domain controller is expected, and the domain network is contacted when the device is unboxed on-prem by the end-user.
>Because the OEM or vendor performs the white glove process, this <u>doesn't require access to an end-user's on-prem domain infrastructure</u>. This is unlike a typical hybrid Azure AD-joined scenario because rebooting the device is postponed. The device is resealed prior to the time when connectivity to a domain controller is expected, and the domain network is contacted when the device is unboxed on-prem by the end-user.
## Preparation
@ -110,8 +111,8 @@ If the pre-provisioning process completed successfully and the device was reseal
- Power on the device.
- Select the appropriate language, locale, and keyboard layout.
- Connect to a network (if using Wi-Fi). If using Hybrid Azure AD Join, there must be connectivity to a domain controller; if using Azure AD Join, internet connectivity is required.
- On the branded sign-on screen, enter the user’s Azure Active Directory credentials.
- If using Hybrid Azure AD Join, the device will reboot; after the reboot, enter the user’s Active Directory credentials.
- On the branded sign-on screen, enter the user's Azure Active Directory credentials.
- If using Hybrid Azure AD Join, the device will reboot; after the reboot, enter the user's Active Directory credentials.
- Additional policies and apps will be delivered to the device, as tracked by the Enrollment Status Page (ESP). Once complete, the user will be able to access the desktop.
@ -45,9 +46,9 @@ Also new in this version of Windows:
## New in Windows 10, version 1809
Windows Autopilot [self-deploying mode](self-deploying.md) enables a zero touch device provisioning experience. Simply power on the device, plug it into the Ethernet, and the device is fully configured by Windows Autopilot. This self-deploying capability removes the current need to have an end user interact by pressing the “Next” button during the deployment process.
Windows Autopilot [self-deploying mode](self-deploying.md) enables a zero touch device provisioning experience. Simply power on the device, plug it into the Ethernet, and the device is fully configured by Windows Autopilot. This self-deploying capability removes the current need to have an end user interact by pressing the "Next" button during the deployment process.
You can utilize Windows Autopilot self-deploying mode to register the device to an AAD tenant, enroll in your organization’s MDM provider, and provision policies and applications, all with no user authentication or user interaction required.
You can utilize Windows Autopilot self-deploying mode to register the device to an AAD tenant, enroll in your organization's MDM provider, and provision policies and applications, all with no user authentication or user interaction required.
>[!NOTE]
>Window 10, version 1903 or later is required to use self-deploying mode due to issues with TPM device attestation in Windows 10, version 1809.
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
jdmartinez36