Packaging knowledge
Reading Intune logs: where the package fails
From the Management Extension log to the installer log: which file shows which step and how to narrow down the cause.
Three logs, three levels
On a Windows client three logs matter. The Intune Management Extension log shows whether the package was downloaded and started. The vendor installer log shows what the installer did. The package log from the PSADT run shows what the shell did before and after.
Read only one and you see one third.
The path of a package
The path is always the same: assignment, download, execution, detection, completion. Each step can fail. A package that “does not arrive” usually never started; a package that “fails” usually started and returned a code.
That difference decides which log you open.
Detection failure vs install failure
A detection failure looks like an install failure in the portal: the device is not compliant, the package is retried. The log then shows “not detected”, not an install error. Confuse the two and you hunt for a problem in the installer that actually lives in detection.
Reading timestamps correctly
Logs are chronological but not synchronised. Download starts before install, detection runs after, completion can be minutes later. Comparing times across logs requires the same time zone — otherwise you create phantom errors.
What you change afterwards
After analysis there are exactly four fixes: correct the parameters, correct detection, handle the return code, or rebuild the package. Everything else is symptom work. If the same cause shows up in three packages, it is not a package bug but a missing standard.
---
The actual files
On the client, Intune logs live under C:\ProgramData\Microsoft\IntuneManagementExtension\Logs. That folder contains the main extension log, the workload log for app execution and the action processor log. Which file holds the decisive line depends on where the package stopped.
A sensible order: first check whether a download or start is recorded. If not, assignment is the topic, not the installer. If yes, continue in the installer log.
One failure, three questions
Before changing a line, answer three questions: was the package started, with which command, and which code did it return? Only then do you know whether parameters, detection or return code handling are the problem.
Skip that order and you change three things at once, then cannot tell which one helped.
When a package is “done”
A package is done when it has been installed, uninstalled and installed again on a clean device, returning the same code every time. A single successful run proves little — it may depend on a leftover state only that device has.