Almost every hour I have lost to Intune was spent staring at a status column that was telling me the truth and not telling me anything. The admin center reports what happened. It does not report why, and it was never built to. The why is already written down, on the device, in files that exist whether or not anyone goes looking. This is about reading the portal as an index rather than a diagnosis, and about the one piece of plumbing that makes people think their tenant is broken when it is working exactly as designed.
The portal reports state, not cause
A device shows a configuration profile as Error. An app shows as Failed. A remediation shows as Not applicable. Each of those is a true statement about what the service currently believes, and none of them is a reason. The service knows the outcome the client reported. It does not know what the installer wrote to standard error, which detection rule returned false, or that the machine was asleep.
This is not a gap Microsoft has neglected to fill. It is the shape of the product. Intune is a policy service with a reporting surface attached. The agent on the device is where the work happens and where the reasons live, and the report is a summary of a summary that has crossed a network and a service boundary to reach you. Treating that summary as a diagnosis is the single most expensive habit in Intune operations, because it sends people to the portal to click Sync repeatedly, which is where the next section comes in.
There are two check-ins, and Sync only forces one of them
This is the fact that turns a ten minute investigation into a two day one, and almost nobody is told it in order.
A Windows device managed by Intune has two independent conversations with the service. The MDM channel carries configuration profiles, compliance policy and the settings catalog. The Intune Management Extension, which is a separate agent and a separate Windows service, carries Win32 apps, PowerShell scripts, remediations, custom compliance discovery scripts, Endpoint analytics and Remote Help. Two channels, two schedules, two sets of logs.
The Intune Management Extension checks for new and updated work every eight hours, and Microsoft documents that this check is independent of the MDM check-in. That is the number people are missing when they say a script has not run.
The Sync action in the Intune admin center, and the Sync button in the Windows Settings app, both start an MDM check-in. Neither of them forces an Intune Management Extension check-in.
Read that again with a support call in mind. An administrator assigns a PowerShell script, presses Sync in the portal, watches nothing happen, presses Sync again, escalates. Every one of those clicks did exactly what it promised and none of them touched the channel the script travels on. The device is not broken, the assignment is not broken, and the person is now writing a ticket about a product that is working.
Two things do force the extension to check in. Opening Company Portal on the device and choosing Settings then Sync starts an MDM check-in and an extension check-in together, which is why the answer that actually works is the one that sounds like a fob-off. Restarting the IntuneManagementExtension service does the same thing more bluntly, and it is the one to reach for when you are standing at the machine.
The operational consequence is not that anyone needs to memorise a table. It is that waiting is a legitimate diagnosis, and it is one you can only make if you know which of the two clocks you are watching. Eight hours of nothing on a script assignment is normal. Eight hours of nothing on a settings catalog profile is not.
What Failed means for an application, which is not what it sounds like
A Win32 app in Intune has an install command and a detection rule, and the status you see is overwhelmingly a report about the second one. The extension runs your installer, waits for it to exit, and then evaluates the detection rule you wrote. If the rule says the app is not there, the app is Failed, whatever the installer thought of itself.
So Failed covers at least four unrelated situations that want four different responses. The installer genuinely failed. The installer succeeded and the detection rule looks in the wrong place. The installer succeeded and the detection rule looks in the right place too early, before a reboot or a service start. Or the installer was never reached at all, because a requirement rule excluded the device and the report is describing a decision rather than an attempt.
You cannot tell those apart from the portal, and you can tell them apart in about ninety seconds from the device, because the extension writes down the installer exit code and the detection evaluation as separate lines. That asymmetry is the whole argument of this article.
One related trap belongs here because it produces a Failed that no amount of log reading explains. If a Win32 app is assigned to a user and the install needs privileges the signed-in standard user does not have, the install fails, and it fails for a reason that is a property of the assignment rather than of the package. Check who the assignment targets before you take the package apart.
The evidence already exists and nobody has to enable it
The extension keeps its logs on the device at C:\ProgramData\Microsoft\IntuneManagementExtension\Logs, and it has been keeping them since the day it installed itself. There is no diagnostic mode to turn on and no verbose flag to set. Eleven or so files sit there, each scoped to one job: the main check-in and policy log, a log for PowerShell execution, a log for Win32 app work, a log for the detection and applicability checks, a log for remediations, a log for the client health of the agent itself.
The build sheet that accompanies this article names them and says which failure sends you to which. What matters at the level of doctrine is that the default posture should be that the answer exists and you have not read it yet, rather than that the product is opaque. Intune is unusually good about this and unusually bad at telling anyone.
There is a corollary that saves real money. Because the evidence is written continuously and not on request, you can investigate a failure that has already finished. You do not need to reproduce it, catch it live, or ask a user to try again while you watch. That changes what you can promise a business: not “let me know next time it happens”, but “send me the machine name”.
Collecting diagnostics remotely, and the boundary around it
Intune has a remote action that pulls a large bundle of device logs to the service without interrupting the person using the machine. It is the right tool when the device is remote, when the user cannot be walked through anything, and when you do not yet know which log you want. It gathers far more than the extension’s own logs: setup and servicing logs, update logs, the MDM diagnostic cab, the Endpoint Privilege Management agent logs, the device inventory agent logs, and Configuration Manager client logs where those exist.
Four boundaries on it are worth carrying in your head, because each one has an operational consequence.
It is admin center only. Microsoft states plainly that diagnostics cannot be collected or downloaded by calling Microsoft Graph directly. If your instinct on reading the last section was to script this across a fleet, that instinct is wrong, and it is wrong in a way that will cost an afternoon before you find the sentence that says so.
It expires. A collection is stored for twenty eight days and then deleted, and each device holds at most ten collections at a time. Neither number is a problem until you are working a case that has been open for a month, at which point the evidence you gathered at the start is simply gone.
It needs the device to be reachable and the network to allow it. The upload goes to a regional Azure blob endpoint, and if that hostname is blocked the action fails in a way that looks like a device problem. A device that cannot receive the action within twenty four hours fails it.
It is a permission somebody has to hold. The action sits behind a specific remote task permission rather than falling out of general device read access, which is the correct design and the reason your service desk cannot use it on the day you decide they should.
Remote collection is for when you do not know what you are looking for. Reading one named log on the device is for when you do. Reaching for the first because the second feels manual is how a fifteen minute answer becomes a next-day answer.
The order of operations that actually holds
Establish which channel the thing you are chasing travels on, because that decides both the clock and the log. Establish whether enough time has passed on that channel to call it a failure at all. Then read the one log that owns the workload, and only then collect the bundle if the log does not settle it.
Almost nobody does it in that order. The common order is to sync, sync again, collect diagnostics, open a zip with forty files in it, and start reading whichever one has the most promising name. That order does eventually work, which is the problem, because it means the habit never gets corrected.
What this is really about
Every managed estate accumulates a folklore of things that are believed to fix Intune: sync twice, reboot, remove and re-add the assignment, delete the device and re-enrol it. Most of that folklore is people having eventually waited long enough while doing something unrelated, and then attributing the recovery to the something.
The cure is not more knowledge of Intune. It is a smaller and more boring commitment: before you change anything, find the line where the device wrote down what it did. It is nearly always there, it is nearly always specific, and it turns an argument about what might be wrong into a sentence about what is.
The companion build sheet turns this into a kit: which log owns which failure, how to force each of the two check-ins, how to run and download a remote collection and what is in the bundle, and an end-to-end test that proves your reading is right rather than plausible.
Build sheet: The Device Already Told You: Build Sheet
