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 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.

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.

Required apps only start installing after the interval timer 3600000 / 60 minutes expired

But the real culprit is why that 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 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.

screenshot showing the rebootrequireduri that caused autopilot to reboot

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, and required apps start immediately. No delay.

Required apps will kick if after the device rebooted or the ime restarted

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.

win32apptimerinterval of 3600000 ms / 60 minutes which caused the required apps to not start installing after the autopilot enrollment

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:

the interval timer 3600000 ms will be set and with it the Required apps only start installing after 60 minutes

[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).
  • 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 login, the next pass sees the real user, EspPhase=NotInEsp, available returns 0, and required apps start installing right away.

the app workload log shows it detected a valid user and is showing it is not in the esp

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 lovely conversation)

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 right away, but everything else waits until the next scheduled check-in. unless you trigger it earlier with a reboot, IME restart, or manual 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 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

If you can, 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.

Mermaid flow of the logic

For those who prefer a flow over words….

the mermaid flow of how the required apps will get a delay of 60 minutes after the device is enrolled and dit not rebooted

Why this matters

On paper, the 60-minute timer makes sense. IME assumes “maybe the user isn’t ready yet” and waits. But in practice it just creates frustration: users are at the desktop, everything looks fine, but their required apps don’t show until exactly one hour later.

The behavior isn’t a mystery once you follow the code and logs — it’s simply a case of the available check-in running too early. Whether you fix it by skipping User ESP, forcing a reboot, restarting IME, or manually syncing, the outcome is the same: get the available pass to return 0, and required apps will start right away.