Autopilot ESP stuck at Apps (Identifying): find the Win32 that fails with 0x81036502

Most Autopilot pilots treat ESP Apps as a progress bar you wait out—or a timeout you raise when the screen sits on Identifying. That version is why Autopilot ESP stuck Apps Identifying becomes a permanent ticket queue: the page is not "thinking," it is waiting on a required Win32 that never finishes install-plus-detection.

Across tenants we assess after a "go live" Autopilot flip, the stall almost always collapses to three patterns—and they show up the same way in technician pre-provision and user-driven ESP.

Identifying forever usually means one tracked Win32 never clears

ESP Apps (Identifying) is the phase where Intune resolves which required apps apply and whether each one is already satisfied. If a tracked Win32's detection rule never returns "installed," ESP stays on Identifying even when the installer already ran. Techs see a frozen Apps screen; users call helpdesk; someone raises the ESP timeout and calls it fixed.

The first move is not another profile tweak. Open the device in Intune, pull the Enrollment Status Page / app installation evidence for that enrollment, and name the Win32 still sitting in Identifying or Failed. One bad required app blocks the whole Apps phase when that app is in the ESP tracking list.

What breaks it:

• Name the stuck Win32 from ESP evidence — stop treating "Identifying" as a generic Autopilot bug before you know which app is holding the phase.
• Match detection to what the installer actually leaves — file, MSI product code, or registry that exists on a clean lab build after a successful install.
• Keep required + tracked honest — if the app is on the ESP list, its detection has to pass offline before you put users on that profile.

0x81036502 is a failed tracked Win32, not an ESP timeout problem

When the tracked app does run and fails, Autopilot shops often surface 0x81036502 (or a sibling Win32 install failure) on the ESP Apps line. Raising the ESP timeout, removing the app from tracking "just for go-live," or flipping the device to a looser profile hides the packaging miss—it does not fix the next unit.

Walk the Win32 app's install command, return codes, and detection the same way you would for a ring deployment: does the content install under SYSTEM the way ESP runs it? Does a non-zero exit still map to success in Intune? Does detection fire only after a reboot you never allowed during ESP? The error on the ESP row is the pointer; the Win32 package is the work.

If Autopilot “go live” keeps turning into an ESP ticket queue—apps racing, Identifying forever, or 0x81036502 on a tracked Win32—start with our Windows Autopilot Managed path instead of another one-off profile tweak.

What breaks it:

• Reproduce the Win32 under SYSTEM outside ESP — same install command, same context Autopilot uses, on a clean image.
• Align detection with post-install state — if detection needs a reboot or a user hive, ESP will fail the app even when Setup.exe returned 0.
• Do not un-track to green the screen — untracked apps can install later; they do not teach you which package is broken.

Apps racing and serialized dependencies turn one miss into a fleet stall

ESP does not forgive "Company Portal will catch it." Required apps with soft dependencies, Store apps that need network the technician flow does not have yet, or Win32 packages that assume another product is already present will race—then serialize—until the slow or failed dependency owns the Apps phase. Same pattern when pre-provision sits on app installs: the profile looks fine; the app graph does not.

Order the graph on purpose. Put the dependency that must exist first in the ESP-tracked set with proven detection. Defer nice-to-have Line-of-Business apps until after ESP when they are not truly blocking. Separate technician pre-provision proof from the first user-driven wave so you are not debugging Identifying with a user at the keyboard.

What breaks it:

• Inventory ESP-tracked apps and draw the real dependency order before the next pilot wave.
• Prove pre-provision on a technician ESP path — same tracked set, no user present—before you call user-driven Autopilot ready.
• Leave non-blocking apps off the ESP required list so one slow package cannot park the whole enrollment.

What "good" looks like: the five-move baseline

If you do nothing else this quarter, these five moves dismantle the Identifying / 0x81036502 patterns above in order of impact:

1. Export the ESP-tracked Win32 list for the Autopilot profile actually assigned to the pilot group—not the profile you meant to assign.
2. Lab-install each tracked Win32 under SYSTEM and confirm detection returns installed without a user session.
3. Chase 0x81036502 (and siblings) in the Win32 package — command line, return codes, detection—before you touch ESP timeouts.
4. Order dependencies deliberately — blocking apps first with proven detection; defer the rest until after ESP.
5. Gate go-live on a clean technician pre-provision that clears Apps without Identifying forever, then allow user-driven ESP.

None of this needs a new Autopilot SKU. It needs an honest tracked-app list and packaging that survives the context ESP actually uses.

The uncomfortable question

The question worth asking is not "should we raise the ESP timeout again?"—it is "which required Win32 is still Identifying or returning 0x81036502 on the last three enrollments, and does its detection pass on a clean SYSTEM install before Autopilot ever runs?"

If you do not know, open the device's ESP / app installation status for the failed enrollment and the Win32 app's detection rules side by side—not the deployment profile summary that still says Ready.