Fix Required Apps Not Showing on ESP After Windows Autopilot Reset

If you run a Windows Autopilot Reset, expect the next user to land at the desktop with your normal device restrictions and management connection restored. What catches a lot of admins off guard is this: the required apps might not appear on the Enrollment Status Page (ESP), and they might not be installed before the user reaches the desktop.

Microsoft documents this as a known issue. The key point is not that app deployment is completely broken. The key point is that after an Autopilot Reset, ESP does not track those required apps the same way many admins expect during first-use enrollment. Microsoft says the apps aren’t tracked on the ESP, but they do install when the user signs in to the desktop.

That means this symptom often gets misdiagnosed as a broken Intune assignment, a bad ESP profile, or a failed Win32 app package when the real issue is the reset path itself.

Quick fix checklist

Use this checklist before you start rebuilding app assignments or rewrapping Win32 packages:

1. Confirm the device went through Windows Autopilot Reset, not a fresh Autopilot enrollment or full wipe.
2. Confirm the visible symptom: the required apps are not shown on ESP and the user reaches the desktop sooner than expected.
3. Sign in to the device and give Intune time to continue post-desktop app delivery.
4. Force a management sync from Settings > Accounts > Access work or school > Info > Sync or from the Intune admin center.
5. Check whether the apps install after sign-in. Microsoft says this known issue still allows that behavior.
6. Verify the apps are still assigned as Required to the correct device or user groups.
7. Review the ESP profile and confirm Block device use until all apps and profiles are installed is configured the way you expect.
8. Collect Autopilot and MDM diagnostics from one affected device before making broader changes.
9. If your handoff process requires apps to be present before the user reaches the desktop, do not treat Autopilot Reset as equivalent to a clean Autopilot provisioning pass.

What Microsoft is actually saying

On the current Windows Autopilot known issues page, Microsoft describes the issue in plain language:

Required apps aren't shown on the Enrollment Status Page (ESP) after a Windows Autopilot Reset

When a Windows Autopilot Reset happens, the required apps aren't installed on the Enrollment Status Page (ESP) before the user reaches the desktop. The apps aren't tracked on the ESP, but the apps are installed when the user signs in to the desktop.

That wording matters because it narrows the problem:

• this is tied to Windows Autopilot Reset
• the issue is about ESP tracking and timing
• Microsoft does not say required app assignment is lost
• Microsoft does not say the apps will never install
• Microsoft says the apps can still install after desktop sign-in

So if your team is seeing the desktop earlier than expected after reset, that is not enough evidence to declare the app deployment broken.

Why admins mistake this for an app failure

Microsoft’s Intune ESP documentation says you can configure ESP to block device use until all required policies and applications are installed. It also says ESP uses the EnrollmentStatusTracking CSP and FirstSyncStatus CSP to track app installation.

That is the normal mental model most Intune admins carry into troubleshooting:

• required apps are targeted
• ESP is configured to block use
• the user should stay on ESP until those apps complete

But Microsoft separately documents that Windows Autopilot Reset works a little differently. In the reset documentation, Microsoft says Autopilot Reset:

• maintains the device’s connection to Microsoft Entra ID
• maintains the device’s management connection to Intune
• blocks access until the device state is restored and an MDM sync completes

That is not the same promise as “every required app will be tracked on ESP before desktop.” The known-issue entry fills in the gap. After Autopilot Reset, the device can satisfy the reset workflow and still let the user reach the desktop before the required apps are surfaced through ESP.

This is why the symptom is confusing in real environments. Everything looks close enough to normal that help desk teams start blaming app packaging, detection rules, or a bad assignment filter.

Root cause and scope

The safest way to explain this issue is the Microsoft way:

• ESP behavior after Autopilot Reset is not the same as ESP behavior during a clean Autopilot first-run provisioning flow.
• Required apps might not be tracked on ESP during the reset experience.
• The apps can still install after the user signs in to the desktop.

The scope matters:

This is most likely the known issue when

• the same app assignments work on newly enrolled devices
• the same ESP profile works in regular Autopilot provisioning
• the symptom appears specifically after Autopilot Reset
• users reach the desktop early, but the apps start arriving later
• Intune still shows the device as managed and able to sync

This is probably not only the known issue when

• apps never install even long after sign-in
• app assignments were changed recently
• only one package fails while others succeed
• detection rules are failing
• the device has broader MDM enrollment or sync problems
• the device is hybrid joined and you are mixing this with unsupported reset assumptions

In other words, Autopilot Reset explains early desktop access with missing ESP-tracked apps. It does not explain every app delivery failure that happens to occur after a reset.

Logs and where to check

1. Confirm the device really went through the reset path

This article only applies if the device used Windows Autopilot Reset. Microsoft documents two reset scenarios:

• local reset started on the device
• remote reset started from an MDM service such as Intune

If the device was actually wiped, reprovisioned, or re-enrolled another way, you may be chasing the wrong branch.

2. Review the Autopilot event log

Microsoft’s Autopilot troubleshooting FAQ says to review:

Application and Services Logs > Microsoft > Windows > ModernDeployment-Diagnostics-Provider > Autopilot

