Windows Autopilot FAQ

No. Providing the Tenant ID is a one-time entry in the Partner Center that can be reused with future device uploads.

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.

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.

The business customer must delete the devices in MSfB before the CSP can upload and manage them in the Partner Center.

No. Windows Autopilot doesn't support removing the local admin account. However, it does support restricting the user performing Microsoft Entra domain join in OOBE to a standard account (versus an administrator account by default).

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.

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.

For the purposes of Windows Autopilot, there are three different types of CSPs, each with different levels of authority and access:

1. Direct CSP: Gets direct authorization from the customer to register devices
2. Indirect CSP provider: Gets implicit permission to register devices through the relationship their CSP reseller partner has with the customer. Indirect CSP providers register devices through the Microsoft Partner Center.
3. Indirect CSP reseller: Gets direct authorization from the customer to register devices. At the same time, their indirect CSP provider partner also gets authorization, which means that either the indirect provider or the indirect reseller can register devices for the customer. However, the indirect CSP reseller must register devices through the Partner Center user interface by manually uploading the CSV file. The indirect CSP provider can register devices using the Partner Center APIs.

No. The CSP sales regions depend on the location of the Microsoft Entra 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. An employee located in Germany can enroll a device using the Autopilot profile created in the US tenant and manage it through the Intune service instance in the US. The user in Germany also authenticates in the US-based Microsoft Entra 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.

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.

No changes are required on the factory floor to enable Windows Autopilot deployment.

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.

Yes. If they want Windows Autopilot, a supported version of Windows is needed. A customer should also receive the CSV file or have the file upload completed on their behalf.

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.

The devices must be running a supported version of Windows general availability channel to enroll in Windows Autopilot deployment. Otherwise, there's generally no issue. For more information, see Windows Autopilot - known issues.

No.

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.

No.

No.

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.

Encrypt the CSV file when sending it to the business customer to self-register their Windows Autopilot devices through MPC, MSfB, or Intune.

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.

As parts of the device are added or removed, these fields are needed to identify a device when creating the hardware hash. Since we don't have a unique identifier for Windows devices, these fields are the best logic to identify a device.

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.

Yes. If you replace parts, you might need to generate a new hardware hash. It depends on the parts that were 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 functions 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.

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:

1. Unregister the device from Autopilot.
2. Replace the motherboard.
3. Generate a new 4K hardware hash.
4. Register the device with the new 4K hardware hash or device ID.

It must be unique as specified in the Windows hardware requirements.

It must meet all the Windows hardware requirements. For more information, see Windows Hardware Compatibility Program Specifications and Policies.

No. At a minimum, the following SMBIOS fields need to have unique values:

• ProductKeyID
• SmbiosSystemManufacturer
• SmbiosSystemProductName
• SmbiosSystemSerialNumber
• SmbiosSkuNumber
• SmbiosSystemFamily
• MacAddress
• SmbiosUuid
• DiskSerialNumber
• TPM
• EkPub

The method for getting this information varies depending on the scenario, but in general:

• The disk serial number comes from IOCTL_STORAGE_QUERY_PROPERTY with StorageDeviceProperty/PropertyStandardQuery.

• The network MAC address is from IOCTL_NDIS_QUERY_GLOBAL_STATS from OID_802_3_PERMANENT_ADDRESS.

All available values are used, although there can 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 are used.

A device has received an Autopilot configuration but hasn't yet applied it when the selection page is skipped and are immediately taken to a generic or customized sign-in page.

Microsoft Entra administrators are always 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 Microsoft Entra tenant, or are creating local user accounts.

For a complete list of support options, see Windows Autopilot support.

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.

If the device isn't registered, it doesn't receive the Windows Autopilot experience, and the end user goes 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 goes 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.

To receive a customized sign-in experience, configure tenant branding in the Azure portal.

Since no Windows Autopilot profile is assigned to the device, the user sees the default OOBE.

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 can be provided upon request.

No. Any MDM works with Autopilot, but others might not have the same full suite of Windows Autopilot features as Intune. The best experience is with Intune.

Yes. Intune supports Win32 apps using MSI and MSIX wrappers.

Co-management enables you to concurrently manage currently supported versions of Windows 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:

