This blog is about the 60-minute delay that occurs before the required Win32 apps are installed after Autopilot. ESP blocking apps complete without issue, but once the user reaches the desktop, nothing else happens until exactly an hour later. We’ll break down why this delay occurs, what triggers it, and how this 60 minute delay can easily be bypassed.

Introduction

Every now and then, a thread pops up on Reddit or Discord: “My device enrolled fine with Autopilot, ESP installed all the blocking apps, user logged on… but then nothing. Nothing new, right? However, they then informed me that the required apps had suddenly started appearing after exactly one hour. That’s the moment my spider sense went off. (Just before heading over to Wp Ninjas)

We attempted to reproduce the same behavior and ensured that we documented all strings attached. During testing, it quickly became clear that Enrollment Status Page (ESP) itself wasn’t broken: all blocking apps configured in the ESP profile installed perfectly before the user’s desktop appeared. The problem only started afterwards. Once the user signed in, the remaining required apps didn’t appear until a full hour later. Which is way too long.

To understand why, we dug into the Intune Management Extension (IME) logs and decompiled code (again) until the picture made sense. And yes, it really does come down to a hardcoded 3600000 ms timer in the Win32 app poller.

But the real culprit is why that 60-minute timer starts in the first place.

Required Apps start installing when a reboot occurs during AP

Initially, we were unable to reproduce it. On all of our test devices, the required apps always appeared almost immediately after the user landed on the desktop. Later, we remembered that we still had some policies in place that we tested when writing the reboot-required Blog. One of the leftovers was a policy to configure Device Guard that fell under the RebootRequired URI. That meant the device always rebooted during Autopilot.

And that reboot masked the required apps issue. If the device restarts as part of ESP, the very first IME cycle after login finds the logged-on user properly (FirstSync / IsSyncDone), and required apps start immediately. No delay.

But if the device does NOT reboot during ESP (typical default setup without any reboot-required policy), you land at the desktop with your Entra ID user, configure Hello for Business, and… nothing happens. That’s when the 60-minute clock starts ticking.

The Available App check-in: The 60-minute Required Apps delay

The IME treats required and available apps as two separate sync passes, and believe me, that order matters:

  1. Available app check-in runs first.
  2. Only if that pass returns 0 (no blockers, valid user found) does the required app check-in kick in immediately.
  3. If the available check-in fails or exits early (no user yet, still on defaultuser0, ESP not out of User phase), IME sets a delay timer of 3600000 ms before it retries.

That’s precisely why you see required apps appear one hour later. The log literally shows:

[Win32App] Request required apps for user logon

AvailableAppRequest → exit → scheduling required app check-in for 3600000 ms

So, the problem isn’t that the required apps “don’t run.” It’s that they are gated by the available app logic, and if that doesn’t succeed on the first shot, you’re stuck waiting until the next scheduled run… which takes… yes, 3600000 ms to kick off.

The Required Apps log flow in plain English (or not)

Here’s what happens line by line when the delay hits:

  • User signs in, IME starts ApplicationPoller.DoWork().
  • EspHelper.CheckEspPhase() still thinks you’re in AccountSetup (or hasn’t set IsSyncDoneForUser correctly, as documented in this blog).
  • The available app check-in looks for a valid logged-in Entra SID. It often only sees defaultuser0 at this point.
  • Since the available pass doesn’t succeed, IME bails and schedules the next full check-in for +3600000 ms.
  • Required apps are skipped until then.

If you reboot (or restart IME) after logging in, the next pass sees the real user, EspPhase=NotInEsp, and available returns 0; required apps start installing immediately.

Why Microsoft Built in the 60-Minute Required Apps Delay

After having another *lovely conversation with MSFT, this was their answer

*(PS: I love those guys!!! … so yeah, lovely, that’s how I explain when I genuinely believe it was a great conversation…totally no sarcasm in play! )

Microsoft confirmed that payloads delivered through the Intune Management Extension are refreshed on a fixed schedule. That schedule depends on the type of payload. For Win32 apps, the check-in is hardcoded to 3,600,000 ms… exactly one hour. Microsoft also mentioned they’re working on accelerating delivery by making changes to those payloads trigger a notification for devices to check in immediately, but there’s no timeline yet.

In practice, this means the behavior we observed is not a bug. It’s by design. ESP blocking apps are installed immediately, but everything else waits until the next scheduled check-in, unless you trigger it earlier with a reboot, IME restart, or manual IME sync.

What fixes or bypasses it

When the IME lands in this state, there are four reliable ways out.

SkipUserStatusPage (short-circuits User ESP)

If you don’t need User ESP on these devices, set SkipUserStatusPage=1. This forces EspHelper.CheckEspPhase() to return NotInEsp immediately. The available pass succeeds instantly, so required apps start without waiting an hour.

This is also why kiosk devices stuck on “Waiting for install status” recover the moment you flip this bit, the IME stops trying to resolve a non-existent user. The behavior and OMA-URI path are covered in the Patch My PC write-ups on kiosk ESP and ESP phases.

Restart the IME

A device reboot or a manual restart of the Microsoft Intune Management Extension service clears the state and reruns the Win32 App poller. Now that the user session is fully live, the available app pass succeeds, and required apps kick in immediately. But restarting the IME… that feels a bit off.

Trigger an on-demand sync

Another method to bypass the 60 minute required app delay, is Running intunemanagementextension://syncapp ,this will call into the StatusService.CheckInAsync() method, which queues an immediate Available+Required sync. That run ignores the one-hour timer and installs required apps straight away.  

If you want to kick it off with PowerShell, here you go:

$Shell = New-Object -ComObject Shell.Application $Shell.open(“intunemanagementextension://syncapp”)

Force a reboot during Autopilot

The last way out is to assign a policy that falls under the RebootRequired URI so ESP enforces a restart before the desktop. That guarantees IME sees the correct user session on the first pass and avoids the 60-minute window altogether… But we all know that rebooting a device during Autopilot could break your Passwordless experience (TAP)

Mermaid flow of the logic

For those who prefer a flow over words….

Why this matters

On paper, the 60-minute timer makes sense, the IME assumes the user might not be ready and waits. In practice, it’s frustrating: the desktop looks ready, but required apps don’t appear until the hour mark. Once you trace the code and logs, the cause is clear: the available check-in runs too early. Skip User ESP, reboot, restart IME, or trigger a manual sync, and the required apps install right away.

Patch My PC cannot change that behavior, but once those apps are finally installed, we will always keep them up to date without effort. Book a demo to see how Patch My PC saves hours each week by taking third-party app management off your plate.