When a proactive remediation script fails to work as expected, it’s much faster to test it locally than wait for the next sync from Intune. In this post, I’ll show you how I troubleshoot Intune remediation scripts directly on a Windows device. This includes script locations, relevant logs, and registry entries that help verify what happened and why.
Table of Contents
- Script Location on Disk
- Run the scripts manually
- Check the logs
- Review execution status in the registry
- Get script output and results
- Add better logging
- Summary
For some samples and an introduction to Remediation scrips check out the community repo an my blog about it: Endpoint Analytics Proactive Remediation Community
Script Location on Disk
Whenever a proactive remediation is executed, the scripts are downloaded to the following directory:
C:\Windows\IMECache\HealthScripts
The detection and remediation scripts are stored here in cleartext. That means anyone with access to the machine can open and read them. So it’s important to never include secrets, credentials or sensitive data in these scripts.
You’ll see subfolders for each script ID. Inside them, the DetectionScript.ps1
and RemediationScript.ps1
files can be manually executed for testing.
Run the scripts manually
To test a script without waiting for Intune, I run it directly from the cached folder:
cd "C:\Windows\IMECache\HealthScripts\<ScriptGUID>"
powershell.exe -ExecutionPolicy Bypass -File .\DetectionScript.ps1
The same method works for remediation:
powershell.exe -ExecutionPolicy Bypass -File .\RemediationScript.ps1
This helps identify syntax issues or problems that only show up on the target device.
Check the logs
The Intune Management Extension writes all activity to a central log file:
C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log
I usually open it with CMTrace or Notepad++ and search for:
- Script GUID or name
ProactiveRemediation
- Exit codes (like 0, 1 or other errors)
This gives a quick view of what ran, what was detected, and whether remediation was triggered.
Review execution status in the registry
Every script execution is also tracked in the registry. The local status and assignment information is available at: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\IntuneManagementExtension\SideCarPolicies\Scripts
This is useful for verifying whether the script was deployed and processed on the device.
Get script output and results
If your script writes values to the registry or uses output reporting, you’ll find those under:
HKLM:\SOFTWARE\Microsoft\IntuneManagementExtension\SideCarPolicies\Scripts\Reports\
You can extract this output with the following script:
$User_id = "00000000-0000-0000-0000-000000000000"
$Script_id = "xxx"
$RegPath = "HKLM:\SOFTWARE\Microsoft\IntuneManagementExtension\SideCarPolicies\Scripts\Reports\$User_id\$Script_id\Result"
Get-ItemProperty -Path $RegPath | Select-Object -ExpandProperty Result | ConvertFrom-Json | fl *Output*
Replace $Script_id
with the script’s action ID, which you can find in the Intune admin center URL when editing the remediation script.
Wanna see all outputs from all remediations?
Here you go:
$Users_all = Get-ChildItem "HKLM:\SOFTWARE\Microsoft\IntuneManagementExtension\SideCarPolicies\Scripts\Reports"
foreach($User in $Users_all){
$User.PSChildName
$Remediations_all = Get-ChildItem "HKLM:\SOFTWARE\Microsoft\IntuneManagementExtension\SideCarPolicies\Scripts\Reports\$($User.PSChildName)"
foreach($Remediation in $Remediations_all){
Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\IntuneManagementExtension\SideCarPolicies\Scripts\Reports\$($User.PSChildName)\$($Remediation.PSChildName)\Result" | Select-Object -ExpandProperty Result | ConvertFrom-Json | fl *Output*
}
}
Add better logging
When building your scripts, I recommend using Start-Transcript
to create a local log:
Start-Transcript -Path "C:\...\remediation_debug.log"
# script logic
Stop-Transcript
This makes it easier to understand what happens when the script runs as part of the managed task.
Summary
Troubleshooting Intune proactive remediation scripts locally saves time and reduces uncertainty. You get full visibility into the script files, logs and registry data. With this approach, I can test, debug and optimize scripts before pushing them to production.