Windows Autopilot device preparation is Microsoft’s newer deployment flow for Microsoft Entra joined Windows 11 devices. It is faster than the classic Autopilot profile model when the tenant is configured correctly, but failures can look vague from the user side. The device sits in OOBE, apps show as skipped, scripts never run, or the deployment report ends in Failed without giving the help desk a single obvious root cause.
This guide is for Intune admins who need a practical troubleshooting path. The main thing to understand is that device preparation depends on three moving parts arriving at the same time: the device preparation policy, the enrollment-time device group, and the apps or scripts selected in the profile. If any one of those is wrong, the user experience can fail even when enrollment itself technically succeeds.
What Device Preparation Changes
Classic Autopilot normally relies on device registration, profile assignment, dynamic groups, and the Enrollment Status Page. Device preparation uses a different model. Microsoft describes it as an Autopilot experience that adds the device to a security group at enrollment time so Intune can deliver the selected apps, scripts, and policies immediately.
That design solves a real operations problem. Dynamic group processing can be slow during high-volume provisioning. Device preparation uses enrollment time grouping to place the enrolling device into a predefined static Microsoft Entra security group during setup. Intune can then target the required payloads without waiting for later inventory-based group evaluation.
The catch is that the new speed comes with stricter dependencies:
- The device must be a supported Windows 11 build.
- The deployment is for Microsoft Entra join, not hybrid join.
- The selected device group must be configured for enrollment time grouping.
- The Intune Provisioning Client service principal must be able to update the group.
- Apps and PowerShell scripts must be both selected in the device preparation profile and assigned to the same device group.
- Policies assigned to the group can sync during deployment, but Microsoft does not track policy application as part of the device preparation deployment result.
That last point matters. If a security baseline or compliance policy is the real blocker, the device preparation report may not tell the whole story. Treat the report as the starting point, not the whole investigation.
Common Failure Patterns Admins See
Start by classifying the symptom. Most device preparation tickets fall into one of these buckets.
| Symptom | Likely area to inspect |
|---|---|
| Deployment status ends as Failed | Device preparation report, app status, script status, timeout settings |
| Apps show Skipped | App assignment missing from the device group, app not applicable, known managed installer issue |
| PowerShell script shows Skipped | Script selected in profile but not assigned to the device group |
| Device completes OOBE but misses required apps | Enrollment time group membership failure or assignment mismatch |
| Device becomes non-compliant after setup | Security group update failure, compliance policy timing, group owner problem |
| Profile assignment fails in the portal | RBAC, group scope, or known policy assignment issue |
Microsoft’s reporting page notes that app and script status can show values such as Installed, Failed, Skipped, and Dependent. In practice, Skipped is often the most useful clue. It usually means the item was selected in the device preparation policy but was not actually assigned to the device group used by that policy, or the item was not applicable to that device.
Do not jump straight to wiping the device. A wipe may reproduce the same failure if the group owner, app assignment, or managed installer setting is still wrong.
Step-by-Step Triage Workflow
Use this order during an active incident. It avoids wasting time on device-side resets before tenant-side configuration is checked.
1. Confirm the device is eligible
Device preparation is not a generic replacement for every Autopilot scenario. Microsoft lists Windows 11 as the target platform, with version 24H2 or later supported, and Windows 11 22H2 or 23H2 requiring KB5035942 or later. Microsoft Entra join is the supported join path.
Check these items first:
- The device is running a supported Windows 11 image.
- The device is not already registered as a classic Windows Autopilot device with a classic profile taking precedence.
- The user is in scope for the device preparation policy.
- Licensing and Intune enrollment prerequisites are present.
- Network access allows Windows activation, Intune enrollment, Microsoft Store, Win32 content delivery, and PowerShell script endpoints.
If you are using old media, fix the media before debugging Intune. Reimaging with stale Windows 11 22H2 or 23H2 media is a common reason device preparation behaves inconsistently across models.
2. Open the device preparation report
In the Intune admin center, go to the Windows Autopilot device preparation reporting area and inspect the specific deployment. You are looking for four fields:
- Deployment status
- Deployment policy
- Policy version
- App and script status
Policy version is easy to ignore, but it is useful when several admins are changing a profile during a rollout. If a failed device received an older policy version, do not compare it blindly against the latest profile screen.
For each failed device, record:
Device name:
User principal name:
Deployment policy:
Policy version:
Failed phase:
Failed app or script:
Last reported time:Keep this small incident record before wiping the machine. It gives you a reliable way to spot whether failures are tied to one policy version, one app, one script, or one hardware model.
3. Check enrollment time grouping failures
Enrollment time grouping is the backbone of device preparation. Microsoft’s Intune documentation says the failure report is under Devices > Monitor > Enrollment time grouping failures. The report shows devices that failed to become members of the configured static device group during setup. Microsoft also notes that recently updated information can take up to 20 minutes to appear.
If a device failed to join the group during enrollment, app and policy delivery can change after setup. That creates the classic “OOBE looked fine, but the desktop is missing half the build” ticket.
Verify the group itself:
- It is a static Microsoft Entra security group.
- It is the same group selected in the device preparation policy.
- The Intune Provisioning Client service principal is an owner.
- The group was not converted from static to dynamic after the profile was configured.
- The group was not deleted and recreated with the same display name.
- The admin editing the policy has the right scope group access.
Microsoft documents the Intune Provisioning Client app ID as f1346770-5b25-470b-88bd-d5744ab7952c. In some tenants the display name may appear differently, but the app ID is the safer identifier.
4. Validate app and script targeting
For every Win32 app, Store app, Enterprise App Catalog app, and PowerShell script selected in the device preparation profile, check the actual assignment. Selection in the profile is not enough. The item also has to be assigned to the device group used by the profile.
A clean validation table looks like this:
| Payload | Selected in profile | Assigned to device group | Install context | Detection rule tested |
|---|---|---|---|---|
| Microsoft 365 Apps | Yes | Yes | System | Yes |
| VPN client | Yes | Yes | System | Yes |
| BIOS utility | Yes | Yes | System | Yes |
| Enrollment cleanup script | Yes | Yes | System | Yes |
If the app shows Skipped, compare the selected profile list against the app assignment list. If it shows Failed, move to app-specific logs after confirming assignment is correct.
For Win32 apps, pull the Intune Management Extension logs from the device if it reaches the desktop:
C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log
C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\AgentExecutor.logFor a PowerShell script failure, AgentExecutor.log is usually faster than the portal. Look for the script name, execution context, exit code, and whether the script was blocked by execution policy, missing network access, or a dependency that is not present during OOBE.
5. Check known issues before rebuilding the profile
Microsoft’s known issues page for device preparation includes several items that can look like tenant misconfiguration:
- Win32, Microsoft Store, and Enterprise App Catalog apps can be skipped during OOBE when managed installer policy is active for the tenant. Microsoft says those apps install after the device reaches the desktop and the next sync completes.
- The apps and scripts tabs can display incorrect information while editing a profile. The documented workaround is to select the table header to reload the table contents.
- Security group membership update failures can lead to non-compliant devices.
- Removing the Intune Provisioning Client service principal as owner of the configured group can cause group update failures.
- Changing a configured security group from static to dynamic can cause failures.
- Custom compliance and device health scripts are not supported during device preparation deployments.
This is where many escalations go wrong. An admin sees app skips, edits the app package, retests, and gets the same result because the tenant has managed installer policy enabled. Check the known issues list before rebuilding a working package.
Practical Remediation Checklist
Once you have the failure pattern, use the smallest fix that matches the evidence.
- For group membership failures: create a new static device security group, add the Intune Provisioning Client as owner, assign it to the device preparation policy, then assign the same group to the required apps and scripts.
- For skipped apps: confirm the app is required for the device group, not just selected in the profile. Check applicability rules and architecture filters.
- For failed Win32 apps: test the install command under system context on the same Windows build. Then review detection rules. Device preparation will expose weak detection logic quickly because the app is evaluated during a tight setup window.
- For failed scripts: make scripts idempotent, short, and independent. Do not assume user profile paths, mapped drives, VPN, or post-desktop services exist during OOBE.
- For managed installer conflicts: decide whether the app truly must install during OOBE. If the known issue applies, move the payload to post-desktop installation or adjust the tenant design after risk review.
- For stale policy behavior: increment the policy deliberately, document the version, and retest with a clean device. Do not compare a failed device on policy version 4 with the current portal view of version 7.
A safe pilot profile usually has only the critical build blockers selected: security agent, VPN if needed before sign-in, Microsoft 365 Apps if required, and one validation script. Move nice-to-have tools to post-desktop installation until the profile is stable.
Limitations and Caveats
Device preparation improves speed and reporting, but it does not remove the need for disciplined assignment design. It also does not make every policy a tracked OOBE dependency. Microsoft’s overview states that policies assigned to the device group can sync, but device preparation does not track whether those policies applied during the deployment.
Be careful with these assumptions:
- A successful deployment does not prove every security policy applied before desktop.
- A skipped app does not always mean the package is broken.
- A failed script does not always mean PowerShell is broken.
- A group display name match does not prove you selected the same group object.
- A wipe is not remediation if the tenant-side assignment is wrong.
For production rollouts, keep separate groups for pilot, broad deployment, and break-glass testing. Do not reuse a heavily targeted desktop engineering group as the device preparation group. The cleaner the group, the easier it is to prove what happened during OOBE.
Bottom Line
When Windows Autopilot device preparation fails in Intune, troubleshoot from the tenant outward. Confirm Windows 11 eligibility, inspect the deployment report, check enrollment time grouping failures, validate that every selected app and script is assigned to the same device group, and review Microsoft’s known issues before touching the package.
The fastest fix is usually not a wipe. It is a corrected static group, a restored Intune Provisioning Client owner, a missing app assignment, or a simplified OOBE payload list. Once the group and assignments are clean, device preparation becomes much easier to operate at scale.