When IME gets into a confused state, a targeted cache-and-log wipe is often faster than a re-enrolment — here’s when to reach for it and exactly what the script does.
What is the Intune Management Extension?
The Intune Management Extension (IME) is the Windows agent responsible for delivering PowerShell scripts, Win32 app deployments, and Proactive Remediations to managed endpoints. It runs as a Windows service, polls the Intune service on a regular schedule, and writes its working state to a pair of local directories — Policies and Logs under C:\ProgramData\Microsoft\IntuneManagementExtension.
Most of the time, it just works. But like any stateful agent sitting between a cloud control plane and a local execution environment, it can get out of sync. When it does, policy assignments silently stop applying, apps refuse to install, and the usual first instinct — checking the portal — shows everything assigned correctly. The problem isn’t in Intune. It’s on the endpoint.
When should you use this reset?
| Scripts not running
A PowerShell script assigned in Intune ran once and never again — or never at all — despite showing as targeted in the portal. |
Win32 app stuck
An app deployment is perpetually pending or erroring on a specific device with no clear failure reason in the portal. |
| Policy cache mismatch
Device was re-imaged, renamed, or moved between AAD tenants and the IME store has stale artefacts from the previous state. |
Proactive Remediations
Detection or remediation scripts are skipping execution windows — often caused by cached last-run timestamps blocking re-evaluation. |
| Post-enrolment catch-up
Freshly enrolled device needs to apply all assigned policies immediately rather than wait for the next standard check-in cycle. |
Testing changes
You’ve updated a script or app and need to force IME to pull the new version on a test device without waiting. |
| Before you run this
This clears cached policy state. All Win32 apps and scripts assigned to the device will be re-evaluated from scratch — some may re-install or re-execute. Confirm this is acceptable in production before running at scale. |
The reset script
# Stop all Intune-related services Get-Service intune* | Stop-Service # Wipe the cached policy assignments Remove-Item "C:\ProgramData\Microsoft\IntuneManagementExtension\Policies" -Recurse -Force # Clear logs (removes stale run-history and execution timestamps) Remove-Item "C:\ProgramData\Microsoft\IntuneManagementExtension\Logs" -Recurse -Force # Start services back up Get-Service intune* | Start-Service # Confirm service state Get-Service intune* # Belt-and-suspenders: explicit restart of the core service Restart-Service IntuneManagementExtension
Breaking down what each line does
Line 1 uses a wildcard to stop all services whose name begins with intune, catching both IntuneManagementExtension and any ancillary services. Stopping before deletion ensures no open file handles block the removal.
Lines 2–3 are the heart of the reset. The Policies folder holds the locally cached copy of all policy assignments. The Logs folder contains execution history files that IME uses to determine whether a script or remediation has already run. Leaving it intact can cause IME to skip re-execution even after clearing the policy cache — this is the step most guides miss.
Line 4 brings everything back. Line 5 outputs current service state so you can verify both services are running. Line 6 is an explicit restart of the named service — a safety net in case the wildcard missed something or a service came up in a degraded state.
What happens after the reset
- IME starts and finds no local policy cache — it immediately contacts the Intune service to pull a fresh policy set.
- All assigned Win32 apps, scripts, and remediations are re-evaluated as if the device has never processed them.
- Progress can be monitored live in IntuneManagementExtension.log, which IME recreates automatically in the Logs directory.
- Allow 5–15 minutes for full re-evaluation depending on the number of assignments and latency to the Intune service.
| Monitoring tip
Run: Get-Content “C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log” -Wait -Tail 30 in a second window to watch IME check in and re-apply policies in real time. |
Automating it with Proactive Remediation
For a single device, running this interactively is fine. For fleet-wide remediation — say, a batch of devices stuck after a tenant migration — wrap it in a Proactive Remediation. The detection script checks whether the IME log file is stale (older than 7 days by default). If it is, Intune triggers the remediation script automatically.
Deploy with a daily schedule, run as System in 64-bit PowerShell, and scope to a device group rather than All Devices until you’re confident with the detection threshold. Adjust $stalenessThresholdDays in the detection script to match your environment’s expected check-in cadence.
Detection script — Detect-IMECacheHealth.ps1
# Exits 1 (non-compliant) if the IME Policies folder is stale or absent
$policiesPath = "C:\ProgramData\Microsoft\IntuneManagementExtension\Policies"
$logsPath = "C:\ProgramData\Microsoft\IntuneManagementExtension\Logs"
$stalenessThresholdDays = 7
try {
if (-not (Test-Path $policiesPath)) {
Write-Output "Non-compliant: Policies folder missing."
exit 1
}
$logFile = Join-Path $logsPath "IntuneManagementExtension.log"
if (-not (Test-Path $logFile)) {
Write-Output "Non-compliant: IME log file missing."
exit 1
}
$lastWrite = (Get-Item $logFile).LastWriteTime
$ageDays = ((Get-Date) - $lastWrite).TotalDays
if ($ageDays -gt $stalenessThresholdDays) {
Write-Output "Non-compliant: IME log last written $([math]::Round($ageDays,1)) days ago."
exit 1
}
Write-Output "Compliant: IME cache healthy."
exit 0
} catch {
Write-Output "Error during detection: $_"
exit 1
}
Remediation script — Remediate-IMECacheHealth.ps1
# Stops IME services, clears policy cache and logs, restarts cleanly
$policiesPath = "C:\ProgramData\Microsoft\IntuneManagementExtension\Policies"
$logsPath = "C:\ProgramData\Microsoft\IntuneManagementExtension\Logs"
try {
Get-Service intune* -ErrorAction SilentlyContinue |
Stop-Service -Force -PassThru | ForEach-Object { Write-Output "Stopped: $($_.Name)" }
Start-Sleep -Seconds 3
if (Test-Path $policiesPath) {
Remove-Item $policiesPath -Recurse -Force
Write-Output "Removed: $policiesPath"
}
if (Test-Path $logsPath) {
Remove-Item $logsPath -Recurse -Force
Write-Output "Removed: $logsPath"
}
Get-Service intune* -ErrorAction SilentlyContinue |
Start-Service -PassThru | ForEach-Object { Write-Output "Started: $($_.Name)" }
Start-Sleep -Seconds 5
Restart-Service IntuneManagementExtension -Force
Write-Output "IntuneManagementExtension restarted successfully."
exit 0
} catch {
Write-Output "Remediation failed: $_"
exit 1
}
Important caveats
| Co-managed devices
On devices co-managed with Configuration Manager, verify that the workloads you’re troubleshooting are actually owned by Intune before running this. Resetting IME on a device where CM owns app management won’t help and may complicate the CM client state. |
| Proactive Remediation scoping
Scope to a device group rather than All Devices on first deployment. The 7-day staleness threshold may produce false positives in environments with aggressive conditional access or frequently offline laptops — tune $stalenessThresholdDays accordingly. |
The bottom line
This script is a scalpel, not a sledgehammer. Unlike a full device wipe or unenrolment, it leaves the Azure AD join, MDM enrolment, and all Configuration Service Provider (CSP) policies intact — it only clears the IME-specific cache that governs Win32 apps, PowerShell scripts, and Proactive Remediations. Keep it in your endpoint troubleshooting toolkit: it resolves a surprising proportion of IME-related support escalations in under five minutes.
Hope this helps!
É
