- Windows 11
- Windows 10
This article provides OEMs, partners, administrators, and end users with answers to some frequently asked questions about deploying Windows with Autopilot.
A glossary of abbreviations used in this article is provided at the end.
Microsoft Partner Center
In the Partner Center, does the Tenant ID need to be provided with every device file upload? Is it needed to allow the business customer to access their devices in Microsoft Store for Business (MSfB)?
No. Providing the Tenant ID is a one-time entry in the Partner Center that can be reused with future device uploads.
How does the customer or tenant know that their devices are ready to be claimed in MSfB?
After the device file upload is completed in the Partner Center, the tenant can see the devices available for Windows Autopilot setup in MSfB. The OEM needs to advise the tenant to access MSfB. Autonotification from MSfB to the tenant is being developed.
How does a customer authorize an OEM or Channel Partner to register Autopilot devices on the customer's behalf?
Before an OEM or Channel Partner can register a device for Autopilot for a customer, the customer must first give them consent. The consent process begins with the OEM or Channel Partner sending a link to the customer that directs the customer to a consent page in MSfB. For more information, see Registration.
Are there any restrictions if a business customer has registered devices in MSfB and later wants those devices to be managed by a Cloud Solution Provider (CSP) using the Partner Center?
The business customer must delete the devices in MSfB before the CSP can upload and manage them in the Partner Center.
Does Windows Autopilot support removing the option to enable a local administrator account?
No. Windows Autopilot doesn't support removing the local admin account. However, it does support restricting the user performing Azure Active Directory (Azure AD) domain join in OOBE to a standard account (versus an administrator account by default).
How can I test the Windows Autopilot CSV file in the Partner Center?
Only CSP partners have access to the Partner Center portal. If you're a CSP, you can create a sales agent user account that has access to devices for testing the file. This test can be done today in the Partner Center.
For more information, see Create user accounts.
Is it required to become a CSP to participate in Windows Autopilot?
This requirement doesn't apply to top volume OEMs because they can use the OEM Direct API. All others who choose to use MPC to register devices must become CSPs to access MPC.
Do the different CSP levels have all the same capabilities when it comes to Windows Autopilot?
For the purposes of Windows Autopilot, there are three different types of CSPs, each with different levels of authority and access:
- Direct CSP: Gets direct authorization from the customer to register devices
- Indirect CSP provider: Gets implicit permission to register devices through the relationship their CSP reseller partner has with the customer. Indirect CSP providers register devices through the Microsoft Partner Center.
- Indirect CSP reseller: Gets direct authorization from the customer to register devices. At the same time, their indirect CSP provider partner also gets authorization, which means that either the indirect provider or the indirect reseller can register devices for the customer. However, the indirect CSP reseller must register devices through the Partner Center user interface by manually uploading the CSV file. The indirect CSP provider can register devices using the Partner Center APIs.
Is there such a thing as a single, worldwide CSP account?
No. The CSP sales regions depend on the location of the Azure AD tenant. A CSP partner can only sell or manage customers with a tenant located in the same CSP region. A partner's CSP region is based on the location of the tenant the CSP partner is using to transact. If the customer tenant was created in the US, only a partner that has a CSP enrollment in the US can establish a reseller relationship with this customer.
For Autopilot & Intune, the location of the end user or device doesn't matter. A device used by an employee located in Germany can enroll using the Autopilot profile created in the US tenant and can be managed by the Intune service instance in US. The user in Germany will also authenticate in the US-based Azure AD instance.
If a partner wants to manage customers globally, they need to have a global presence. They need multiple CSP enrollments in each of the CSP sales regions where they conduct business.
It's not possible to create user accounts that have access to all CSP tenants. This scenario would translate into 18 user accounts for a CSP admin agent that wants to manage all customers around the world.
In summary, the location of the user and devices doesn't matter. The location of the customer tenant matters. Cross-border device registration isn't the problem. The problem is cross-border sales via CSP.
Does the Partner Center have access to the profiles created in Intune or Microsoft Store for Business?
No. The Partner Center doesn't have access to profiles created in Intune or Microsoft Store for Business. It only has access to the Autopilot profiles created through the Partner Center.
What changes need to be made in the factory OS image for customer configuration settings?
No changes are required on the factory floor to enable Windows Autopilot deployment.
What version of the OA3 tool meets Windows Autopilot deployment requirements?
Windows Autopilot can work with any version of the OA3 tool. We recommend using a supported version of Windows to generate the 4K hardware hash.
When placing an order, do customers need to be state whether they want it with or without Windows Autopilot options?
Yes. If they want Windows Autopilot, they'll want a supported version of Windows. Also, they'll want to receive the CSV file or have the file upload completed on their behalf.
Does the OEM need to manage or collect any custom imaging files from customers? Do they need to upload any images to Microsoft?
No. OEMs just send the CBRs as usual to Microsoft. No images are sent to Microsoft to enable Windows Autopilot. Windows Autopilot only customizes OOBE and allows policy configurations.
Are there any customer issues with upgrading from Windows 8 to Windows 10 or Windows 11?
The devices must be running a supported version of Windows 10 or Windows 11 general availability channel to enroll in Windows Autopilot deployment. Otherwise, there's generally no issue. For more information, see Windows Autopilot - known issues.
Will there be any change to the existing CBR with 4K hardware hash?
What new information needs to be sent from the OEM to Microsoft?
Nothing, unless the OEM opts to register the device on the customer's behalf. In this case, they must upload the device ID CSV file to the Microsoft Partner Center or use the OEM direct API.
Is there a contract or amendment for an OEM to participate in an Autopilot deployment?
Can a comma be used in the CSV file?
Is there a limit to the number of devices that can be listed in the CSV file?
Yes. The CSV file can only contain 500 devices to apply to a single profile. If more than 500 devices need to be applied to a profile, the devices need to be uploaded through multiple CSV files.
Does Microsoft have any recommendations on how an OEM should provide the CSV file to their customers?
Encrypt the CSV file when sending it to the business customer to self-register their Windows Autopilot devices through MPC, MSfB, or Intune.
What data does the hardware hash need to include?
Every hardware hash submitted by the OEM has to contain the following data:
- SMBIOS UUID: A universally unique identifier
- MAC address: The network card unique identifier
- Unique disk serial number: If you use the Windows OEM Activation 3.0 tool
Since Windows Autopilot is based on the ability to uniquely identify devices applying for cloud configuration, it's critical to submit hardware hashes that meet the outlined requirement.
Why are the SMBIOS UUID, MAC address, and disk serial number required in the hardware hash details?
For creating the hardware hash, these fields are needed to identify a device, as parts of the device are added or removed. Since we don't have a unique identifier for Windows devices, these fields are the best logic to identify a device.
What's the difference between the OA3 hardware hash, the 4K hardware hash, and the Windows Autopilot hardware hash?
None. They're different names for the same thing. The OA3 tool output is called the OA3 hash, which is 4K in size, and is used for the Windows Autopilot deployment scenario.
If you use an older, unsupported Windows version of the OA3 tool, you get a different-sized hash. You can't use this hash for a Windows Autopilot deployment.
If I need to replace hardware like the disk or network card, does that invalidate the hardware hash?
Yes. If you replace parts, you may need to generate a new hardware hash. It depends on what's replaced, and the characteristics of the parts.
For example, if you replace the TPM or motherboard, it's a new device and you must get a new hardware hash. If you replace one network card, it's probably not a new device, and the device will function with the old hardware hash.
In general, after any hardware changes, assume the old hardware hash is invalid and get a new hardware hash. This process is recommended anytime you replace parts.
How does Autopilot handle motherboard replacement scenarios?
Motherboard replacement is out for scope for Autopilot. Any repaired or serviced device that alters the ability to identify the device for Windows Autopilot must go through the normal OOBE process. It must manually select the right settings or apply a custom image.
To reuse the same device for Windows Autopilot after a motherboard replacement, use the following process:
- Unregister the device from Autopilot.
- Replace the motherboard.
- Generate a new 4K hardware hash.
- Register the device with the new 4K hardware hash or device ID.
An OEM can't use the OEM direct API to re-register the device, which only accepts a tuple or PKID. In this case, the OEM can send the new 4K hardware hash information using a CSV file to customer, and let customer re-register the device using MSfB or Intune.
Are there any specific requirements for the SMBIOS UUID?
It must be unique as specified in the Windows hardware requirements.
What's the requirement on the SMBIOS table to meet the Windows Autopilot hardware hash need?
It must meet all the Windows hardware requirements. For more information, see Windows Hardware Compatibility Program Specifications and Policies.
If the SMBIOS supports UUID and Serial Number, is it enough for the OA3 tool to generate the hardware hash?
No. At a minimum, the following SMBIOS fields need to have unique values:
What's the interface to get the MAC address and disk serial number? How does the OA tool get this information?
The method for getting this information varies depending on the scenario, but in general:
The disk serial number comes from
The network MAC address is from
If a device has multiple network cards or disks, how does the OA3 tool choose which MAC address and disk serial number to use?
All available values are used, although there may be specific usage rules. The serial number of the system disk is more important than the other disks available. Network interfaces that are removable shouldn't be used if detected as they're removable. LAN vs WLAN shouldn't matter, as both will be used.
How do I know that I received Autopilot?
You can tell that the device received an Autopilot configuration but hasn't yet applied it when you skip the selection page, and are immediately taken to a generic or customized sign-in page.
Why did a user end up as an administrator when the Autopilot profile was configured otherwise?
Azure AD administrators will be local administrators even if Windows Autopilot is configured to disable this configuration.
To help troubleshoot, run
licensingdiag.exe and send the
.cab (cabinet) file to
AutopilotHelp@microsoft.com. If possible, also collect an ETL from Windows Performance Recorder (WPR).
Often in these cases, users aren't signing into the right Azure AD tenant, or are creating local user accounts.
For a complete list of support options, see Windows Autopilot support.
If I make changes to an existing Autopilot profile, will the changes take effect on devices that have that profile assigned to them and are already deployed?
No. Windows Autopilot profiles aren't resident on the device. They're downloaded during OOBE, the settings defined at the time are applied. Then the profile is discarded on the device. If the device is reimaged or reset, the new profile settings will take effect the next time the device goes through OOBE.
What's the experience if a device isn't registered or if I don't configure Windows Autopilot before an end user attempts to self-deploy?
If the device isn't registered, it won't receive the Windows Autopilot experience and the end user will go through normal OOBE. The Windows Autopilot configurations won't be applied until the user runs through OOBE again, after registration. If a device is started before an MDM profile is created, the device will go through standard OOBE experience. You then have to manually enroll that device into the MDM. The next time the device is reset, it will go through the Windows Autopilot OOBE experience.
Why didn't I receive a customized sign-in screen during Autopilot?
To receive a customized sign-in experience, configure tenant branding in the Azure portal.
What happens if a device is registered with Azure AD but doesn't have a Windows Autopilot profile assigned?
Since no Windows Autopilot profile is assigned to the device, the user sees the default OOBE.
How can I collect logs on Autopilot?
The best way to collect logs on Windows Autopilot performance is to collect a WPR trace during OOBE. The XML file (WPRP extension) for this trace may be provided upon request.
Does Autopilot require the use of Microsoft Intune?
No. Any MDM will work with Autopilot, but others may not have the same full suite of Windows Autopilot features as Intune. You'll get the best experience with Intune.
Does Intune support preinstalling Win32 apps?
Yes. Intune supports Win32 apps using MSI and MSIX wrappers.
What is co-management?
Co-management enables you to concurrently manage Windows 10 or later devices by using both Microsoft Configuration Manager and Microsoft Intune. It lets you cloud-attach your existing investment in Configuration Manager by adding new functionality. By using co-management, you have the flexibility to use the technology solution that works best for your organization.
When a Windows device has the Configuration Manager client and is enrolled to Intune, you get the benefits of both services. You control which workloads, if any, you switch the authority from Configuration Manager to Intune. Configuration Manager continues to manage all other workloads, including those workloads that you don't switch to Intune, and all other features of Configuration Manager that co-management doesn't support.
For more information, see the following articles:
Does Autopilot require Configuration Manager?
No. It's not required, but you can use it together with Autopilot in the following scenarios:
What's self-deploying mode?
Self-deploying mode only requires the user to power on the device. It's useful for scenarios where a standard user account isn't needed. For example, shared or kiosk devices.
For more information, see Windows Autopilot self-deploying mode.
What's hybrid Azure AD join?
Hybrid Azure AD-joined devices connect to an on-premises Active Directory domain and Azure AD.
For more information, see Introduction to device management in Azure Active Directory.
What's Windows Autopilot reset?
Windows Autopilot reset removes user apps and settings from a device, but maintains Azure AD domain join and MDM enrollment. This feature is useful when you transfer a device from one user to another.
For more information, see Windows Autopilot reset.
What's Autopilot personalization?
You can add the following customizations to the OOBE experience:
- A personalized welcome message
- Personalize the username hint
- Your organization's logo
What's Autopilot for existing devices?
Autopilot for existing devices offers an upgrade path to Windows 10 or Windows 11 for all existing Windows 8.1 devices.
For more information, see Autopilot for existing devices.
If I wipe the machine and restart, will I still receive Windows Autopilot?
Yes. If the device is still registered for Autopilot and is running a supported version of Windows, it will receive the Autopilot experience.
Can I harvest the device fingerprint on existing devices?
Yes. If the device is running a supported version of Windows, you can harvest device fingerprints for registration. There are no plans to backport the functionality to earlier releases. There's no way to harvest them on devices running unsupported versions of Windows.
Is Windows Autopilot supported on other SKUs, for example, Surface Hub, HoloLens, or Windows Mobile?
For Surface Hub, Windows Mobile, and other SKUs, Windows Autopilot isn't supported. HoloLens 1 also doesn't support Windows Autopilot. Starting with Windows Holographic version 2004, HoloLens 2 supports Windows Autopilot self-deploying mode with Microsoft Intune. Third-party MDM providers aren't supported.
For more information on HoloLens 2, see Windows Autopilot for HoloLens 2.
Does Windows Autopilot work after MBR or image reinstallation?
Yes. For more information, see Windows Autopilot motherboard replacement scenario guidance.
What does this error message mean? This user isn't authorized to enroll, error code 801c0003.
There are limits to the number of devices a particular Azure AD user can enroll in Azure AD, and the number of devices that are supported per user in Intune. These limits are configurable, but not infinite. If you reuse devices, or roll back to previous virtual machine snapshots, you'll see this error frequently.
What happens if a device is registered to a malicious agent?
By design, Windows Autopilot doesn't apply a profile until the user signs in with the matching tenant for the configured profile using the Azure AD sign-in process. For example,
badguys.com registers a device owned by
contoso.com. At worst, the user will be directed to sign in to
badguys.com. When the user enters their email and password, the sign-in information is redirected through Azure AD to the proper Azure AD authentication and the user is prompted to then sign into
contoso.com doesn't match
badguys.com as the tenant, the malicious profile isn't applied and the user sees the regular OOBE.
Where is Windows Autopilot data stored?
Windows Autopilot data is stored within the European Union (EU). It's not stored in a sovereign cloud, even when the Azure AD tenant is registered in a sovereign cloud. This storage applies to all Windows Autopilot data, whatever portal is used to deploy Autopilot.
Why is Windows Autopilot data stored in the US and not in a sovereign cloud?
Customer data isn't stored, only business data that enables Microsoft to provide a service. For that reason, it's appropriate for the data to be stored in the US. Customers can stop subscribing to the service at any time. In that event, the business data is removed by Microsoft. Autopilot isn't currently supported in any sovereign cloud.
How many ways are there to register a device for Windows Autopilot?
There are six ways to register a device, depending on who does the process:
- OEM direct API, which is only available to TVOs
- MPC using the MPC API, which is only available to CSPs
- MPC using manual upload of CSV file in the UI, which is only available to CSPs
- MSfB using CSV file upload
- Intune using CSV file upload
- Microsoft 365 Business Premium portal using CSV file upload
How many ways are there to create a Windows Autopilot profile?
There are four ways to create and assign a Windows Autopilot profile:
- Through MPC, which is only available to CSPs
- Through MSfB
- Through Intune or another MDM service
- Microsoft 365 Business Premium portal
Microsoft recommends creation and assignment of profiles through Intune.
What are some common causes of registration failures?
- Bad or missing hardware hash entries can lead to faulty registration attempts
- Hidden special characters in CSV files. To avoid this issue, after creating your CSV file, open it in Notepad to look for hidden characters, trailing spaces, or other corruptions.
Is Autopilot supported in all regions/countries?
Autopilot only supports customers using global Azure. Global Azure doesn't include the following three entities:
- Azure Germany
- Azure China 21Vianet
- Azure Government
If you use global Azure, there are no region restrictions. For example, Contoso uses global Azure but has employees working in China. The Contoso employees working in China can still use Autopilot to deploy devices. If Contoso uses Azure China 21Vianet, the Contoso employees can't use Autopilot. While Autopilot is available in global tenants, users in China may experience poor connectivity and high latency when deploying due to ISP-related issues. If you are experiencing these issues when deploying in the region, please contact your local ISP for support.
Why does TPM provisioning/attestation take longer during the first boot on a device?
TPM provisioning involves generating and processing strong cryptographic keys. Depending on the characteristics of the TPM hardware used on a device, it may take longer than a minute on first boot.
|CSV||Comma-separated value format, which is a file type that's similar to an Excel spreadsheet|
|MPC||Microsoft Partner Center|
|MDM||Mobile Device Management|
|OEM||Original Equipment Manufacturer|
|CSP||Cloud Solution Provider|
|MSfB||Microsoft Store for Business|
|Azure AD||Azure Active Directory|
|4K HH||4K hardware hash|
|CBR||Computer Build Report|
|DDS||Device Directory Service|
|OOBE||Out of Box Experience|
|UUID||Universally Unique Identifier|