IntuneManagementExtension.log to establish check-in and policy flow, AppWorkload.log and AppActionProcessor.log for Win32 app processing, AgentExecutor.log for PowerShell execution, and the health logs when the agent itself is the suspect.Capture context before searching
Write down the device, user, UTC time window, application or script identifier, assignment intent, and the status shown in Intune. Without a narrow time window, a normal detection cycle can be mistaken for the failed attempt. Preserve the original logs before forcing another sync.
The default client location is:
C:\ProgramData\Microsoft\IntuneManagementExtension\LogsUse the log map
| Question | Primary log | Evidence to find |
|---|---|---|
| Did IME check in and receive work? | IntuneManagementExtension.log | Service startup, check-in, policy requests, processing cycle, reporting |
| Why did a Win32 app evaluate or act? | AppWorkload.log | Assignment, applicability, content and app workflow |
| What did detection or applicability decide? | AppActionProcessor.log | Detection results, requirement evaluation, intended action |
| What happened to an Intune PowerShell script? | AgentExecutor.log | Execution context, command launch, output and exit behavior |
| Is the extension unhealthy? | ClientHealth.log and ClientCertCheck.log | Agent health actions and certificate checks |
Follow one correlation through the cycle
- Locate the relevant check-in in the main IME log.
- Confirm that the intended policy or application is present in the received workload.
- Capture the app, policy, or script identifier used by the client—not only its portal display name.
- Move to the workload-specific log and search the same identifier and time window.
- Record requirement, detection, download, install or execution, post-detection, and reporting as separate stages.
This sequence prevents a common mistake: treating an installation exit code as the entire case when the app was never applicable, never downloaded, or was detected as already installed.
Interpret Win32 app results in order
For a Win32 application, test the chain in the same order the client needs it. First prove assignment and applicability. Then prove content acquisition. Next prove the installer launched in the expected context and returned a defined exit code. Finally prove the post-install detection rule agreed with the installer.
- Requirement failure: compare architecture, OS version, disk space, dependencies, and custom requirement scripts.
- Detection mismatch: test the rule in the same 32-bit or 64-bit and user or system context.
- Download issue: separate content retrieval from installation and record network/proxy context.
- Installer failure: preserve the installer’s own verbose log; IME can report an exit code without explaining the package internals.
- Reporting delay: compare local completion time with the next successful service check-in before redeploying.
Scripts need execution-context evidence
When a script succeeds interactively but fails through Intune, compare context before changing the script: system versus user, 32-bit versus 64-bit host, working directory, environment, network access, certificate store, and whether the script assumes an interactive profile. Capture standard output and error carefully; do not write secrets into logs.
Verify instead of repeatedly syncing
A manual sync can help reproduce a known condition, but repeated syncs add overlapping log cycles and may hide the original sequence. After a targeted correction, verify one clean cycle: assignment received, item evaluated, action completed, detection passed, and status reported.