Windows Autopilot device preparation: known issues and how to troubleshoot a failed run

Windows Autopilot device preparation looks like classic Autopilot from the user's chair, but under the hood it's a different architecture, and most "it failed" tickets I see come from treating it like the old flow. In this post I'll cover the differences that cause confusion, the current known issues and their status, how to read the deployment status report, and the troubleshooting steps Microsoft documents for a run that didn't finish.

How device preparation differs from classic Autopilot#

• Windows 11 and Microsoft Entra join only. It needs 24H2 or later, or 22H2/23H2 with KB5035942. There's no hybrid join option, and no Enrollment Status Page: if you see an ESP, the device isn't running a device preparation deployment at all.
• The device group is special. The policy references an assigned security group whose owner must be the Intune Provisioning Client service principal (AppID f1346770-5b25-470b-88bd-d5744ab7952c, shown in some tenants as Intune Autopilot ConfidentialClient), and Microsoft Entra roles can be assigned to the group must be No. The device is added to that group during enrollment, which is what Microsoft calls enrollment time grouping: membership arrives just in time, so apps and policies assigned to the group reach the device immediately.
• Only what's selected in the policy is tracked. Apps and PowerShell scripts chosen in the policy install during OOBE and appear in the report; anything else assigned to the device group arrives after the desktop. Policies assigned to the group are synced but not tracked. Everything delivered during OOBE must be device-targeted and run in the System context.
• Limits. Since January 2026 a policy can carry up to 25 apps, in both user-driven and automatic mode. The automatic mode tutorial also states a limit of 10 PowerShell scripts.
• Precedence. A device registered for classic Autopilot runs the Autopilot profile, not device preparation, unless it's associated with the tenant. Device association, added in August 2026, writes a tenant marker into UEFI before enrollment; associated devices are marked corporate-owned, can receive device-targeted device preparation policies and OOBE customisations such as a %SERIAL% naming template, and take precedence over the Autopilot profile. You monitor them under Devices › Enrollment › Device association › Devices.

Known issues and their status#

The security group entry deserves detail, because it's the one that silently leaves devices unprotected. Microsoft lists four causes: membership updates that fail during retry windows, a group changed from static to dynamic after the policy was configured, the Intune Provisioning Client removed as the group's owner, and a group deleted before Intune noticed. The mitigation is to validate the group before provisioning (the right group is selected in the policy, it isn't role-assignable, and the service principal owns it) and to add already-deployed devices to the correct group by hand.

Reading the deployment status report#

Open Devices › Monitor and select Windows Autopilot device preparation deployments (the Monitor tab under Devices › Enrollment links to the same report). Each row shows:

Select a device to open the details pane. The Device section shows the Intune and Entra device IDs, serial number, the deployment policy and its Policy Version (incremented on every save, handy to confirm a device received your latest edit) and the OS version at deployment. Apps and Scripts list each item as Installed, In progress, Skipped or Failed. Skipped usually means the item was selected in the policy but isn't assigned to the policy's device group, or isn't applicable to the device. Two housekeeping notes from the documentation: deployment records are cleaned up automatically every 28 days (only records created after the cleanup feature was introduced), and Windows 365 devices reprovisioned after a failure stay in the report and in Intune so you can still collect diagnostics, so use cleanup rules for those.

Troubleshooting a failed run#

1. The experience never launched. Confirm the build meets the minimum (OEM image or media with the required update), that the device isn't a registered Autopilot device with a profile (deregister it, or associate it), that the user is in the policy's user group, that a device group is selected in the policy, that automatic MDM enrollment is configured, that users may join devices to Microsoft Entra ID, and that a corporate identifier exists if you block personal enrollments.
2. The device isn't in the device group. Check the owner, the group selected in the policy, the role-assignable setting, and that the admin who created the policy has the Enrollment time device membership assignment RBAC permission.
3. Apps or scripts show Skipped. Assign them to the policy's device group and set them to install in the System context; during OOBE nothing runs as a user.
4. The policy won't save its device group, with "There was a problem with the device security group" or "Failed to update security group device preparation setting", or shows 0 groups assigned. Add the Intune Provisioning Client as the group owner. If the service principal doesn't exist in the tenant, create it with the Microsoft Graph PowerShell SDK:
   PowerShell

   Connect-MgGraph -Scopes "Application.ReadWrite.All"
   New-MgServicePrincipal -AppId f1346770-5b25-470b-88bd-d5744ab7952c

5. The wrong policy applied. When several user-driven policies target the same user, the one with the smallest Priority number wins; drag to reorder under Devices › Enrollment › Device preparation policies. Automatic-mode policies don't use priority because the Cloud PC provisioning policy picks them directly.
6. Export device information fails with "Export of device link information timed out" during association. Use a USB drive with a single NTFS partition; FAT32 or mixed partitions cause it.
7. Collect logs. On the failure screen, Export logs writes to the first USB drive with no confirmation (the known issue above), so check the drive. After enrollment, use the Collect diagnostics action on the device record in Intune. For app and script phases, the Intune Management Extension logs under C:\ProgramData\Microsoft\IntuneManagementExtension\Logs are where the detail lives.

Verify the fix#

• The report shows Success with every selected app and script Installed, and the Policy Version matches your latest edit.
• The device appears as a member of the policy's device group in the Microsoft Entra admin center, and in Devices › Windows as corporate-owned and compliant.
• The user is a standard user or administrator as intended, which is quick to check with net localgroup Administrators on the device.

Key takeaways#

• Ownership of the device group by the Intune Provisioning Client is the single most common cause of broken device preparation. Check it first and never change the group from static to dynamic.
• "Skipped" in the report is a targeting problem, not an installation failure.
• Three of the headline known issues were resolved in 2026, but the fixes for BitLocker live in Windows, so the device needs KB5124012 or later at OOBE to benefit.
• Subscribe to the RSS link at the top of the device preparation known issues page; it has its own feed, separate from the classic Autopilot page.

References#

• Windows Autopilot device preparation known issues
• Windows Autopilot device preparation troubleshooting FAQ
• Windows Autopilot device preparation reporting and monitoring