Intune Management Extension: Why Your Win32 App Is Stuck at "Processing"

A required Win32 app has said "Processing" for four days straight on a batch of laptops. Device compliance is green, the device shows up fine in Intune, the assignment is correct, and the same package installed cleanly on every other machine in the same group ten minutes after it was pushed. Nobody's touched the device. Nothing in the Intune admin center gives you a reason — just a spinning status that never resolves into either success or a failure code you could actually search for.

This is almost never an Intune problem. It's a problem with a small, easy-to-forget Windows service running locally on the device called the Intune Management Extension — the agent that actually does the work of installing Win32 apps, running PowerShell and Proactive Remediation scripts, and evaluating custom compliance scripts. If you've never had a reason to look at it before, this is the post that explains what it is, how it lands on a device in the first place, and the one failure mode that causes almost every "stuck processing" ticket you'll ever get.

The problem — "Processing" that never becomes "Installed" or "Failed"

The symptom is always some version of the same thing: in Intune admin center > Apps > Windows > [app name] > Device install status, a device sits at Processing (Install) indefinitely. It doesn't move to Installed. It doesn't move to Failed with a code you can look up in the app installation error reference. It just sits there, sometimes for hours, sometimes for days, while every other targeted device in the same assignment finishes normally.

The Intune console genuinely doesn't know why, because from the cloud service's point of view, nothing has gone wrong yet — it delivered the policy, and it's still waiting for the device to check in and report a result. The actual problem, and the actual evidence of what's wrong, lives entirely on the device. That's the part most admins skip straight past, because the instinct is to go looking in the Intune portal for an answer the portal was never going to have.

Why it happens — the Intune Management Extension is a separate agent that has to be running

Modern MDM in Windows is built on a set of built-in configuration service providers (CSPs) — small OS components that know how to apply specific settings pushed down over MDM. CSPs are great for structured configuration: Wi-Fi profiles, certificate deployment, most compliance settings, most restrictions. What CSPs were never designed to do is run an arbitrary installer with custom command-line switches, execute a PowerShell script and capture its output, or run a discovery script and interpret a JSON result.

To cover that gap, Microsoft ships a separate client-side agent called the Intune Management Extension (IME). Per Microsoft's own description, it's "an installer agent that enhances Windows device management. It supplements the standard Windows MDM feature by enabling advanced device management capabilities." In plain terms: it's the thing that actually runs the .exe or .msi for a Win32 app, invokes powershell.exe for your scripts, and reports the result back up to Intune — because the native MDM stack in Windows simply has no CSP that can do any of that on its own.

According to Microsoft's documentation, the IME installs automatically — once prerequisites are met — the moment any of the following is assigned to a user or device:

• A PowerShell script
• A Win32 app
• A Microsoft Store app
• A custom compliance policy discovery script
• A Proactive Remediation (remediation script)
• Windows Endpoint analytics, Remote Help, Managed Installers, or BIOS update via MDM policy

The prerequisites themselves are worth knowing, because "prerequisites not met" is a real reason the agent never shows up on a device in the first place: the device must be on a supported Windows version (not S mode, not Windows Home), it must be Microsoft Entra joined, Entra hybrid joined, or Entra registered, and it must actually be enrolled in Intune. On co-managed devices, the Apps workload has to be set to Pilot Intune or Intune for Win32 apps to trigger the agent — though PowerShell scripts will still run even if the Apps workload stays on Configuration Manager.

Here's the mechanic that trips people up most: the IME does not check in with Intune on the same schedule as the regular MDM sync. Per Microsoft, "the IME checks for new or updated installations with Intune services every 8 hours. This check-in process is independent of the MDM check-in." That means forcing a device sync from the Intune admin center's Devices blade — the "Sync" button every admin reaches for first — triggers an MDM check-in, but it does not force the IME to check in. If the IME's own cycle hasn't come around yet, a Win32 app assignment can sit waiting on the device for hours even though the device itself is online, healthy, and syncing fine.

