By the end of this you can take a machine name and a symptom and produce a specific cause, without reproducing the failure and without asking the user to do anything. You will know which of the two check-ins governs the thing you are chasing, how to force that one rather than the other, which single log owns each class of failure, and when a remote collection is worth its twenty minutes and when it is the slow way round.
Prerequisites
Before step 1: a Windows device enrolled in Intune and corporate owned, since the remote collection action supports corporate-owned Windows rather than personal. Windows 11, or Windows 10 version 1909 or later, for the application diagnostic collection in step 6. An account holding Help Desk Operator, or a custom Intune role carrying the Remote tasks/Collect diagnostics permission together with permissions that give visibility of managed devices, such as Organization/Read and Managed devices/Read. Local administrator on the device for the log reading in steps 3 and 4, because the log directory is under ProgramData and the service restart in step 2 is a privileged operation. No licence beyond Intune is required for anything in this sheet.
Naming convention
You will be moving evidence off devices and into tickets, and unlabelled zip files are how two incidents become one confused incident. Name every artefact you extract DIAG-<devicename>-<yyyyMMdd-HHmm>-<ticket>, for example DIAG-LON-LT-0447-20260810-1432-INC0084216. The device name and the timestamp are the two things you cannot reconstruct later from the contents, and the collection itself is deleted from the service after twenty eight days, so the copy you named is eventually the only copy.
Step 1: Decide which channel owns the failure, before you touch anything
This is the verification gate for the whole sheet. Everything after it is cheap and reversible; getting this wrong is what makes people spend a day on the wrong clock.
| Setting | Value | Why |
|---|---|---|
| Workload is a configuration profile, settings catalog policy, compliance policy or certificate | MDM channel | Delivered over the MDM channel on its own schedule. Sync from the portal or the Settings app is the correct lever. |
| Workload is a Win32 app, PowerShell script, remediation, custom compliance discovery script, Endpoint analytics or Remote Help | Intune Management Extension | Delivered by a separate agent that checks in every eight hours, independently of MDM. Portal Sync does not move it. |
| Symptom is that nothing at all has happened and the assignment is recent | Not yet a failure | On the extension channel, up to eight hours of silence is the documented interval, not a fault. Record the assignment time before opening a ticket. |
| Symptom is a reported state such as Error or Failed | A failure, and it has a log line | The device reached a conclusion and wrote it down. Skip to step 3. |
Expected result: you can say out loud which of the two channels you are on. Failure mode to watch for: a workload that looks like configuration but travels on the extension, custom compliance being the one that catches people, because the policy is a compliance policy and the discovery script it depends on is not.
Step 2: Force the check-in you actually need
| Setting | Value | Why |
|---|---|---|
| Sync from the Intune admin center device page | MDM check-in only | Documented as starting an MDM check-in. It does not force an extension check-in, whatever the ticket says. |
| Sync from the Windows Settings app, under work or school account | MDM check-in only | Same channel as the portal action. Same limitation. |
| Company Portal, then Settings, then Sync | MDM and extension | The only user-runnable action that moves both channels. This is the one to give a remote user. |
| Restart the IntuneManagementExtension service | Extension check-in, immediately | The blunt instrument for when you are on the machine. The service restarts and checks in. |
From an elevated PowerShell session on the device:
Get-Service -Name IntuneManagementExtension | Select-Object Status, StartType, DisplayName
# Expected: Status Running, StartType Automatic,
# DisplayName "Microsoft Intune Management Extension"
# If Status is Stopped, that IS the answer for every extension-channel symptom
# on this device, and you can stop investigating the assignment.Restart-Service -Name IntuneManagementExtension
Start-Sleep -Seconds 30
Get-Content -Path "$env:ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log" -Tail 40
# Expected: fresh lines within the last minute showing the agent initialising
# and requesting policy.
# Failure mode: no new lines at all after a restart means the agent is not
# reaching the service. Treat that as a connectivity or proxy
# question, not a policy question.The gate before you restart: a service restart interrupts an install that is in flight. Read the tail of the log first. If the agent is mid-installation, wait for it rather than restarting into a half-applied package and spending the next hour on a problem you introduced.
Step 3: Read the one log that owns the failure
The extension writes to C:\ProgramData\Microsoft\IntuneManagementExtension\Logs. These are Configuration Manager style logs, so open them in CMTrace if you have it, which gives you the component column and follows the file as it is written. Notepad works and costs you the formatting.
| Setting | Value | Why |
|---|---|---|
| Agent will not check in, or nothing happens at all | IntuneManagementExtension.log | The main log. Agent check-in, policy request, policy processing and reporting. |
| A Win32 app is Failed, or installed but not reported | AppWorkload.log | The main app workload log: app check-ins, installs, applicability and detection. |
| Detection or requirement rules behaving unexpectedly | AppActionProcessor.log | Tracks detection and applicability check actions specifically. |
| A PowerShell script did not run, or ran and did nothing visible | AgentExecutor.log | Tracks PowerShell script execution deployed by Intune. |
| A remediation, custom compliance script or managed installer | HealthScripts.log | All workloads that use remediation scripts log here, including custom compliance. |
| The agent itself looks unhealthy | ClientHealth.log | Health of the extension rather than of any workload it carries. |
| Endpoint analytics data looks wrong or missing | Sensor.log | The Endpoint analytics collector, including boot performance and app reliability. |
| Device inventory or hardware readiness data missing | DeviceHealthMonitoring.log | Hardware readiness, device inventory and other collectors. |
| The log you want has already rolled over | The underscore-prefixed copy of the same name | The previous generation is kept alongside. If your incident is older than the current file, it is in there. |
Two things in that table are worth saying out loud because they cost time. App failures are two logs, not one: the workload log tells you what was attempted and what the installer returned, and the action processor log tells you what the detection rule concluded. And custom compliance is not in the compliance log, because the discovery script is a remediation-family workload.
$logs = "$env:ProgramData\Microsoft\IntuneManagementExtension\Logs"
# Every log that has been written in the last day, newest first.
Get-ChildItem -Path $logs -Filter *.log |
Where-Object { $_.LastWriteTime -gt (Get-Date).AddDays(-1) } |
Sort-Object LastWriteTime -Descending |
Select-Object Name, LastWriteTime, @{n='KB';e={[int]($_.Length/1KB)}}
# Expected: IntuneManagementExtension.log always present and recent on a
# healthy device, plus a workload log for whatever the device does.
# Failure mode: an empty result means the agent has not written anything for
# a day. That is a finding on its own, and it points at step 2.Worked example: the app that is installed and says Failed
The most common single ticket in an Intune estate. The portal shows a Win32 app as Failed on one device. The user says the application works. Both are telling the truth.
Take the app name into the workload log and read the installer result and the detection result as two separate facts:
$logs = "$env:ProgramData\Microsoft\IntuneManagementExtension\Logs"
Select-String -Path "$logs\AppWorkload.log" -Pattern 'ExitCode|Detection|applicationDetected' -Context 0,1 |
Select-Object -Last 40
# Expected: an installer exit code line, then a detection outcome line.
# applicationDetected: True with a non-zero exit code means the
# package installed something the rule can see and returned a code
# Intune treats as failure.
# applicationDetected: False with exit code 0 is the classic
# mismatch: the installer succeeded and the rule looks in the
# wrong place.
# Failure mode: no match at all usually means you have the wrong app name,
# not that nothing happened. Search for the package GUID instead.Now map what you found onto the fix, because these want opposite responses:
| Setting | Value | Why |
|---|---|---|
| Exit code 0, detection False | Fix the detection rule, not the package | The install worked. Your rule looks at a path, registry key or version that the installer does not produce. |
| Exit code 0, detection False, and the app appears after a reboot | Detection is running too early | Add the reboot behaviour the package actually needs rather than loosening the rule. |
| Exit code non-zero, detection False | Fix the package or its command line | A genuine install failure. The exit code is the vendor’s, so take it to the vendor’s documentation. |
| Exit code 1603 specifically | Look for context, not for a generic answer | A generic Windows Installer failure. It usually means permissions, a running process, or an install already in progress. |
| No install attempt in the log at all | A requirement rule excluded the device | The report describes a decision, not an attempt. Check requirement rules before touching anything else. |
One environmental cause belongs in this example because it produces failures that read as random. The extension stages content under a cache directory and runs installers from it, and Microsoft asks for antimalware exclusions on both that content directory and the cache. On x64 clients those are C:\Program Files (x86)\Microsoft Intune Management Extension\Content and C:\Windows\IMECache. If a security team has recently tightened scanning and app installs began failing intermittently across unrelated packages, check the exclusions before you take any single package apart.
The staged folder under the cache carries a generated name, a package identifier with a numeric suffix, so never write one into a script or a runbook. Match on the directory and let the name be whatever the agent derived.
Step 4: Collect diagnostics remotely, when the log did not settle it
Use this when the device is remote, when you do not yet know which log you want, or when you need an evidence bundle attached to a support case.
In the Microsoft Intune admin center, go to Devices, then All devices, select the device, and on the device overview find the row of action icons and select Collect diagnostics, then confirm. Watch progress under Monitor, then Device diagnostics. When the action completes, use the row’s overflow menu and select Download. The result arrives as a zip.
| Setting | Value | Why |
|---|---|---|
| Retention | 28 days, then deleted | Long enough for an incident, short enough that a long-running case loses its own early evidence. Export what you need. |
| Collections held per device | 10 at a time | An eleventh pushes out the oldest. On a device you are actively working, do not collect speculatively. |
| Bulk action scope | Up to 25 Windows devices at a time | The right tool for a fleet-wide symptom. Also the reason a bulk collection is not a substitute for a query. |
| Microsoft Graph | Not available for collect or download | Documented explicitly. Automating this is not an option you have missed, it is one that does not exist. |
| Automatic capture on Autopilot failure | One set per device per day | If enabled, provisioning failures collect themselves. Check here before asking anyone to reproduce an Autopilot failure. |
Failure mode to watch for: the upload leaves the device for a regional Azure blob endpoint, and if that hostname is blocked on your network the action fails while every other Intune function keeps working, which reads convincingly as a device fault. The endpoint differs by region, so read your tenant’s region from the documentation rather than copying a hostname out of a blog. A device that cannot receive the action within twenty four hours also fails it, so a laptop that is off is not a diagnostic finding.
Step 5: Know what is in the bundle before you open it
The collection is much wider than the extension’s own logs, which is what makes it useful and what makes it slow to read without a target. It includes the extension log directory, the Endpoint Privilege Management agent logs, the device inventory agent logs, the MDM diagnostic cab and its companion reports, Windows servicing and setup logs including the component based servicing log and the setup diagnosis results, Windows Update logs, and Configuration Manager client logs where the device is co-managed.
Several of those names are generated and must not be typed into a runbook. The MDM diagnostic cab carries a date and time in its filename, and the collector traces carry generated names. Match on the directory and the extension, never on a literal filename you saw once.
File provenance: what travels, from where, and what it is for on arrival
| Setting | Value | Why |
|---|---|---|
| The diagnostics zip | Device, to Intune, to your download tray | The evidence bundle. Rename it to the convention above on arrival, because its default name will not tell you which incident it belongs to. |
| Individual extension logs | Copied off the device by you, from the logs directory | What you take when you already know the workload. Faster than a collection and does not consume one of the ten slots. |
| Application diagnostic files | Device, to Intune, via the app installation details pane | Separate from the device collection and gathered per failed app. Only offered while the app is not installed successfully. |
| Nothing goes back to the device | No return path in this sheet | Everything here is read-only on the endpoint. If a fix follows, it is a policy change, not a file you carry back. |
Step 6: Application diagnostics, which are a different collection
When a Win32 app has failed, Intune can collect files you nominate from the device. Open the app’s Installation details for that device and select Collect diagnostics, then supply complete file paths. This is offered only while the app has not installed successfully, so it is a tool for the open failure rather than the post mortem.
| Setting | Value | Why |
|---|---|---|
| Path form | Complete paths, environment variables permitted | The documented variables include the program files, program data, public, windows and temp locations. A relative path is rejected. |
| Size and count ceiling | 250 MB or 25 files, whichever comes first | Nominate the vendor’s own installer log, not a directory of everything. |
| Time to collect | Roughly 15 to 20 minutes | Long enough that you should have read the workload log first, short enough to be worth starting before you do. |
| Platform floor | Windows 11, or Windows 10 1909 or later | Below that the option is not available and the absence is not a fault. |
One documented inconsistency, stated rather than resolved. Microsoft’s requirements section for this feature lists the permitted extensions as log, txt, dmp, cab, zip and xml, while the procedure section on the same subject also lists the two Windows event log extensions. Nominate an event log export only if you are prepared for it to be refused, and prefer converting it to text on the device where you control the outcome.
Step 7: The end-to-end test, both directions
A kit you have not tested is a set of paths you believe in. Prove both the working case and the blocked case on a device you control, before you need it on a device you do not.
The permitted direction. Assign a trivial PowerShell script to a test device, note the time, and do not touch the portal. Open Company Portal on the device, choose Settings, then Sync. Then:
$logs = "$env:ProgramData\Microsoft\IntuneManagementExtension\Logs"
Get-Item "$logs\AgentExecutor.log" | Select-Object Name, LastWriteTime
# Expected: LastWriteTime within a couple of minutes of the sync, and the
# script's own output visible in the tail of the file.
# This proves the extension channel end to end: assignment, check-in,
# execution, and a log line you can point at.The blocked direction, which is the half people skip. Assign a second script, and this time press Sync in the Intune admin center only. Wait ten minutes and run the same command.
Get-Item "$logs\AgentExecutor.log" | Select-Object Name, LastWriteTime
# Expected: LastWriteTime UNCHANGED. The portal sync moved the MDM channel
# and did not move this one.
# If it changed, something else triggered a check-in during your wait, most
# likely the eight hour interval landing. Re-run the test rather than
# concluding the documentation is wrong.That second test is the whole sheet in one observation. Once a team has seen the timestamp not move, nobody on it argues about sync again.
What breaks, and what does not
Nothing in this sheet changes policy, so nothing here can break a configuration. Three things are worth knowing anyway.
Restarting the extension service interrupts an installation in flight, which is why step 2 puts a read before the restart. Collecting diagnostics consumes one of ten slots on that device and pushes out the oldest when it is full, so speculative collection destroys older evidence. And the diagnostics contain user and device identifiers by design, so the bundle is subject to whatever handling rules your organisation applies to endpoint data, and Microsoft states that its own personnel may access device diagnostics when helping resolve incidents.
Consolidated build
One block to run on a device when a ticket arrives, before you have decided anything. It answers the channel question, the service question and the recency question in one pass.
$logs = "$env:ProgramData\Microsoft\IntuneManagementExtension\Logs"
"=== extension service ==="
Get-Service -Name IntuneManagementExtension |
Select-Object Status, StartType
"=== logs written in the last 24 hours ==="
Get-ChildItem -Path $logs -Filter *.log -ErrorAction SilentlyContinue |
Where-Object { $_.LastWriteTime -gt (Get-Date).AddDays(-1) } |
Sort-Object LastWriteTime -Descending |
Select-Object Name, LastWriteTime
"=== last 20 lines of the main log ==="
Get-Content -Path "$logs\IntuneManagementExtension.log" -Tail 20 -ErrorAction SilentlyContinue
# Expected on a healthy device: service Running, the main log written within
# the last eight hours, and recent lines showing a check-in.
# Failure mode: the logs directory missing entirely means the extension has
# never installed, which happens when nothing that requires it has
# ever been assigned. That is not a fault, and it is the answer.Ongoing review
Two things to re-check on a schedule rather than on an incident. Confirm the antimalware exclusions for the extension content and cache directories still exist after any endpoint security change, because that is a fleet-wide app failure that arrives without a deployment. And confirm your service desk still holds the remote task permission for diagnostics after any role change, because it is a narrow permission that a role tidy-up removes without anybody noticing until the next remote user.
Once the kit is in place the failures worth investigating change character. You stop asking whether Intune is working and start asking which of two channels is quiet and for how long, which is a question with an answer.
Doctrine: The Device Already Told You
