Blog
Microsoft Intune Management Extension (IME): what it does and how to troubleshoot it
Learn what the Intune Management Extension does, how it runs on Cloud PCs and AVD, and how to fix stuck apps and IME errors.
Table of Contents
- What the Intune Management Extension is and why Intune needs it
- How the agent runs (service, check-in cadence, and execution context)
- The log files that answer common IME tickets
- A troubleshooting playbook for stuck apps and silent scripts
- How the IME behaves on Windows 365 Cloud PCs and Azure Virtual Desktop session hosts
- Where Nerdio Manager extends Intune on both cloud desktop paths
- What this means for your Cloud PC and session host baseline
- Frequently asked questions about Microsoft Intune Management Extension
A Win32 app can sit stuck at "Install pending" across forty session hosts for two days, while the Intune admin center offers no explanation.
For Windows Cloud environments (Microsoft's umbrella term for the Windows 365 and Azure Virtual Desktop portfolio), the useful evidence is on the device, in the logs of the Intune Management Extension (IME). The Windows agent that installs Win32 apps and runs PowerShell scripts. It also executes remediations on Microsoft Intune-managed endpoints.
This guide is for platform owners and end-user computing (EUC) engineers who need to understand and unstick the agent.
What the Intune Management Extension is and why Intune needs it
The Intune Management Extension is an installer agent that supplements the built-in Windows MDM channel. Native MDM uses the OMA-DM protocol, a declarative model where policies arrive as SyncML and a Configuration Service Provider applies them. That model handles settings well. Installing an EXE or executing a script is a task-based operation, and the original MDM channel supported only basic MSI deployments. The IME, sometimes called the "SideCar agent," closes that task-execution gap.
The agent installs itself. Assigning any of the following puts the IME on an enrolled device automatically:
- A Win32 app (.intunewin package)
- A PowerShell platform script
- A Microsoft Store app
- A custom compliance policy setting
- A remediation
Once present, IME-dependent workloads include Endpoint analytics, Remote Help, managed installer tagging, and Endpoint Privilege Management (EPM). Devices must be Microsoft Entra joined, registered, or hybrid joined, on Enterprise, Pro, or Education editions. The IME does not support Windows Home or S mode. Devices running IME versions below 1.58.103.0 stop receiving all IME-dependent workloads, with no obvious error signal.
Knowing what the agent owns is half the picture. Its timing and execution context explain many "nothing is happening" tickets.
How the agent runs (service, check-in cadence, and execution context)
The IME appears as IntuneManagementExtension under Services and installs at C:\ProgramData\Microsoft\IntuneManagementExtension.
It checks for new Win32 app assignments every hour, or whenever the service or device restarts. The IME retrieves Remediation scripts every 8 hours on a fixed schedule tied to service start (user sign-ins don't move it) and reruns them every 24 hours. The hourly Win32 app check-in cadence is why a freshly assigned app can legitimately take an hour to appear.
Execution context causes more failures than cadence. Win32 apps install as SYSTEM by default, so an installer that works fine interactively can fail silently when it expects user profile paths or tries to show UI. PowerShell scripts can run in system or user context, time out after 30 minutes, and always execute before Win32 apps.
The IME gives a failed script three retries across the next three check-ins; the IME tracks them in the registry under HKLM\SOFTWARE\Microsoft\IntuneManagementExtension\Policies.
On co-managed devices running both the Configuration Manager client and Intune enrollment, the split matters. PowerShell scripts run through the IME even when the Apps workload is set to Configuration Manager; Win32 apps deploy only after the Apps workload moves to Pilot Intune or Intune.
When behavior still doesn't match expectations, the agent writes everything it does to disk.
The log files that answer common IME tickets
The Logs folder captures every check-in and download, plus script execution, at C:\ProgramData\Microsoft\IntuneManagementExtension\Logs.
Microsoft recommends CMTrace.exe for reading them, and the line [Win32AppAsync] Starting app check in in the main log confirms a policy sync fired.
|
Log file |
What it tells you |
|
IntuneManagementExtension.log |
Check-ins, policy requests, processing, reporting |
|
AppWorkload.log |
Win32 app installs, applicability, detection |
|
AgentExecutor.log |
PowerShell script executions |
|
HealthScripts.log |
Remediations health and scheduled execution |
|
ClientHealth.log |
IME agent health |
|
NotificationInfra.log |
Real-time notification channel traffic |
You don't need to RDP into every machine. The Collect diagnostics action in the Intune admin center pulls the whole Logs folder remotely; for a failed Win32 app, the app's Installation details page can trigger the collection. At fleet scale, per-device log pulls become the last step, not the first step.
Nerdio Manager for Enterprise surfaces Intune device status reports across Cloud PCs and session hosts alongside physical devices, so admins can triage app and policy state before collecting logs device by device.
Common IME failures sort into a short playbook.
A troubleshooting playbook for stuck apps and silent scripts
The first move is restarting the IntuneManagementExtension service to force an immediate check-in. A device sync from the admin center does not restart the agent:
Restart-Service -Name IntuneManagementExtension -Force
After restarting the service, these failure patterns are the next checks:
- "Install pending" that never resolves
Install pending often traces to the policy payload never reaching the device (app GUIDs under HKLM\SOFTWARE\Microsoft\EnterpriseDesktopAPPManagement and in the Content\Incoming folder show whether the payload arrived), antivirus scanning the staging paths, or a line-of-business (LOB) MSI and a Win32 app installing simultaneously during Autopilot, which fails with "Another installation is in progress" (setup status page) because both use TrustedInstaller. - Antivirus interference (error 0x87D30067)
Microsoft requires antimalware exclusions on the IME Content folder and C:\Windows\IMECache. Teams should bake them into the golden image. - Error 0x87D1041C, "app not detected."
The installer ran without issue; Intune's detection rule couldn't confirm the result. The fix is correcting the detection rule (file path, registry key, or MSI product code), and if a script wraps msiexec, the wrapper should exit with the real return code so failures stop reporting as success. - Scripts silently not running
You can confirm the service is running, then read AgentExecutor.log. A known silent killer: script policy payloads that cross the 2 MB maxJsonLength limit produce no execution and no logs. - Forcing a failed app to retry
You can clear the Win32Apps and SideCarPolicies\StatusServiceReports registry keys, empty the Content\Incoming folder, and restart the service.
The troubleshooting flow above assumes a standard single-user endpoint. Virtual desktops bend some single-user endpoint assumptions, and multi-session bends them hardest.
How the IME behaves on Windows 365 Cloud PCs and Azure Virtual Desktop session hosts
Windows 365 Cloud PCs are single-session endpoints that Intune manages identically to physical desktops. Windows 365 supports app deployment for Win32, MSI packages. APPX and MSIX apps also deploy, and none of the multi-session restrictions below apply.
Azure Virtual Desktop personal VMs get the same treatment, and Intune service release 2601 (February 2026) adds EPM elevation policies for users on those single-session VMs.
Azure Virtual Desktop multi-session is a separate OS edition with its own rules:
- User-context remediation scripts execute for only one user session, typically the first user signed in. The reliable pattern is a SYSTEM-context script that registers a Task Scheduler task firing at each logon.
- Device-scoped configuration belongs on devices and user-scoped configuration belongs on users; mismatches report as Error or Not applicable. Compliance policies should target the device group.
- Intune can't manage session hosts joined to Microsoft Entra Domain Services at all, and cloning an already-enrolled image breaks enrollment because cloning replicates the identity token.
Designing multi-session workloads around device context from the start avoids the whole class of "works on the Cloud PC, fails on the host pool" tickets. Managing both desktop paths from one console lets admins review app policy, reporting, and host readiness together.
Where Nerdio Manager extends Intune on both cloud desktop paths
Many enterprises run Windows 365 and Azure Virtual Desktop side by side, which means two flavors of Intune-managed endpoints and one team responsible for both. Nerdio Manager manages Intune-enrolled Cloud PCs and Azure Virtual Desktop session hosts alongside physical devices from a single console.
Nerdio Manager applies the same application policies across Windows 365 Cloud PCs and Azure Virtual Desktop session hosts. It puts reporting and policy backup workflows in one console. Native Intune app delivery can take up to 3 hours, while Nerdio Manager's unified application management deploys applications to Cloud PCs in about 30 seconds. The same application policies apply to session hosts, and Nerdio Manager can hold new session hosts in drain mode until all required application installs complete, so new hosts stay out of rotation.
Nerdio Manager also extends Intune with policy backup and restore, including automatic backup whenever a policy is edited, and adds a restore path for deleted policies that native Intune does not provide. Admins can export Intune device status and review update compliance or antivirus posture from Nerdio Manager instead of checking each device in the Intune portal.
For Intune-assigned workloads, the IME still does the installing. Nerdio Manager gives admins a combined operational view for deciding which devices need log collection.
What this means for your Cloud PC and session host baseline
Back to the app stuck across forty session hosts. The diagnosis now starts with a service restart and follows the evidence in AppWorkload.log to the Incoming folder and the app's detection rule.
These hygiene practices prevent the next incident:
- Monitor IME version with a remediation script; anything below 1.58.103.0 has silently stopped receiving IME workloads.
- Build the antimalware exclusions, and for multi-session hosts the device-context-only design, into your golden image.
- Watch the network layer. IME traffic rides regional endpoints (macsidecar.manage.microsoft.com in North America, with Europe and Asia Pacific counterparts) on TCP 443, and Intune endpoints moved to Azure Front Door IP addresses on or shortly after December 2, 2025, so IP-based firewall allowlists may need updating.
With those checks covered, IME tickets become log-driven instead of guesswork. Surfacing policy and installation status across the estate reduces the number of devices that require IME log pulls.
Get a demo to see how Nerdio Manager works across both cloud desktop paths, or try it free in your Azure tenant.
Frequently asked questions about Microsoft Intune Management Extension
Resources
Learn more about Nerdio Manager