Pull recent events with PowerShell:

Get-WinEvent -LogName 'Microsoft-Windows-ModernDeployment-Diagnostics-Provider/Autopilot' -MaxEvents 200 |
  Select-Object TimeCreated, Id, LevelDisplayName, Message |
  Format-List

You are looking less for a single magic event ID here and more for timeline proof:

• reset occurred
• Autopilot resumed normally
• the user reached desktop
• there is no stronger evidence that ESP itself hard-failed

3. Check Intune and MDM state after sign-in

Because Microsoft says the apps can install when the user signs in to the desktop, your next check is whether the device is still syncing and receiving policy.

Useful checks on the device:

dsregcmd /status

Get-ScheduledTask | Where-Object { $_.TaskName -like '*PushLaunch*' -or $_.TaskName -like '*EnterpriseMgmt*' } |
  Select-Object TaskName, State, TaskPath

Then confirm the device can still sync from Access work or school. If sync is dead, you have a second problem beyond the Microsoft-known ESP behavior.

4. Confirm the app assignment model

Check the app assignment in Intune before touching packaging:

• is the app still Required?
• is it assigned to the intended device or user group?
• did an assignment filter change recently?
• is there a dependency or supersedence relationship delaying what users expect to see?

The known issue is easy to over-apply. If one app is genuinely misassigned, Autopilot Reset will not fix that.

5. Use the diagnostics page when available

Microsoft’s FAQ says the Windows Autopilot diagnostics page can be enabled through ESP and opened with:

CTRL + SHIFT + D

That gives you a cleaner way to prove whether you are looking at an ESP-tracking expectation mismatch or a deeper provisioning failure.

Practical remediation workflow

Step 1: Prove the pattern on one affected device

Pick one device and document the sequence:

1. trigger or review the Autopilot Reset
2. watch the device return to OOBE
3. note whether ESP skips required apps
4. sign in
5. force a sync
6. verify whether the required apps begin installing afterward

If the apps install after sign-in, you are squarely in the Microsoft-known-issue branch.

Step 2: Separate “late install” from “never installs”

This is the decision point that saves the most time.

If apps install after the user reaches the desktop, your problem is mostly handoff timing and operator expectation.

If apps do not install after sign-in and sync, your problem is no longer just the known issue. Move into normal Intune app troubleshooting for:

• detection rules
• install command lines
• requirement rules
• delivery optimization or network issues
• dependencies and supersedence
• assignment targeting

Step 3: Adjust the field workflow

If your service desk resets and reissues devices the same day, update the runbook.

Practical changes that help:

• budget time for post-sign-in sync and install after Autopilot Reset
• do not promise that a reset device will behave like a freshly pre-provisioned device
• if a device must be fully app-ready before handoff, validate that requirement in a non-reset provisioning workflow first
• add a tech validation step at the desktop for the small set of apps that matter most

That last point matters. This known issue is as much a process problem as it is a platform quirk.

Step 4: Re-test the apps that really matter

For high-impact required apps such as VPN clients, security agents, line-of-business launchers, or remote support tools, test them explicitly after reset:

Get-Service | Where-Object { $_.Status -eq 'Running' } | Sort-Object DisplayName

Get-ItemProperty HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*, HKLM:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\* |
  Select-Object DisplayName, DisplayVersion, Publisher |
  Sort-Object DisplayName

Swap these checks for your real app validation commands where possible.

What not to do first

When this specific symptom appears, avoid these common bad moves:

• rebuilding all your Win32 app packages before proving the issue is reset-specific
• rewriting detection rules because the apps were not visible on ESP
• assuming ESP policy is broken tenant-wide from one reset test
• telling deskside teams the device is ready the moment the desktop appears
• treating Autopilot Reset as a full substitute for fresh Autopilot provisioning in every handoff workflow

Those moves create more work and often hide the actual Microsoft-known behavior.

Caveats

A few limits matter here.

First, this known issue is about required apps not being shown on ESP after Autopilot Reset. It is not a blanket explanation for all slow or failed app installs.

Second, Microsoft’s wording says the apps install when the user signs in to the desktop. That does not guarantee every app will finish instantly. Large Win32 apps, dependent apps, and network-sensitive installers can still take time.

Third, if your workflow depends on proving app readiness before the first user session, Autopilot Reset is the wrong place to assume ESP will enforce that state exactly the way a fresh deployment does.

Prevention

To keep this from turning into a repeat ticket storm:

• document Autopilot Reset as its own operational path
• train support teams that desktop reached does not always mean all required apps finished
• define a short post-reset validation checklist for your must-have apps
• keep one pilot device for testing reset behavior after major Intune app changes
• separate ESP timing issues from real app install failures in your incident notes

Bottom line

If required apps are not shown on ESP after Windows Autopilot Reset, do not assume your Intune app delivery is dead.

Microsoft already documents the real behavior: the apps are not tracked on ESP in this reset scenario, but they can still install after the user signs in to the desktop. Prove that pattern on one device, force a sync, verify the post-sign-in install behavior, and adjust your handoff workflow so your team stops treating a reset device like a brand-new Autopilot build.