The Intune management extension is not something you install. It arrives on its own, triggered by a specific list of assignments, and it removes itself under conditions that are equally specific. That asymmetry is why the agent turns out to be absent on exactly the devices where you first go looking for it, and why the missing log folder is a symptom rather than a fault. Here is the documented trigger list, the check-in interval that is longer than most guides claim, a log by log map, and the failure modes the reference page does not describe.
Rule out the channel underneath the agent before you diagnose the agent. A device that is not checking in at all produces symptoms identical to a broken extension, and the two need different fixes. Work the Intune device not syncing diagnosis order first, then come back once you are certain the device is genuinely reaching the service.
One disclosure. My tenant is a lab with no enrolled devices, so I have not run any of this against a production estate. What follows is documented behaviour, verified against Microsoft Learn on 19 August 2026, plus the places I would expect it to bite.
What actually installs the Intune management extension
There is no installer to deploy and no switch in the admin centre. The agent is installed automatically when one of a fixed set of payloads is assigned to the user or the device, and if none of them is targeted, the agent is correctly absent. Microsoft’s Intune management extension reference lists the triggers.
| Assignment that triggers the install | Notes |
|---|---|
| PowerShell scripts | The original trigger, and still the most common one |
| Win32 apps | Includes anything packaged as .intunewin |
| Microsoft Store apps | The new Store app type, not the retired Business Store |
| Custom compliance policy settings | The discovery script is executed by the agent |
| Remediations | Listed on the reference page under the older name, proactive remediations |
| Endpoint analytics | Data collection rides on the agent |
| Remote Help | Assignment alone is enough |
| Managed Installers | Used for app control scenarios |
| Update Windows BIOS using a configuration MDM policy | Firmware update payloads |
The prerequisites are stricter than the trigger list. The device needs a supported Windows version, excluding Home editions and anything running in S mode. It has to be Microsoft Entra joined, Microsoft Entra hybrid joined, or Microsoft Entra registered, and enrolled in Intune by Group Policy, by manual enrolment with automatic enrolment turned on, or as a co-managed device. It needs network access through whatever proxy sits in front of it. And the agent itself has to be version 1.58.103.0 or later, which it reaches on its own because it self-updates.
The removal conditions are the part almost nobody reads. The agent is removed when PowerShell scripts are no longer assigned, when the device is no longer managed, or when the extension has been in an irrecoverable state for more than 24 hours of device-awake time. That last clause is measured in awake time, not wall clock, so a laptop that spends most of its week shut takes considerably longer than a day to trip it.
Where it logs, file by file
Everything the agent does lands in C:\ProgramData\Microsoft\IntuneManagementExtension\Logs. Seven files matter, and picking the wrong one is the most common reason an admin concludes there is nothing in the logs.
| File | What it holds |
|---|---|
| IntuneManagementExtension.log | Agent check-in, policy request, policy processing and reporting |
| AppWorkload.log | App check-ins, installs, applicability and detection. Where most Win32 answers actually are |
| AgentExecutor.log | PowerShell script execution detail |
| HealthScripts.log | Remediation script execution detail |
| AppActionProcessor.log | Detection and applicability checks |
| ClientHealth.log | Agent client health activity |
| _IntuneManagementExtension.log | The rolled-over copy of the main log. Check it when the window you care about has already scrolled |
If the folder does not exist, that is not a logging problem. It means the agent was never installed on that device, which sends you back to the trigger table rather than into a log parser.
Two paths need excluding from antimalware scanning on x64 clients: C:\Program Files (x86)\Microsoft Intune Management Extension\Content and C:\windows\IMECache. On x86 clients the first path drops the (x86). Content downloads that stall at zero bytes are worth checking against this before anything else.
# No service means no eligible assignment ever reached this device.
Get-Service -Name IntuneManagementExtension -ErrorAction SilentlyContinue |
Select-Object Status, StartType
# Newest log first. An old timestamp on every file is the real finding.
Get-ChildItem "C:\ProgramData\Microsoft\IntuneManagementExtension\Logs" -File |
Sort-Object LastWriteTime -Descending |
Select-Object Name, LastWriteTime, Length
The check-in interval, and why eight hours matters
The agent checks in every 8 hours, and that cycle is independent of the MDM check-in. This is the single fact most third-party guides get wrong, usually by quoting an hourly figure borrowed from the MDM channel.
The consequence is practical. Pressing Sync in Company Portal or in the admin centre moves the MDM channel. It does not guarantee that the extension has re-evaluated anything, so a script or Win32 app can sit apparently untouched while every sync you trigger reports success. If you are chasing that gap, the mechanics are in forcing an Intune sync and the problems that look like sync failures.
Restarting the IntuneManagementExtension service is the blunt instrument most admins reach for here. It is not documented as a supported sync trigger and I have not run it against a production estate, so treat it as folklore that is widely relied on rather than as a supported procedure.
Script behaviour that surprises people
The PowerShell scripts documentation sets limits that are easy to breach without noticing.
- Scripts do not run at every sign-in. A script runs when it is assigned, and again only if the script or the policy changes. Editing the file and re-uploading it counts as a change. Reassigning the same unchanged script does not.
- A failure gets three retries, spread across the next three consecutive check-ins. At an 8 hour cycle those three attempts occupy roughly a day of device-awake time, and once they are exhausted the script does not try again by itself.
- 200 KB is the ceiling, in ASCII. Large scripts with embedded content hit this sooner than expected.
- 30 minutes is the execution timeout. Anything that waits on a user, a reboot or a slow download needs to be a Win32 app instead.
- Workplace joined devices can only be targeted by device security groups. User targeting is ignored on those devices, which is a silent no-op rather than an error.
- A device clock that is out by months or years stops scripts running at all. Rare, but it explains the device that is otherwise perfectly healthy.
The signature setting is worth reading rather than accepting. Enforce script signature check requires the script to be signed by a trusted publisher when it is set to Yes, and skips that requirement when set to No, which is a different question from the device’s own PowerShell execution policy.
The failure modes
These are the ones that cost time, in the order I would check them.
- Agent missing, nothing wrong. No PowerShell script, Win32 app or other trigger has ever been assigned. Assign a trivial script to the device group and the agent appears on its own schedule.
- Agent vanished after a cleanup. Someone unassigned the last PowerShell script. That is a documented removal condition, not a bug, and it takes the log history with it.
- The logs are there and nothing recent is in them. Compare file timestamps before you read content. Uniformly old timestamps point at enrolment or connectivity, not at the payload you are investigating.
- Proxy configured for the user only. The documentation is explicit that a user-level proxy with no machine-wide equivalent needs a signed-in user, and suggests
bitsadmin /util /setieproxyas the alternative. Kiosks and freshly provisioned devices sitting at the login screen are the population that breaks. - Reading IntuneManagementExtension.log for a Win32 problem. App applicability, detection and install detail live in AppWorkload.log. The main log will happily show a healthy check-in while the app never becomes applicable.
- Retries silently exhausted. Three failures and the script is finished. Nothing in the admin centre announces that the agent has stopped trying, so a report that has not changed in two days may not mean anything is still happening.
For anything Win32-specific beyond this, Microsoft’s troubleshoot Win32 apps guidance carries the full log table and the antimalware exclusion paths.
What I would do differently
I would stop treating the extension as a component to be repaired. It is a delivery outcome. Almost every case that presents as a broken agent is really an assignment that was never made, a device that is not enrolled the way someone assumed, or a retry budget that quietly ran out. Checking those three before opening a log would save most of the time this topic consumes.
I would also fix the mental model about sync. Two independent channels with different intervals means the reassuring word Success in the admin centre answers a question you did not ask. When the answer matters, read the timestamp on the agent’s own log rather than the status in the portal, because only one of those two is evidence that the Intune management extension did anything.
And I would assign a deliberate no-op script to a broad device group in any tenant that expects to use Win32 apps later. It guarantees the agent and its log folder exist before the day you urgently need both, which is a cheaper position than discovering the trigger list during an incident. When that day comes, the agent is rarely the thing at fault: most of what goes wrong is in the detection rule rather than the installer, which is the subject of what actually breaks in Intune Win32 app deployment. Where several policies are involved and the outcome still looks wrong, the separate question of which Intune policy actually wins a conflict is worth ruling out first, and the same log discipline applies to Intune remediation scripts, which this agent also executes. None of it transfers to the Mac estate: the extension is a Windows agent, which is why custom compliance scripts on macOS fail in an entirely separate set of ways.
Last verified: 19 August 2026.
