Windows Autopilot troubleshooting FAQ

Windows Autopilot is designed to simplify all parts of the Windows device lifecycle, but there are always situations where issues might arise. When troubleshooting an issue, it's helpful to understand:

• The Windows Autopilot process flow.
• How Windows Autopilot device profiles are downloaded.
• Key activities to perform during troubleshooting.

Whether performing user-driven or self-deploying device deployments, the troubleshooting process is about the same. It's useful to understand the flow for a specific device:

1. A network connection is established. The connection can be a wireless (Wi-fi) or wired (Ethernet) connection.

2. The Windows Autopilot profile is downloaded. When a wired connection is used, or a wireless connection is established, the profile downloads from the Windows Autopilot deployment service as soon as the network connection is in place.

3. User authentication occurs. During a user-driven deployment, the user enters their Microsoft Entra credentials, which is then validated.

4. Microsoft Entra join occurs. For user-driven deployments, the device is joined to Microsoft Entra ID using the specified user credentials. For self-deploying scenarios, the device is joined without specifying any user credentials.

5. Automatic mobile device management (MDM) enrollment occurs. As part of the Microsoft Entra join process, the device enrolls in the MDM service configured in Microsoft Entra ID (for example, Microsoft Intune).

6. Settings are applied. If the enrollment status page is configured, most settings are applied while the enrollment status page is displayed. If not configured or available, settings will be applied after the user is signed in.

When an Internet-connected Windows device boots up, it attempts to connect to the Windows Autopilot service and download a Windows Autopilot profile. The Windows Autopilot profile is downloaded as soon as possible, and again after each reboot.

The key troubleshooting activities to perform are:

• Review configuration: Are Microsoft Entra ID and Microsoft Intune or a non-Microsoft mobile device management (MDM) service configured as specified in Windows Autopilot configuration requirements?

• Check network connectivity: Can the device access the services described in Windows Autopilot networking requirements?

• Windows out-of-box experience (OOBE) behavior: Are the expected OOBE screens displayed? Is the Microsoft Entra credentials page customized with organization-specific details as expected?

• Microsoft Entra join issues: Is the device able to join Microsoft Entra ID?

• MDM enrollment issues: Is the device able to enroll in Microsoft Intune or non-Microsoft MDM service?

• Review logs that are automatically collected upon Windows Autopilot failure. For more information, see Collect diagnostics from a Windows device.

On Windows 11, the Windows Autopilot diagnostic page can be opened to view additional detailed troubleshooting information about the Windows Autopilot provisioning process. To enable the Windows Autopilot diagnostics page:

1. Go to the ESP profile where the Windows Autopilot diagnostics page needs to be enabled.

2. Make sure that Show app and profile configuration progress is selected to Yes.

3. Make sure that Turn on log collection and diagnostics page for end users is selected to Yes.

To access any diagnostic information once the diagnostic page is enabled, select the View Diagnostics button or enter the keystroke CTRL + SHIFT + D. The diagnostics page is currently supported under the following conditions:

• Windows 11.
• Windows Autopilot user-driven mode.
• When signing in with a Work or School account. Personal Microsoft accounts aren't supported.

Windows Autopilot logs entries into the event log. The log entries can be used to see details related to the Windows Autopilot profile settings and OOBE flow. These entries can be viewed using Event Viewer. Review the information in Event Viewer at Application and Services Logs -> Microsoft -> Windows -> ModernDeployment-Diagnostics-Provider -> Autopilot.

The following events might be recorded, depending on the scenario and profile configuration:

Windows Autopilot profile settings received from the Windows Autopilot deployment service are stored in the device's registry. This information can be found in the registry at the following registry key:

HKLM\SOFTWARE\Microsoft\Provisioning\Diagnostics\Autopilot

Available registry entries include:

ETW tracing can be used to get detailed information from Windows Autopilot and related components. The ETW trace files can be viewed using the Windows Performance Analyzer or similar tools. For more information, see Troubleshooting Windows Autopilot.

Error code 0x80180014 can occur under either of the following scenarios:

1. Microsoft Intune changed the Windows Autopilot self-deployment mode and pre-provisioning mode experience. To reuse a device, the device record created by Intune must be deleted.

   This change impacts all Windows Autopilot deployments that use the self-deployment or pre-provisioning mode. This change impacts devices when they devices are reused, reset, or when redeploying a profile.

   To resolve and fix the issue in this scenario and redeploy the device using Windows Autopilot, follow these steps:

   1. Delete the device record in Intune. For the specific steps, see Delete devices from the Intune admin center.
   2. Redeploy the Windows Autopilot deployment profile.