The other common root cause is the underlying IntuneManagementExtension Windows service simply not running — stopped, crashed, or stuck in a state where it isn't actively polling. If the service isn't up, nothing gets processed no matter how many times Intune re-delivers the policy from the cloud side. Less commonly, a script assigned to run detection or install logic can itself misbehave badly enough — hanging, waiting on user input that never arrives, producing far more console output than the agent is designed to capture and relay back — that the IME's own processing of that one payload stalls, which can make everything behind it in the queue look stuck too.

It's worth being precise about the limits of what's confirmed in Microsoft's own documentation here rather than repeating numbers that get passed around forum threads as fact. Microsoft's public IME article doesn't publish an exact script execution timeout or a hard output-size ceiling in kilobytes — what it does document clearly is the check-in cadence (every 8 hours, independent of MDM sync) and the conditions that cause the agent to remove and reinstall itself. If a script genuinely never returns control to the agent, or floods standard output far beyond what a status-reporting payload is meant to carry, the practical effect you'll see is the same regardless of the exact internal ceiling: that one item stops progressing, and anything queued behind it in the same processing cycle looks stuck along with it. Treat "the script itself is hanging or over-verbose" as a hypothesis to rule in or out from the logs, not a number to test against.

How to verify — check the agent's actual state on the device, not the portal

All three of the likely causes — service not running, IME check-in timing, or a runaway script — leave evidence on the device, in one specific location: C:\ProgramData\Microsoft\IntuneManagementExtension\Logs. This is where you actually diagnose the problem, not the Intune admin center.

Microsoft's own documentation lists the individual log files and what each one is for — this is the part worth bookmarking, because guessing which log to open wastes more time than the actual troubleshooting:

Open these with CMTrace.exe rather than Notepad — it colour-codes errors and follows the file live, which matters because these logs get written to continuously while the agent is actually working through a queue.

Microsoft also ships a self-help diagnostic for exactly this scenario. From the Microsoft 365 admin center, go to Help & support, describe the issue (something like "user's app deployment isn't completing"), enter the affected user's email, and run the Intune app deployment diagnostic. It can't make changes to your tenant, but it will surface known configuration issues automatically — worth running before you go device-hunting, since it takes under a minute.

The fix — restart the agent, force the right kind of sync, and clear stuck scripts

Once you've confirmed which of the three causes you're looking at, the fix is usually fast. Work through these in order.

If the cause turns out to be a specific script or app hanging rather than the service itself, the fix is different — you're not restarting the agent, you're removing the thing that's stalling it. Delete the device's record for that specific app or script under the app's Device install status, confirm the device isn't still targeted by a broken script assignment, and republish a corrected script or detection rule before reassigning. A script that never exits — waiting on user interaction that will never come on an unattended device, or producing an unbounded amount of console output — needs to be fixed at the source; restarting the IME service repeatedly on the device will not resolve a genuinely broken script, it'll just retry the same failure.

Proof it worked — confirm the local agent state before trusting the portal again

The reliable way to prove the fix landed is the same place you diagnosed it: the device, not the portal. Confirm the service is running, confirm the logs are being written to recently, and confirm AppWorkload.log shows the app moving through its states rather than sitting idle. The companion script below automates exactly that check — service status, log recency, and a scan of AppWorkload.log and AgentExecutor.log for pending or failed activity — so you get a single read-only snapshot instead of opening four log files by hand every time this comes up.

If you need a second opinion beyond what's on the device, Intune's Collect diagnostics device action pulls the entire IME log folder (%ProgramData%\Microsoft\IntuneManagementExtension\Logs\*.*) plus the HKLM\SOFTWARE\Microsoft\IntuneManagementExtension registry key straight from the device into a downloadable zip, without interrupting the user — useful when you can't get remote access to the box directly but can still trigger a cloud action against it.

References

• Understand Microsoft Intune Management Extension — Microsoft Learn
• Troubleshooting app installation issues with Intune — Microsoft Learn
• Device action: Collect diagnostics — Microsoft Learn
• Use PowerShell scripts on Windows devices in Intune — Microsoft Learn
• Network endpoints for Microsoft Intune — Microsoft Learn