The GRS 24-hour lock: why Intune won't retry your failed Win32 app

After three failed install attempts, the Intune Management Extension locks a Win32 app behind its Global Retry Schedule for 24 hours — and no portal edit or device sync will unstick it. Here is what GRS actually does, and the safe way to force a retry today.

The problem

A Win32 app deployment fails on a device. You spot the mistake — a wrong install switch, a detection rule pointing at the wrong path, a broken .intunewin — and fix it in the Intune admin centre. You sync the device. Nothing happens. You sync again, restart the device, even upload a corrected package. The app stays Failed, and the Intune Management Extension (IME) log shows the app being skipped rather than retried.

That is the Global Retry Schedule (GRS) at work. Once a Win32 app has failed three times, IME locks it out for 24 hours, and there is no button anywhere in the admin centre to force a retry of a required Win32 app before the lock expires.

It bites hardest in three situations:

• Packaging and testing. You are iterating on a new app against a test device. One bad build burns that device for a day unless you reset the state.
• Autopilot builds. A required app fails during provisioning; the machine finishes (or fails) enrolment with the app missing, and re-syncing will not bring it down until GRS expires.
• Helpdesk fixes. A user's install failed for a transient reason — disk space, a locked file, a dropped VPN. The cause is gone, but the device still refuses to retry.

Why it happens

Win32 apps are not delivered by the core Windows MDM stack but by the Intune Management Extension, an agent running as a Windows service on the device. When IME processes a required Win32 app and the install fails — the installer returns a non-success exit code, or detection fails afterwards — IME retries the install: three attempts, roughly five minutes apart.

After the third failure, IME records the failure in its Global Retry Schedule: registry state under HKLM\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps. Under a key named for the targeted user's object GUID (all zeros — 00000000-0000-0000-0000-000000000000 — for device-context assignments) sits a subkey named for the app's GUID holding its last processing state, plus a GRS subkey containing hashed entries stamped with the time of the failure.

From that point on, IME's regular check-ins (roughly hourly) consult GRS before doing anything with the app. If fewer than 24 hours have passed since the recorded failure, the app is skipped outright: no content download, no re-read of the install command, no re-evaluation of detection rules. You can watch this happening in C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\AppWorkload*.log, where the app is logged as held by GRS rather than reprocessed. Once the 24 hours elapse, the next check-in retries the app — and if it fails again, the lock re-arms.

This is why portal-side fixes appear to do nothing:

• GRS state lives on the device, keyed by the app's GUID. Editing the app in the portal — new package, new detection rule, new command line — changes the app definition but never touches the device-side lock.
• Restarting the IME service alone does not help: the service re-reads the same GRS registry state and keeps skipping the app.
• There is no force-retry action for a required Win32 app in the admin centre.

The behaviour is deliberate — it stops a broken installer hammering devices and content delivery every hour — but Microsoft provides no supported way to clear it early.

The fix

Option 1 — reset the device-side state (single device)

1. Get the app's GUID: open the app in the Intune admin centre and copy the GUID from the browser URL.
2. On the device, under HKLM\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps\<userGUID>, delete the subkey(s) whose names begin with the app GUID.
3. Delete the matching GRS entry under <userGUID>\GRS. The GRS subkeys are hashes, not app GUIDs; find the right one by searching the newest AppWorkload*.log for the app GUID near the failure entries. On a test device it is common to simply delete every subkey under GRS — the only effect is that all previously failed apps become eligible to retry.
4. Restart the Microsoft Intune Management Extension service (IntuneManagementExtension).
5. Sync the device (Settings → Accounts → Access work or school → Info → Sync), or wait for the next check-in. IME re-evaluates the app against its current portal definition — including whatever you fixed.

As a script, run elevated (the last registry line is the blunt clear-all-GRS variant; swap it for the specific hash key if you need to be surgical):

$appId = '<your app GUID>'

$root = 'HKLM:\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps'

Get-ChildItem $root -Recurse | Where-Object { $_.PSChildName -like "$appId*" } | Remove-Item -Recurse -Force

Get-ChildItem $root | Get-ChildItem | Where-Object { $_.PSChildName -eq 'GRS' } | Remove-Item -Recurse -Force

Restart-Service -Name IntuneManagementExtension

Note this deletes only IME's local bookkeeping — nothing is uninstalled. IME re-runs detection for any app whose state was cleared at its next processing cycle.

Option 2 — an on-demand remediation (no interactive access)

If you cannot, or would rather not, log on to the device, wrap the same cleanup in an Intune Remediations script package and trigger it from the device page with Run remediation (requires an eligible Windows/Intune licence). The script runs as SYSTEM, clears the app's state and GRS entries, restarts the service, and the device retries at its next check-in. This is the cleanest answer at fleet scale.

Option 3 — sidestep GRS entirely

• New app object. GRS is keyed on the app GUID, so uploading the fixed package as a brand-new app and assigning it gets processed immediately. It works, but you accumulate duplicate app objects and assignment churn — better as a one-off emergency move than routine practice.
• Re-provision the device. A wipe or fresh Autopilot build starts with a clean registry, so no previous GRS state applies. Sensible for lab VMs, drastic for anything else.

One caution: the registry surgery is unsupported by Microsoft. It is widely used and low-risk, but it belongs in a tested, parameterised script — not ad-hoc regedit sessions on production devices.

How Decolla handles it

GRS is behaviour baked into Microsoft's Intune Management Extension. Decolla does not — and cannot — change how the agent retries; no product can remove the 24-hour lock itself. What Decolla does is turn the recovery into a tested, deliberate step instead of a manual regedit session.

Decolla provisions Windows devices over your own Intune/Autopilot tenant, and its Library of pre-built, industry-tested policies, scripts and fixes includes exactly this scenario: a Win32 retry-reset script that clears a failed app's IME state and GRS entries and restarts the agent — the same pattern described above, packaged and tested rather than typed by hand mid-build.

As with everything Decolla deploys, the item appears in the written, itemised plan before anything runs, with its delivery method and reversibility class stated per item, and Decolla can roll back its own changes item by item. So a bad Win32 app costs you a retry cycle, not a day of the build.

Decolla is pre-launch. You can join the waitlist at decolla.app.

Sources

• Call4Cloud (Rudy Ooms) — retrying a failed Win32 app installation: GRS deep dive
• Patch Tuesday — the Win32 app retry interval and Global Retry Schedule
• Anoop C Nair (HTMD) — override GRS and trigger IME to retry failed Win32 apps
• MSNugget — retry failed Win32 apps on demand with Intune Remediations