2. Windows MDM enrollment is disabled in the Intune tenant.

   To resolve and fix the issue in this scenario and redeploy the device using Windows Autopilot, follow these steps:

   1. Sign into the Microsoft Intune admin center.

   2. In the Home screen, select Devices in the left hand pane.

   3. In the Devices | Overview screen, under By platform, select Windows.

   4. In the Windows | Windows devices screen, under Device onboarding, select Enrollment.

   5. In the Windows | Enrollment screen, under Enrollment options, select Device platform restriction.

   6. In the Enrollment restrictions screen, under Device type restrictions, select All Users under the Name column.

   7. In the All Users screen that opens, under Manage, select Properties.

   8. In the Properties screen that opens, next to Platform settings, select the Edit link.

   9. In the Edit restriction screen that opens:

   10. Locate Windows (MDM) under the Type column.

   11. Make sure that Windows (MDM) is set to Allow under the Platform column.

   12. If Windows (MDM) is set to Block, change it to Allow.

   13. Select Review + save, and then either Save if a setting was changed, or Cancel if not settings were changed.

   14. Repeat the above steps for any additional restrictions that might exist in the Enrollment restrictions screen other than All Users. Only restrictions for the Windows platform need to be verified.

   Note

   When multiple restrictions exist, restrictions might exist that only allow certain groups MDM enrollment. Some of the restrictions blocking MDM enrollment might be valid based on what group the restrictions are assigned to. When experiencing this problem, verify that the device isn't a member of one of the groups where there's MDM enrollment is blocked. Alternatively, if applicable change the MDM enrollment setting for that restriction to Allow.

In both of these scenarios, in addition to error 0x80180014 occurring, the Event Tracing for Windows (ETW) logs might also show the following mobile device management (MDM) error:

MDM Enroll: Server Returned Fault/Code/Subcode/Value=(DeviceNotSupported) Fault/Reason/Text=(Enrollment blocked for AP device by SDM One Time Limit Check)

This issue usually occurs because the device hash in the CSV file is incorrectly formatted. The issue can be confirmed by running a network trace while the issue occurs. Most likely the device hash in the CSV file is incorrectly formatted if an error 400 occurs in the network trace. The message body of the 400 error message shows:

Cannot convert the literal '[DEVICEHASH]' to the expected type 'Edm.Binary'

Anything that corrupts the collected hash can cause this error. One possibility is that the hash itself fails to be decoded, even if the hash is valid.

The device hash is Base64. At the device level, it's encoded as unpadded Base64, but Windows Autopilot expects padded Base64. Usually, the payload doesn't require padding and the process works. Sometimes, however, the payload doesn't line up cleanly and padding is necessary. In this case, the 400 error message occurs. PowerShell's Base64 decoder also expects padded Base64, so this decoder can be used to validate that the hash is properly padded.

The "A" characters at the end of the hash are effectively empty data. Each character in Base64 is 6 bits. A in Base64 is 6 bits equal to 0. Deleting or adding As at the end doesn't change the actual payload data.

To resolve and fix this issue, the hash needs to be modified. The new value then needs to be tested until PowerShell succeeds in decoding the hash. The result is mostly illegible, which is fine as long as the error Invalid length for a Base-64 char array or string isn't displayed.

To test the base64, use the following PowerShell:

[System.Text.Encoding]::ascii.getstring( [System.Convert]::FromBase64String("DEVICE HASH"))

As an example:

[System.Text.Encoding]::ascii.getstring( [System.Convert]::FromBase64String("Q29udG9zbwAAA"))

This particular example isn't a device hash, but it's a misaligned unpadded Base64 so it's good for testing.

Now for the padding rules. The padding character is "=". The padding character can only be at the end of the hash, and there can only be a maximum of two padding characters. Here's the basic logic.

• Does decoding the hash fail?
  • Yes: Are the last two characters "="?
    • Yes: Replace both "=" with a single "A" character, then try again
    • No: Add another "=" character at the end, then try again
• No: That hash is valid

Looping the logic on the previous example hash, we get the following permutations:

• Q29udG9zbwAAA
• Q29udG9zbwAAA=
• Q29udG9zbwAAA==
• Q29udG9zbwAAAA
• Q29udG9zbwAAAA=
• Q29udG9zbwAAAA== - This result has valid padding.

Replace the collected hash with this new padded hash then try to import again.

The Windows Autopilot profile isn't applied if the following conditions are met:

• A hardware change occurs on a device.

• The device is reimaged to a Windows version before one of the following versions:

  • Windows 11, version 21H2 with KB5017383.

  • Windows 10, versions 22H2.

This behavior is expected.

The message Fix pending or Attention required might also be displayed in the Windows Autopilot devices page for the device. These messages indicate that a hardware change occurred on the device. When the link for the Fix pending status is selected, the following message appears:

We've detected a hardware change on this device. We're trying to automatically register the new hardware. You don't need to do anything now; the status will be updated at the next check in with the result.

To resolve and fix this issue, deregister and re-register the device. For more information including how to deregister a device, see the following articles:

• Deregister a device.
• Return of key functionality for Windows Autopilot sign-in and deployment experience.
• Windows Autopilot motherboard replacement scenario guidance.

This issue occurs if the device was previously registered in Microsoft Entra ID before it was joined to Microsoft Entra ID. The device possibly registered in Microsoft Entra ID via something like a Workplace join. If the Microsoft Entra ID registered device isn't deleted from Microsoft Entra ID before the device is joined to Microsoft Entra ID, then the previous trust type is retained in the record. Joining an existing Microsoft Entra registered device to Microsoft Entra ID results in the Windows Autopilot device showing as Microsoft Entra registered instead of Microsoft Entra joined.

