How to Detect and Remediate a Missing Intune Management Extension with PowerShell
Build a safe PowerShell detection and remediation pair that finds devices where the Intune Management Extension is missing or unhealthy and repairs what can be repaired locally.
C
CloudEngineerHub Team
Published: September 14, 2026· Last Updated: September 28, 2026·10 min read
The Intune Management Extension (IME) is the workhorse agent behind Win32 app deployment,
proactive remediations, and custom device scripts on Windows. When it is missing or broken on
a device, nothing you assign from the Intune admin center that depends on the IME will run:
Win32 apps sit in "waiting for install status", remediation scripts never execute, and the
device quietly falls behind its compliance baseline. Because the IME installs itself only
when Intune first targets the device with a Win32 app or a required system script, a missing
agent is usually the symptom of an enrollment or assignment problem, and a broken agent is
usually the aftermath of a corrupted upgrade, image capture mistake, or an over-aggressive
cleanup script.
Visual Walkthrough
The engine behind every “Detect with PowerShell” runbook on this site.
C
CloudEngineerHub Team
Author
The CloudEngineerHub editorial team — Microsoft endpoint management and cloud engineers writing hands-on guides on Intune, Azure, Entra ID, Autopilot, Defender and PowerShell. Every article is reviewed against current Microsoft documentation.
Exit 1 flips the device into the remediation queue for this package.
remediate
3
Remediation executes
Fix script runs silently as SYSTEM with a 5-minute budget.
verify
4
Re-run detection
The same detection script must now exit 0 — proof, not hope.
telemetry
5
Results report
Per-device outcome lands in Reports → Remediations for trend analysis.
6
Repeat on schedule
The loop continues — drift gets caught the day it appears.
Continuous cycle
Proactive Remediations — The Detect → Fix → Verify Loop. 1. Detection script runs: Scheduled (daily/hourly): exit 0 healthy, exit 1 unhealthy — nothing more. — 2. Verdict: unhealthy: Exit 1 flips the device into the remediation queue for this package. — 3. Remediation executes: Fix script runs silently as SYSTEM with a 5-minute budget. — 4. Re-run detection: The same detection script must now exit 0 — proof, not hope. — 5. Results report: Per-device outcome lands in Reports → Remediations for trend analysis. — 6. Repeat on schedule: The loop continues — drift gets caught the day it appears.
This article gives you a paired detection and remediation script set that you can deploy
through Intune's built-in Scripts and Remediations feature. The detection script reports
exactly why a device is unhealthy: agent not installed, service disabled, service stopped,
or a damaged install. The remediation script repairs everything that can be repaired
locally, such as enabling and starting the service, and clearly reports the cases that need
an assignment or enrollment fix instead of pretending to reinstall the agent.
Everything here is written for the environment your scripts actually run in: 64-bit Windows
PowerShell in SYSTEM context, structured logging to C:\ProgramData\Company\Logs\, and exit
codes that follow the Intune remediation convention so device status in the admin center
means what you expect it to mean.
Symptoms
You will typically discover this problem from the admin center side, then confirm it on the
device. The most common signals are:
Win32 app assignments show "Waiting for install status" or stay at 0% on specific devices indefinitely.
Proactive remediation script assignments report the device as "Not applicable" or never return a status.
The device is visible in Intune and checks in for policy, but no IME-specific inventory or script status ever appears.
On the device, the IntuneManagementExtension service is absent from services.msc, or present but stopped with a disabled start type.
C:\Program Files (x86)\Microsoft Intune Management Extension\ is missing entirely, or the log folder C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\ has no recent entries.
A useful tell: if the device checks in for MDM policy but has never run any Win32 app
deployment, suspect the IME first before troubleshooting the app itself.
Possible Causes
The device was never targeted with an IME-triggering assignment
The IME is not installed during MDM enrollment. It installs automatically when the device
is targeted with a Win32 line-of-business app, a Microsoft Store app wrapped as Win32, or a
required system script. Devices that only receive settings catalogs and compliance policies
never install the agent at all.
Enrollment prerequisites are missing or broken
The IME requires an Entra joined (or hybrid joined) device with an active MDM enrollment.
Devices with failed or partial enrollment state sometimes enroll for policy but never
qualify for IME installation.
The service was disabled intentionally
Hardening scripts, third-party "debloat" tooling, or a well-meaning admin disabling services
listed as "unknown" can turn IntuneManagementExtension to Disabled. The agent then cannot
start, and no remediation content reaches the device.
A damaged install or failed agent upgrade
Interrupted agent upgrades, disk space exhaustion during an upgrade, or antivirus
quarantining agent binaries can leave the service registered but its files missing, which
detection must catch before a blind service start makes things worse.
Image capture with the agent pre-installed
Golden images that included the IME at capture time produce devices with a stale, half
configured agent. Microsoft's guidance is to capture images without the IME present, and
devices built from such images frequently show exactly this broken state.
Detection Script
The script below is read-only and safe to run at any frequency. It completes in a few
seconds, runs in 64-bit SYSTEM context, and evaluates five checks in order: enrollment
prerequisites, service presence, service start type, agent executable, and running state.
PowerShell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
#Requires -RunAsAdministrator
[CmdletBinding()]
param()
Set-StrictMode -Version Latest
$ErrorActionPreference = 'Stop'
<#
.SYNOPSIS
Detection script: verifies the Intune Management Extension (IME) is
installed, enabled, and running on a Windows device.
.NOTES
Intended for Intune Scripts and Remediations, 64-bit SYSTEM context.
This script NEVER changes the system. Exit 0 = healthy, 1 = IME missing
or unhealthy (remediation needed), 2 = prerequisites missing (device is
not Entra joined / not MDM enrolled), 3 = unexpected error.
#>$logDir = 'C:\ProgramData\Company\Logs'$logFile = Join-Path $logDir'ImeDetection.log'$imeServiceName = 'IntuneManagementExtension'$imeInstallRoot = "${env:ProgramFiles(x86)}\Microsoft Intune Management Extension"$imeExePath = Join-Path $imeInstallRoot'IntuneManagementExtension.exe'function Write-DetectionLog {
param([Parameter(Mandatory)][string] $Level, [Parameter(Mandatory)][string] $Message)
if (-not (Test-Path $logDir)) { New-Item -Path$logDir -ItemType Directory -Force | Out-Null }
"$([DateTime]::UtcNow.ToString('o')) [$Level] $Message" | Out-File -FilePath$logFile -Append -Encoding utf8
}
function Test-EntraJoined {
# dsregcmd /status is the supported way to read join state from a script.$status = & "$env:SystemRoot\System32\dsregcmd.exe" /status 2>$nullreturn (($status | Select-String -Pattern'^\s*AzureAdJoined\s*:\s*YES\s*$') -ne$null)
}
function Test-MdmEnrolled {
# A device-managed MDM enrollment appears as a GUID subkey of # HKLM:\SOFTWARE\Microsoft\Enrollments with EnrollmentType 6 (MDM).$enrollPath = 'HKLM:\SOFTWARE\Microsoft\Enrollments'if (-not (Test-Path $enrollPath)) { return$false }
$keys = Get-ChildItem -Path$enrollPath -ErrorAction SilentlyContinue
foreach ($keyin$keys) {
$type = (Get-ItemProperty -Path$key.PSPath -Name EnrollmentType -ErrorAction SilentlyContinue).EnrollmentType
if ($type -eq6) { return$true }
}
return$false
}
try {
Write-DetectionLog 'INFO''IME detection run started.' # ---- Check 1: prerequisites (Entra join + MDM enrollment) ----$entraJoined = Test-EntraJoined
$mdmEnrolled = Test-MdmEnrolled
Write-DetectionLog 'INFO'"Prerequisites: AzureAdJoined=$entraJoined MdmEnrolled=$mdmEnrolled"if (-not $entraJoined -or -not$mdmEnrolled) {
Write-DetectionLog 'WARN''Device lacks IME prerequisites (Entra join or MDM enrollment missing).'
exit 2
}
# ---- Check 2: service present and enabled ----$service = Get-Service -Name$imeServiceName -ErrorAction SilentlyContinue
if ($null -eq$service) {
Write-DetectionLog 'ERROR'"Service '$imeServiceName' not found - IME is not installed."
exit 1
}
$startMode = (Get-CimInstance -ClassName Win32_Service -Filter"Name='$imeServiceName'").StartMode
Write-DetectionLog 'INFO'"Service found. Status=$($service.Status) StartMode=$startMode"if ($startMode -eq'Disabled') {
Write-DetectionLog 'ERROR''IME service is Disabled - agent cannot run.'
exit 1
}
# ---- Check 3: executable present ----if (-not (Test-Path $imeExePath)) {
Write-DetectionLog 'ERROR'"IME executable not found at $imeExePath - install is broken."
exit 1
}
# ---- Check 4: service actually running ----if ($service.Status -ne'Running') {
Write-DetectionLog 'ERROR'"IME service is $($service.Status) (expected Running)."
exit 1
}
# ---- Check 5: build version recorded (informational) ----$version = (Get-Item $imeExePath).VersionInfo.ProductVersion
Write-DetectionLog 'INFO'"IME healthy. Version=$version"
exit 0
}
catch {
Write-DetectionLog 'ERROR'"Unexpected failure: $($_.Exception.Message)"
exit 3
}
Detection Logic
The detection walks from prerequisites to runtime state, because each check only makes
sense if the previous one passed.
Entra join status. The script runs dsregcmd /status and looks for
AzureAdJoined : YES. This is the supported, version-tolerant way to read join state
from a script, and it works for both Entra joined and hybrid joined devices.
MDM enrollment. It enumerates HKLM:\SOFTWARE\Microsoft\Enrollments and looks for a
GUID subkey whose EnrollmentType value is 6, which is the value used for
device-managed MDM enrollment. A device that fails both this and the join check gets
exit code 2, telling you the problem is upstream of the IME.
Service presence.Get-Service -Name IntuneManagementExtension answers whether the
agent is installed at all. A missing service with valid prerequisites is the classic
"never targeted with a Win32 app" case.
Start type. Through Win32_Service CIM query the script reads the configured start
mode. Disabled is reported even when the service is currently running, because it will
fail after the next reboot.
Executable check. The script verifies
C:\Program Files (x86)\Microsoft Intune Management Extension\IntuneManagementExtension.exe
exists. A registered service without its binary is a damaged install, and starting it
would only produce generic failure codes.
Running state. Finally, Status must be Running. Anything else is treated as
unhealthy even if the start type is correct.
Every step writes a structured line to C:\ProgramData\Company\Logs\ImeDetection.log, so a
Fleet view of the results doubles as an audit trail of why each device was flagged.
Remediation Script
The remediation is deliberately conservative: it enables the service when it has been
disabled, starts it when stopped, and verifies the agent binary exists. It does not
attempt to install or reinstall the IME, because the agent is delivered by Intune itself.
When the agent is missing, the script checks prerequisites and exits with code 2, which
tells you the correct fix is an assignment or an enrollment repair, not a local install
attempt.
PowerShell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
#Requires -RunAsAdministrator
[CmdletBinding()]
param()
Set-StrictMode -Version Latest
$ErrorActionPreference = 'Stop'
<#
.SYNOPSIS
Remediation script: repairs an unhealthy Intune Management Extension (IME)
agent on a Windows device.
.DESCRIPTION
Scope of this script (deliberately conservative):
- Enables the IME service when it is Disabled.
- Starts the IME service when it is stopped.
- Restarts the service when it is hung (start pending for a long time is
reported, not force-killed, to avoid tearing an active install).
- When the IME is NOT installed at all, it verifies prerequisites and
exits with code 2: Intune installs the IME automatically the first time
the device is targeted with a Win32 app or a required system script,
so the correct fix is an assignment, not a local install attempt.
This script never removes the agent, never deletes agent state, and never
touches user data.
#>$logDir = 'C:\ProgramData\Company\Logs'$logFile = Join-Path $logDir'ImeRemediation.log'$imeServiceName = 'IntuneManagementExtension'$imeExePath = "${env:ProgramFiles(x86)}\Microsoft Intune Management Extension\IntuneManagementExtension.exe"function Write-RemediationLog {
param([Parameter(Mandatory)][string] $Level, [Parameter(Mandatory)][string] $Message)
if (-not (Test-Path $logDir)) { New-Item -Path$logDir -ItemType Directory -Force | Out-Null }
"$([DateTime]::UtcNow.ToString('o')) [$Level] $Message" | Out-File -FilePath$logFile -Append -Encoding utf8
}
function Test-EntraJoined {
$status = & "$env:SystemRoot\System32\dsregcmd.exe" /status 2>$nullreturn (($status | Select-String -Pattern'^\s*AzureAdJoined\s*:\s*YES\s*$') -ne$null)
}
function Test-MdmEnrolled {
$enrollPath = 'HKLM:\SOFTWARE\Microsoft\Enrollments'if (-not (Test-Path $enrollPath)) { return$false }
foreach ($keyin (Get-ChildItem -Path$enrollPath -ErrorAction SilentlyContinue)) {
$type = (Get-ItemProperty -Path$key.PSPath -Name EnrollmentType -ErrorAction SilentlyContinue).EnrollmentType
if ($type -eq6) { return$true }
}
return$false
}
try {
Write-RemediationLog 'INFO''IME remediation run started.'$changed = $false$service = Get-Service -Name$imeServiceName -ErrorAction SilentlyContinue
if ($null -eq$service) {
# ---- IME not installed: prerequisites decide the correct action ----$entraJoined = Test-EntraJoined
$mdmEnrolled = Test-MdmEnrolled
if (-not $entraJoined -or -not$mdmEnrolled) {
Write-RemediationLog 'WARN'"IME not installed and prerequisites missing (AzureAdJoined=$entraJoined MdmEnrolled=$mdmEnrolled). Device needs join/enrollment repair first."
exit 2
}
Write-RemediationLog 'WARN''IME not installed but prerequisites are present. Assigning any Win32 app or required system script to this device triggers the automatic IME installation; no local install is attempted.'
exit 2
}
# ---- Enable the service when it is Disabled ----$startMode = (Get-CimInstance -ClassName Win32_Service -Filter"Name='$imeServiceName'").StartMode
if ($startMode -eq'Disabled') {
Set-Service -Name$imeServiceName -StartupType Automatic
Write-RemediationLog 'INFO''IME service was Disabled - set startup type to Automatic.'$changed = $true
}
# ---- Start the service when it is stopped ----if ($service.Status -ne'Running') {
Write-RemediationLog 'INFO'"Starting IME service (previous status: $($service.Status))."
Start-Service -Name$imeServiceName -ErrorAction Stop
$service.WaitForStatus('Running', (New-TimeSpan -Seconds90))
Write-RemediationLog 'INFO''IME service started successfully.'$changed = $true
}
else {
Write-RemediationLog 'INFO''IME service already running - no start action needed.'
}
# ---- Confirm the executable is present (catches broken installs) ----if (-not (Test-Path $imeExePath)) {
Write-RemediationLog 'ERROR''IME executable missing - the install is damaged beyond a service fix. Re-trigger the agent by assigning a Win32 app, or re-enroll the device.'
exit 3
}
if ($changed) { Write-RemediationLog 'INFO''IME remediation applied.' }
else { Write-RemediationLog 'INFO''Device already compliant - no changes made.' }
exit 0
}
catch {
Write-RemediationLog 'ERROR'"Remediation failed: $($_.Exception.Message)"
exit 3
}
The important design decision is the strict separation between "repairable locally" and
"needs an Intune-side action". Scripts that silently try to force-reinstall agents are the
ones that turn one unhealthy device into a service desk ticket generator.
Deploying Through Intune
Deploy both scripts as one remediation package:
Sign in to the Microsoft Intune admin center.
Go to Devices → Scripts and remediations, then choose + Add on the Windows 10/11 platform tab.
On the Basics tab, give the package a recognizable name, for example Remediate - Intune Management Extension health, and a description that states the blast radius ("enables and starts the IME service; never removes the agent").
On Detection script, upload detect.ps1. Choose Run script in 64-bit PowerShell: Yes, and leave Run this script using signed-on credentials: No so the script runs as SYSTEM.
On Remediation script, upload remediate.ps1 and keep the same context settings. Leave Enforce script signature check: No unless your organization signs internal scripts and certificates are deployed to devices.
On Schedule, set frequency to Daily until your fleet is healthy, then relax to Weekly. IME health degrades slowly, and daily runs catch broken upgrades within a day.
On Assignments, target a dynamic device group such as "All Windows devices enrolled in Intune", or better, a test ring first. Apply filters if you need to exclude devices that intentionally run without the IME.
Review and create.
Post-specific notes:
Run this in 64-bit PowerShell: Yes. The IME installs under Program Files (x86) and
the script reads both 64-bit and file-system paths that a 32-bit PowerShell session would
silently redirect.
Signed-on credentials: No. All checks are machine-scoped; user context adds nothing.
Keep detection-only mode in mind: if you prefer to measure the problem before fixing it,
publish the package with only the detection script and review results for a week.
Visual Walkthrough
The Management Extension log narrates every app from job to verdict.
TimelineIME Log Forensics — Read It Like a Timeline5/5
T+0 · job
1
Job received
IntuneManagementExtension.log: app + policy arrives with install intent.
download
2
Content download
Win32AppMgr fetches content; watch byte counts and DO involvement.
execute
3
Command execution
AgentExecutor runs install command; exit code recorded verbatim.
detect
4
Detection pass
Detection rule evaluated; mismatch means "reinstall next cycle".
report
5
State reported
Final app state posts to Intune; correlate in the portal report.
IME Log Forensics — Read It Like a Timeline. 1. Job received: IntuneManagementExtension.log: app + policy arrives with install intent. — 2. Content download: Win32AppMgr fetches content; watch byte counts and DO involvement. — 3. Command execution: AgentExecutor runs install command; exit code recorded verbatim. — 4. Detection pass: Detection rule evaluated; mismatch means "reinstall next cycle". — 5. State reported: Final app state posts to Intune; correlate in the portal report.
Exit Codes
Intune runs the detection script and evaluates its exit code; any non-zero result marks the
device as needing remediation and triggers the remediation script according to your
schedule. The scripts use the following convention:
Code
Meaning
0
IME is installed, enabled, and running (detection) — or the repair succeeded / device already compliant (remediation)
1
IME is missing, disabled, stopped, or its executable is missing — remediation needed
2
Prerequisites missing (device not Entra joined or not MDM enrolled), or IME not installed with prerequisites present — needs an assignment or enrollment fix, not a local repair
3
Unexpected script error — inspect the log
In the admin center, devices showing "Remediated" under the script status view are the ones
where the remediation changed something and now pass detection. Devices stuck in "Error"
deserve a look at the local log before anything else.
Logging
Both scripts write to the same structured location:
Each line carries a UTC timestamp, a level (INFO, WARN, ERROR), and a message. The
log directory is created on first run, and files grow slowly (a few lines per run), so
retention is rarely a concern; if you want a hard cap, rotate the files monthly with your
existing log management. When you need the agent's own view of the world, cross-reference
C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log,
which is the IME's native log and the first place to look for service-side errors.
Troubleshooting the Script
Device shows "Error" immediately after assignment. Confirm the script really runs in
64-bit PowerShell; a 32-bit session on x64 Windows resolves
Program Files (x86) differently and the executable check can misfire.
Exit code 2 floods your reports. That is the script doing its job: those devices are
not Entra joined or not MDM enrolled. Work those devices through join/enrollment repair,
not through this remediation.
Service starts but stops again within a minute. Read the IME's own log in
C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\ and check for upgrade
failures. Repeated start-stop loops usually mean a damaged install that needs the agent
re-triggered from the Intune side.
No log file appears at all. The script never ran. Verify the assignment, check
whether another policy set "Run script using signed-on credentials" with an enforcement
conflict, and confirm the device last checked in.
Antivirus quarantines the script. Unsigned scripts downloaded from anywhere can trip
AMSI or tamper rules. Sign your internal scripts, or add the documented exclusions your
security team approves, before broad rollout.
How to Validate the Fix
On a flagged device, run the detection script manually in an elevated 64-bit PowerShell
console. Before remediation you expect exit code 1 and an ERROR line naming the
failed check.
Run the remediation script manually. Expect exit code 0 and log lines showing the
enable and start actions.
Re-run detection. It must now return 0 with a IME healthy. Version=... line.
In the admin center, open the remediation package and check Device status. The
device should move to "Remediated" or "Compliant" after its next sync.
Prove the agent is functional end to end: assign a harmless Win32 app or a benign system
script to the device group and confirm it executes. Agent health is only proven when an
IME-dependent workload actually runs.
Production Considerations
Execution context. Both scripts run as SYSTEM in 64-bit Windows PowerShell. No user
token is needed, and no user profile paths are touched.
Idempotency. Both scripts are safe on repeat runs: detection changes nothing, and
remediation logs "already compliant" when everything is healthy.
Side effects and reboots. Enabling and starting a service does not require a reboot.
The scripts never restart the service while it is running, so an active Win32 install is
never interrupted.
Security. No credentials, tokens, or secrets appear in the scripts. The only external
binary invoked is the built-in dsregcmd.exe. Have your PowerShell automation SME and
security team review the scripts and validate them in a test ring before broad production
rollout, in line with your organization's script signing and review policy.
Scope control. Assign through a device group you can shrink quickly. If anything
behaves unexpectedly, removing the assignment stops new runs without touching devices.
Why can't the script just install the IME when it is missing?
The IME is delivered by the Intune service, not by a standalone installer you should run
locally. When a device has valid join and enrollment state, assigning any Win32 app or
required system script to it triggers the automatic installation. A script that tries to
hand-install the agent would fight the service's own lifecycle and break on every agent
update.
Does this work on hybrid Entra joined devices?
Yes. dsregcmd /status reports AzureAdJoined : YES for both Entra joined and hybrid
joined devices, and the IME behaves identically on both. If your hybrid environment has
join problems, the script reports exit code 2, and you should investigate the join state
first.
How long until Intune shows the device as remediated?
Device status updates after the device runs the package and syncs its result, typically
within one agent interval. Daily-frequency packages usually show corrected status within a
day of the repair. Force a sync from the device or the admin center when validating.
Comments
0No comments yet — be the first to share your thoughts.