Reference

IME log reference

Based on the article: Reading Intune Management Extension logs: IME, AppWorkload and AgentExecutor explained · 4 min read

When a Win32 app, platform script or remediation misbehaves on Windows, the admin center usually tells you that it failed. The Intune Management Extension (IME) logs tell you why. In this deep dive I'll map out the log folder, explain what each file records, and show a repeatable way to read them, on the device or from a remote diagnostics collection.

How it works

The IME is the Intune agent for work the built-in Windows MDM client can't do on its own. Intune installs it automatically when you assign something that needs it, including Win32 apps, Microsoft Store apps, PowerShell platform scripts, Remediations and custom compliance discovery scripts. It runs as the IntuneManagementExtension service and checks in with Intune every 8 hours, independently of the MDM check-in. It also looks for new app assignments as soon as the Enrollment Status Page or Autopilot device preparation finishes.

Everything it does is logged to C:\ProgramData\Microsoft\IntuneManagementExtension\Logs. ProgramData is hidden by default, so type the path into File Explorer.

Note: Configuration profiles and LOB MSI apps are delivered by the Windows MDM client, not the IME, so you won't find them here. For those, use the DeviceManagement-Enterprise-Diagnostics-Provider event log or the advanced diagnostic report under Settings › Accounts › Access work or school.

What each log records

Log	What it records	Open it when
`IntuneManagementExtension.log`	The main log: check-ins, policy requests, policy processing and reporting	Nothing reaches the device, or you need proof a check-in happened
`AppWorkload.log`	Win32 app deployment activity: download, install and detection	A Win32 app fails, hangs or reports the wrong state
`AppActionProcessor.log`	Detection and applicability checks for assigned apps	An app is never attempted or shows as not applicable
`AgentExecutor.log`	Execution of PowerShell scripts deployed by Intune	A script returns an unexpected exit code or output
`HealthScripts.log`	Remediations that run on a schedule	A remediation didn't run when you expected
`ClientHealth.log`	Health checks of the IME agent itself	The agent seems stuck or isn't checking in

You'll also find ClientCertCheck.log (device client certificate checks), DeviceHealthMonitoring.log, NotificationInfra.log, Sensor.log (Endpoint analytics data collection) and Win32AppInventory.log (app inventory). They're rarely the first stop for deployment problems.

Step-by-step: reading the logs

1. Use a proper viewer

The IME writes in the same format as Configuration Manager, so CMTrace is the natural choice. The Configuration Manager client installs it as C:\Windows\CCM\CMTrace.exe, and it ships in SMSSETUP\Tools on the site server. On Intune-only devices, copy it over or open the logs from your workstation. Three features earn their keep:

Merge selected files in the Open dialog interleaves IntuneManagementExtension.log and AppWorkload.log into one timeline.
Highlight and Filter on the Tools menu isolate the lines for one app or script.
Error Lookup translates a numeric error code into its message.

Support Center OneTrace works in a similar way. For a quick live view with no extra tools, PowerShell is enough:

powershell

Get-Content -Path "$env:ProgramData\Microsoft\IntuneManagementExtension\Logs\AppWorkload.log" -Tail 40 -Wait

2. Find the right lines

Apps, scripts and remediations appear in the logs by their ID. Open the object in the admin center, copy the GUID from the browser address bar, and search for it. Once you're in the right area, these terms help:

The app or script name, if the GUID gives you too many hits.
error, fail and exception for the obvious failures.
exit code to see what an installer or script returned.
detection and applicability for "why wasn't it installed" questions. Win32 app lines in AppWorkload.log are tagged [Win32App].
download for content problems.

Exact message wording changes between IME releases, so GUIDs and timestamps are better anchors than memorized strings.

3. Trigger a fresh check-in

Rather than waiting up to eight hours, start a check-in and watch the logs. Settings › Sync in Company Portal, Sync in the Windows Settings app, or the Sync device action in the admin center all trigger both an MDM and an IME check-in. Restarting the service from an elevated prompt does the same for the IME:

powershell

Restart-Service -Name IntuneManagementExtension

4. Collect the logs remotely

For corporate-owned Windows devices, go to Devices › All devices, open the device, select Collect diagnostics and confirm with Collect data. Track progress under Monitor › Device diagnostics in the device's menu, then use Download when it completes. The zip contains the whole IME Logs folder, plus registry exports such as HKLM\SOFTWARE\Microsoft\IntuneManagementExtension and command output like dsregcmd /status. Worth knowing:

The device must be online, and you need the Help Desk Operator or School Administrator role, or a custom role with Remote tasks › Collect diagnostics.
Collections are kept for 28 days, up to 10 per device, and the action also runs in bulk on up to 25 devices.
The feature is on by default and can be turned off under Tenant administration › Device diagnostics.

Verify: what good looks like

After a sync, IntuneManagementExtension.log shows new check-in and policy activity with current timestamps.
For a healthy Win32 app, AppWorkload.log shows the download, the install command, the installer's exit code, and a detection result saying the app is present.
For a script, AgentExecutor.log shows the run and the exit code you expected.
The status in the admin center catches up once the IME has reported back.

Tips and gotchas

When a log fills up, the IME starts a new file and keeps the old one with a date stamp in its name. Check those too if the event you need is older.
Devices need IME version 1.58.103.0 or later to keep receiving Win32 apps, scripts and remediations. If nothing arrives, check the agent version early.
Install commands that call powershell.exe run in 32-bit PowerShell, which explains many "but it worked when I ran it" puzzles.
No IME on a device usually means nothing that needs it is assigned, the device can't reach Intune, or Windows is in S mode.