Intune Management Extension logs
Overview
The Intune Management Extension (IME) logs are the device-side record of everything that happens during Win32 app and PowerShell-script processing. They show whether a device received policy, evaluated requirements, checked detection, ran the install command, captured the exit code, and reported the result back to Intune. When the admin center says “Failed” or “Not installed” but does not say why, these logs are where the real answer lives.
This guide explains where the logs are stored, which file to open for a given symptom, how to read a deployment by its timeline, and the common evidence-to-action mapping you will use most. It also makes the point that logs are a diagnostic step, not the first step: confirm assignment, requirements, and command syntax first, then use the logs to confirm what actually executed on the device.
Where are the Intune Management Extension logs stored?
On every Windows device that has been targeted with a Win32 app or a PowerShell script, the Intune Management Extension writes its logs to a fixed local folder. The IME service (“Microsoft Intune Management Extension”) is installed automatically the first time one of those policies is assigned, so the folder appears only after the agent has been provisioned.
C:\ProgramData\Microsoft\IntuneManagementExtension\LogsThese files use the SCCM-style log format, so the right tool matters. Open them with CMTrace (or OneTrace), which handles live updates, long lines, and timestamp sorting. Plain Notepad works for a quick glance but makes timeline troubleshooting painful.
Which IME log file should you open first?
Do not read the whole folder top to bottom. Pick the starting log from the symptom, then follow the timeline to a more specific file if the trail points there. For most Win32 app failures, AppWorkload.log is the right entry point because it carries the per-app processing detail; IntuneManagementExtension.log is the right entry point when you suspect the device is not receiving policy at all.
| Symptom | Open this log first | Why |
|---|---|---|
| A Win32 app install or uninstall failed | AppWorkload.log | Per-app applicability, detection, command execution, exit code, and state transitions. |
| Device may not be checking in or getting policy | IntuneManagementExtension.log | Main agent log for check-ins, policy requests, processing, and reporting. |
| A PowerShell script or script-based action failed | AgentExecutor.log | Captures script execution, parameters, and the returned exit code. |
| The IME service or client itself looks unhealthy | ClientHealth.log | Confirms whether the IME client passed its own health evaluation. |
How does the IME decide when to process apps?
Understanding the cadence stops you from misreading “nothing happened.” The IME checks for new Win32 app and PowerShell-script policy roughly once per hour, and also right after a device restart or when the service restarts. This is separate from the general Windows MDM device check-in, which runs on a variable schedule (commonly around every eight hours, and more frequently just after enrollment). So a brand-new assignment may sit until the next IME cycle even though the MDM channel has already synced.
- Wait for the cycle: a Required app typically appears in the log within the next IME pass after assignment.
- Force a check-in: on the device go to Settings > Accounts > Access work or school > Info > Sync, or use the Company Portal, to trigger an immediate IME check.
- Restart effect: rebooting the device also prompts the IME to re-evaluate assigned policy.
How do you read a deployment by its timeline?
The most reliable approach is to anchor on the exact time of the attempt (you can get this from the admin center) and read the sequence forward. The IME processes a Win32 app in a fixed order, and each stage leaves a marker you can search for.
A key detail many admins miss: requirement rules are evaluated before detection and before the install command runs. If a device is not applicable (wrong OS architecture, below the minimum OS, failing disk or memory checks, or failing a custom requirement), you will never see an install attempt in the log at all. That is a “not applicable” outcome, not a failure. Detection then runs before install so the IME can skip an app that is already present, and again after install to confirm success. Comparing the before and after detection lines is the single fastest way to tell whether the installer succeeded but the detection rule is wrong.
What does a healthy AppWorkload entry look like?
Search AppWorkload.log by the app ID, the command text, a return code, or the timestamp of the attempt. A clean install produces a recognizable sequence: applicable, not detected, command runs, exit code 0, detected, reported as installed.
App workload policy received
Applicability: Applicable
Detection before install: NotDetected
Install command: msiexec /i "<product>.msi" /qn
Process exit code: 0
Detection after install: Detected
Reporting state: InstalledWhen you reach the exit-code line, remember the default return-code mapping: 0 and 1707 are success, 3010 is a soft reboot (success, reboot required), 1641 is a hard reboot initiated by the installer, and 1618 means retry. Any other code defaults to Failed unless you mapped it on the app. A log showing exit code 3010 reported as a failure usually means the code simply was not added to the return-code table.
Turning log evidence into the next action
Use the log to decide one targeted change rather than editing several app settings at once. The table below maps the most common evidence to the next thing to verify.
| Log evidence | What to check next |
|---|---|
| No app processing appears for the app | Confirm the assignment, force a sync, verify device/user targeting, and wait for the next IME cycle. |
| Applicability is false / not applicable | Review requirement rules: OS architecture, minimum OS, disk space, memory, and any custom file/registry/script requirement. |
| Detection is already true before install | Expected when the app is present; the IME will skip the install. Check the detection rule if this is wrong. |
| Command starts but the process fails | Validate silent switches, install behavior (System vs User context), and dependencies. See common reasons apps fail. |
| Exit code reported as failed unexpectedly | Map the code on the app (for example 3010 as soft reboot) so it is not treated as a failure. |
| Install succeeds but detection fails after | Fix the detection rule: file path, MSI product code, registry value, or custom script logic. |
How do you collect the logs from a device?
When troubleshooting remotely, capture the whole Logs folder before repeated retries overwrite or shift the timeline. Compress it and attach it to your ticket or support case so the full sequence is preserved.
Compress-Archive -Path "C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\*" -DestinationPath "$env:TEMP\IME-Logs.zip" -ForceYou can also collect IME diagnostics remotely from the Intune admin center using the device’s Collect diagnostics action, which gathers these logs without touching the machine directly.
Quick checklist
- Record the exact time of the deployment attempt before opening any log.
- Start with AppWorkload.log for Win32 app failures, IntuneManagementExtension.log for policy and check-in issues.
- Read the timeline in order: policy, requirements, detection-before, execution, exit code, detection-after, report.
- Compare detection-before and detection-after lines to separate an install failure from a detection-rule problem.
- Check the return-code mapping (0, 1707, 3010, 1641, 1618) before editing the install command.
- Collect the Logs folder before forcing repeated retries.
Leave a feedback
Include versions, steps, and any error text if you have them.