• What is co-management?
• How to enroll with co-management when provision with Windows Autopilot

No. It's not required, but you can use it together with Autopilot in the following scenarios:

• Co-management
• Autopilot for existing devices

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.

Microsoft Entra hybrid joined devices connect to an on-premises Active Directory domain and Microsoft Entra ID.

For more information, see Introduction to device management in Microsoft Entra ID.

Windows Autopilot reset removes user apps and settings from a device, but maintains Microsoft Entra 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.

You can add the following customizations to the OOBE experience:

• A personalized welcome message
• Personalize the username hint
• Your organization's logo

Autopilot for existing devices offers an upgrade path to currently supported versions of Windows for an existing Windows device.

For more information, see Autopilot for existing devices.

Current manufacturers enabled for this change are Dell, Dynabook, HP, Lenovo and Microsoft Surface. We're working to add other manufacturers and will update this list once they're onboarded. For more information, see Return of key functionality for Windows Autopilot sign-in and deployment.

Yes. If the device is still registered for Autopilot and is running a supported version of Windows, it receives the Autopilot experience.

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.

For Surface Hub, Windows Mobile, and other SKUs, Windows Autopilot isn't supported. HoloLens 1 also doesn't support Windows Autopilot. 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.

Yes. For more information, see Windows Autopilot motherboard replacement scenario guidance.

There are limits to the number of devices a particular Microsoft Entra user can enroll in Microsoft Entra ID, 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, this error occurs frequently.

By design, Windows Autopilot doesn't apply a profile until the user signs in with the matching tenant for the configured profile using the Microsoft Entra sign-in process. For example, badguys.com registers a device owned by contoso.com. At worst, the user is directed to sign in to badguys.com. When the user enters their email and password, the sign-in information is redirected through Microsoft Entra ID to the proper Microsoft Entra authentication and the user is prompted to then sign into contoso.com. Since contoso.com doesn't match badguys.com as the tenant, the malicious profile isn't applied and the user sees the regular OOBE.

Windows Autopilot data is stored within the European Union (EU). It's not stored in a sovereign cloud, even when the Microsoft Entra tenant is registered in a sovereign cloud. This storage applies to all Windows Autopilot data, whatever portal is used to deploy Autopilot.

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, Microsoft removes the business data. Autopilot isn't currently supported in any sovereign cloud.

There are six ways to register a device, depending on who does the process:

1. OEM direct API, which is only available to TVOs
2. MPC using the MPC API, which is only available to CSPs
3. MPC using manual upload of CSV file in the UI, which is only available to CSPs
4. MSfB using CSV file upload
5. Intune using CSV file upload
6. Microsoft 365 Business Premium portal using CSV file upload

There are four ways to create and assign a Windows Autopilot profile:

1. Through MPC, which is only available to CSPs
2. Through MSfB
3. Through Intune or another MDM service
4. Microsoft 365 Business Premium portal

Microsoft recommends creation and assignment of profiles through Intune.

1. Bad or missing hardware hash entries can lead to faulty registration attempts
2. Hidden special characters in CSV files. To avoid this issue, after creating your CSV file, open it in Notepad to look for hidden characters, trailing spaces, or other corruptions.

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 can experience poor connectivity and high latency when deploying due to ISP-related issues. If you're experiencing these issues when deploying in the region, contact your local ISP for support.

TPM provisioning involves generating and processing strong cryptographic keys. Depending on the characteristics of the TPM hardware used on a device, it can take longer than a minute on first boot.

When autologon with Windows Autopilot self-deploying mode is used, autologon uses the KioskUser0 local account. By default, user ESP isn't processed for local accounts, including the KioskUser0 local account, and a device token isn't issued until user ESP is processed. When using autologon, in order for applications to install after the ESP finishes, skip user ESP by using the custom OMA-URI SkipUserStatusPage. For more information, see the following articles:

• How can I disable the user ESP portion of the Enrollment Status Page (ESP) if an ESP has been configured on the device?.
• Deploy OMA-URIs to target a CSP through Intune, and a comparison to on-premises.

Device compliance in Microsoft Entra ID is reset during the User flow. Once the User flow completes, compliance is reevaluated and updated. This behavior is expected.