Intune Management Extension Keeps Uninstalling: Causes & Fixes
If you manage a Windows estate with Microsoft Intune, you’ve probably hit this one: the Intune Management Extension (IME) installs, runs for a while, then quietly removes itself. You check Event Viewer and find a clean MsiInstaller event — Event ID 1034, removal success status 0 — and a matching 11724 saying the product was removed. Nothing crashed. Nothing failed. Windows Installer was explicitly told to uninstall the agent, and it did.
That’s the behaviour throwing people off. IME isn’t falling over. Something asked it to leave.
This post walks through why that happens, the handful of root causes you’ll encounter in the real world, and a diagnostic path that gets you to the answer without rebuilding the device.
IME is an on-demand agent, not a permanent one
The first thing to internalise: IME is not Configuration Manager’s client. It isn’t meant to sit on a device forever regardless of workload. It’s a just-in-time agent that Intune deploys when there’s work it alone can do — specifically, Win32 app installs, PowerShell scripts, remediations, and a few related features. When Intune determines the device no longer needs IME, it can pull it back off.
That detail alone resolves a surprising number of “IME keeps uninstalling” tickets. If nothing is targeted at the device or its primary user that requires IME, the MDM channel is doing exactly what it’s designed to do.
With that framing, here are the causes worth investigating, ordered roughly by how often they’re the culprit.
1. Nothing is assigned that requires IME
IME is installed when a Win32 app, PowerShell script, proactive remediation, or similar workload is assigned to the user or the device. If none of those assignments apply — or they briefly applied during testing and were removed — IME has no reason to stay resident.
The fix most shops land on is a “keep-alive” assignment: a required Win32 app or PowerShell script targeted at the device group that guarantees IME always has at least one piece of work. A no-op detection script or a small utility your helpdesk actually wants on every machine both work. The point is simply to give IME a reason to stick around.
2. User-targeted assignments on a device with no primary user
This is the sneaky one. If every app and script you’ve deployed is user-targeted, and the device doesn’t have a primary user resolved yet, IME installs, evaluates its assignment list, finds nothing applicable, and removes itself.
This shows up most often on:
- Freshly reset or reimaged machines that haven’t had a user sign in yet
- Autopilot pre-provisioned (“white glove”) devices during the technician phase
- Shared devices or kiosks
- Hybrid-joined devices where the primary user hasn’t synced through
Switching at least one assignment — even just your keep-alive — to a device group fixes the class of problem cleanly. Device-targeted assignments don’t wait on a primary user to be resolved.
3. Enrollment state has drifted
The device looks fine in the Intune admin center, but the MDM channel on the client is broken or stale. This is more common than it should be, especially on hybrid-joined machines that have been through a domain rejoin or certificate renewal.
Run this on the client:
dsregcmd /status
You’re looking for:
AzureAdJoined : YES(orDomainJoined : YESplusAzureAdJoined : YESfor hybrid)MdmUrlpopulated with your tenant’s endpoint- A valid device certificate under
DeviceAuthStatus
If MdmUrl is empty but the device still shows as compliant in Intune, you have a stale record. Re-enrollment won’t stick until the stale device object is removed from Intune and Entra ID, the local MDM enrollment is cleaned up (dsregcmd /leave on Azure-AD-joined devices, or the scheduled task under Microsoft\Windows\EnterpriseMgmt\{GUID} removed), and the device is re-enrolled.
4. An uninstall assignment is reaching the device
Check group membership against every app that has an Uninstall assignment. It’s rare, but a misconfigured dynamic group or a nested group can pull a device into an uninstall scope for something that takes IME with it. Remediation scripts that run as SYSTEM and call msiexec /x against IME’s product code fall in the same category — review any custom scripts you’ve deployed.
5. Third-party security software
Some endpoint protection products have at various points flagged IME’s MSI or its child processes. Check the AV console’s quarantine and exclusion logs for the window around the uninstall. Microsoft Defender with aggressive ASR rules can also interfere, though this is usually blocking rather than uninstalling. If you find AV involvement, add the IME install path (C:\Program Files (x86)\Microsoft Intune Management Extension\) and the IntuneManagementExtension.exe process to your exclusion policy.
6. Co-management workload conflicts
If the device is co-managed with Configuration Manager, the workload sliders determine which authority owns what. If Apps is still on ConfigMgr, Win32 app deployments via Intune won’t land — which loops back to cause #1, because IME won’t have an assignment that requires it.
Diagnostic path
When a device is misbehaving, this is the order I work through:
Start with Event Viewer under Application, filtered to MsiInstaller. Event 11724 with Microsoft Intune Management Extension tells you it was an explicit uninstall. Note the timestamp.
Then open the agent log:
C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log
Read with CMTrace or the free Intune Log Analyzer from Microsoft’s Support Center tool — plain Notepad won’t cut it on a log this chatty. Search for the uninstall timestamp and work backward. You’re looking for entries mentioning no assignments, agent cleanup, or a policy refresh that removed the last workload.
At the same time, pull dsregcmd /status output and confirm enrollment health. If MDM enrollment is gone, nothing in Intune will work until it’s fixed, and you’re chasing the wrong problem.
Finally, in the admin center, pull up the device and list every assignment actually targeting it or its primary user. Filter out “Available” assignments — those don’t keep IME resident on their own. You want at least one Required Win32 app, PowerShell script, or proactive remediation in the list. If there isn’t one, you’ve found your root cause.
The short version
IME is on-demand. It stays when it has work and leaves when it doesn’t. Ninety percent of “it keeps uninstalling itself” reports trace back to either (a) no qualifying assignment targeting the device, or (b) assignments that only apply to a user who hasn’t been resolved yet. Fix the assignment model, verify enrollment health with dsregcmd, and the agent stops ghosting you.
The remaining ten percent is usually AV, stale enrollment records, or someone’s custom remediation script. The logs will tell you which — as long as you know what you’re looking for.