To resolve and fix this issue, before registering an existing Microsoft Entra ID registered device as a Windows Autopilot device, the following existing device objects for the device should be deleted:

• Microsoft Intune.
• Microsoft Entra ID.
• Windows Autopilot.

After all device objects are deleted, re-register the device as a Windows Autopilot device and then re-enroll the device. For more information on properly deleting all of the device objects, see Deregister a device.

To troubleshoot enrollment issues in Microsoft Intune such as the error code 80180018 in the Something went wrong error page, see Troubleshooting Windows device enrollment errors in Intune. Common issues can include:

• Incorrect or missing licenses assigned to the user.
• Too many devices enrolled for the user.

See Windows Autopilot Reset: Troubleshooting for more help if Windows Autopilot Reset fails immediately with the error:

Ran into trouble. Please sign in with an administrator account to see why and reset manually.

It's useful to check if the device received a Windows Autopilot profile. If the device did receive a Windows Autopilot profile, verify that the settings in the profile are correct.

This error message usually indicates an issue with licensing. The complete error message reads:

Something went wrong

Can't connect to the URL of your organization's MDM terms of use. Try again, or contact your system administrator with the problem information from this page.

Verify that the user who is signing into the device has a valid Intune, EMS, or Microsoft 365 license.

The most common issue joining a device to Microsoft Entra ID is related to Microsoft Entra permissions. Make sure that the correct configuration is in place to allow users to join devices to Microsoft Entra ID. For more information, see Configuration requirements.

Errors occur if a user exceeds the allowed number of devices they can join. This default limit is 50 devices but can be configured in Microsoft Entra ID. For more information, see Understand Intune and Microsoft Entra device limit restrictions.

A Microsoft Entra device is created upon import. It's important this object isn't deleted. The object acts as Windows Autopilot's anchor in Microsoft Entra ID for group membership and targeting, including the profile. Deleting it might lead to Microsoft Entra join errors. If this object is deleted, the issue can be fixed by deleting and reimporting the device as a Windows Autopilot device. Deleting and reimporting the device as a Windows Autopilot device recreates the associated object in Microsoft Entra ID.

There are a significant number of policy settings available for Windows, including:

• Native mobile device management (MDM) policies.
• Group policy (ADMX-backed) settings.

Some policy settings can cause issues in some Windows Autopilot scenarios. These issues can arise because of how the policies change Windows behavior. If any of these issues are discovered, remove the policy in question to resolve the issue.

The following policies are known to cause issues with Windows Autopilot. Make sure to configure the policies appropriately so that they don't conflict with Windows Autopilot:

The Enrollment Status Page (ESP) used by Windows Autopilot doesn't support mixing of line-of-business (LOB) and Win32 applications. Both LOB and Win32 applications use TrustedInstaller which doesn't allow simultaneous installations. If both an LOB and Win32 application attempt to install at the same time, the following error message occurs during ESP:

Another installation is in progress, please try again later.

For more information, see Set up the Enrollment Status Page - Device setup: Apps.

If mixing LOB and Win32 apps is required, consider using Windows Autopilot device preparation, which doesn't use ESP so therefore supports mixing of LOB and Win32 apps.

The Teams Machine-Wide Installer component of the Microsoft 365 Click-to-Run version of Office includes an MSI installation. ESP doesn't track the Teams Machine-Wide Installer MSI install. Because ESP doesn't track the Teams Machine-Wide Installer MSI install, it can cause a conflict when other Win32 app MSI based installs attempt to install during ESP. MSIs install via TrustedInstaller which doesn't allow simultaneous installations. This conflict can cause either the Teams Machine-Wide Installer to fail or other MSI based installs to fail during ESP. For more information, see Set up the Enrollment Status Page - Device setup: Apps.

This issue might be random and might not always occur. The issue occurs due to a timing issue between the Teams Machine-Wide Installer MSI install and other Win32 app MSI installs.

To work around the issue or avoid the error, use one of the following solutions:

1. Don't install Teams as part of the Microsoft 365 Click-to-Run install of Office. Instead, deploy Teams as a Win32 app after the Windows Autopilot deployment completes.

2. Don't install the Microsoft 365 Click-to-Run version of Office during ESP. Instead, deploy the Microsoft 365 Click-to-Run install of Office after the Windows Autopilot deployment completes.

3. Use a custom PowerShell script for Intune Management Extension (IME) that checks if TrustedInstaller is currently installing another MSI. If it is, then wait for the current MSI to finish installing before launching a new MSI install.

4. For Windows 11 deployments, use Windows Autopilot device preparation. Windows Autopilot device preparation doesn't use ESP so therefore supports mixing of LOB and Win32 apps.

5. Continue on error for ESP failures. If the problem occurs with this option enabled, some applications including Teams might not install. However, ESP continues and doesn't fail.

Related content

• Windows Autopilot - known issues.
• Collect MDM logs.
• Collect diagnostics from a Windows device.