Remediations: the detect-and-fix engine hiding in your Intune console

Intune has a built-in engine that runs a detection script on a schedule and, when it finds a problem, runs a paired fix script automatically. Most admins never open it — and those who do usually trip over the exit-code convention on their first attempt. Here is how it works, what it is for, and five remediations worth deploying today.

The problem

You manage Windows devices with Intune and keep hitting the same two walls. First, the Settings Catalogue simply has no setting for what you need — enabling a Windows optional feature, restarting a wedged service, clearing a stuck app install. Second, one-off Platform scripts run once and never again, so anything that drifts back stays broken until a user raises a ticket.

There is a purpose-built answer sitting in the console: Remediations (formerly Proactive Remediations). Andrew Taylor called his walkthrough "Remediations 101 – Intune's hidden secret" for a reason — it is a full detect-and-fix script engine that a large share of Intune admins have never clicked into.

And when admins do find it, the most common first experience is this: you write a detection script, assign the package, wait — and the remediation never runs. The report cheerfully shows Without issues on machines you know are broken.

Why it happens

Three separate causes conspire to keep Remediations under-used.

1. It keeps moving and changing name

The feature launched as Proactive remediations, buried under Reports > Endpoint analytics — a place most admins visit rarely, if ever. It has since been renamed to Remediations and now lives under Devices > Manage devices > Scripts and remediations. If you learned Intune's layout a few years ago, the feature is not where your muscle memory looks.

2. The exit-code contract inverts developer instinct

A remediation package is a pair of PowerShell scripts: a detection script and a remediation script. The contract is:

• Detection exits 0 → device is healthy → nothing runs.
• Detection exits 1 → issue found → the remediation script runs, then detection re-runs to confirm the fix.
• Any other exit code → treated as a script error, not an issue.

Every developer's instinct says non-zero exit codes mean failure, so first-timers end their detection script with exit 0 "on success" — and Intune duly records the device as compliant and never fires the fix. The remediation only ever runs when detection deliberately exits with code 1.

3. Licensing gates it

Remediations requires Windows 10/11 Enterprise E3 or E5 (included in Microsoft 365 F3/E3/E5), Education A3/A5, or Windows VDA per-user licensing, with devices Entra-joined or hybrid-joined and managed by Intune. Tenants without qualifying licences can see the blade but cannot use it, which reinforces the impression that it is "not for us".

The fix

Find it and check prerequisites

In the Intune admin centre, go to Devices > Manage devices > Scripts and remediations. Confirm your licensing (above) and that the account creating packages has an appropriate Intune RBAC role. Scripts are delivered by the Intune Management Extension and run as SYSTEM by default.

Honour the script contract

• Write a short detection script that checks one condition, writes a one-line status to standard output (this surfaces in the report), and exits 0 (healthy) or 1 (needs fixing).
• Write the paired remediation script that actually corrects the condition. After it runs, detection re-runs automatically to verify.
• Assign to a device group on a schedule — once, hourly or daily — or trigger it ad hoc on a single device with the Run remediation device action, which makes it a genuinely useful helpdesk tool.
• Keep each script under 200 KB.

Five high-value remediations to deploy

1. Refresh stale Group Policy. Microsoft ships a built-in, read-only package — Update stale Group Policies — that detects devices whose last Group Policy refresh is stale and triggers a refresh. Deploy it as-is; hybrid-joined estates benefit immediately.
2. Enable a Windows optional feature. The Settings Catalogue cannot enable arbitrary optional features; a remediation can. Detection: if ((Get-WindowsOptionalFeature -Online -FeatureName TelnetClient).State -eq 'Enabled') { Write-Output 'Present'; exit 0 } else { Write-Output 'Missing'; exit 1 }. Remediation: Enable-WindowsOptionalFeature -Online -FeatureName TelnetClient -All -NoRestart. The tbone.se walkthrough linked below covers this pattern end to end.
3. Restart a stopped or wedged service. Detection checks (Get-Service -Name Spooler).Status and exits 1 if it is not Running; remediation calls Restart-Service. Microsoft's second built-in package, Restart Office Click-to-Run service, is exactly this pattern and doubles as a worked example.
4. Reset a failed Win32 app so it retries. When a Win32 app install fails repeatedly, the Intune Management Extension records the failure in its Global Retry Schedule (GRS) under HKLM\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps and suppresses retries for around 24 hours. A remediation that removes the relevant app's GRS entries and restarts the IntuneManagementExtension service forces an immediate retry — a classic recurring helpdesk fix. Scope the deletion to the specific app GUID; do not clear the whole key.
5. Deploy Microsoft's built-in packages generally. Both built-ins ship read-only in every qualifying tenant and cost you zero scripting effort. Deploying them is the lowest-friction way to prove the feature's value to your organisation before you write custom pairs.

Gotchas checklist

• Exit code 1, not 0, is what triggers remediation. Write your status output before the exit statement.
• Scripts run in 32-bit PowerShell by default. Tick Run script in 64-bit PowerShell if you touch the registry or use cmdlets with 64-bit behaviour differences — registry redirection is a frequent silent failure.
• Default context is SYSTEM; switch to logged-on credentials only when you genuinely need the user's hive or profile.
• The minimum recurring schedule is hourly — this is not a real-time engine, so design detections to be idempotent and cheap.
• Check the pre-remediation detection output column in the report when debugging: if your status string never appears, your script is erroring before it exits.

How Decolla handles it

Everything above works without Decolla — Remediations is a native Intune feature, and the built-in packages plus the patterns here will carry you a long way.

What Decolla adds is that you do not have to discover the feature by accident or write and test the script pairs yourself. The Library — Decolla's curated catalogue of 260+ items across 21 sections — includes pre-built, industry-tested fixes of exactly this detect-and-fix shape, covering recurring helpdesk problems like the stale-policy and stuck-app cases above, alongside built-in hardening.

When you build a deployment through the wizard, each library item you select appears in a written, itemised plan showing its delivery method and its reversibility class (automatically reversible, reversible, or explicitly flagged irreversible) — and nothing runs until you approve that plan. Deployment then happens unattended into your own Intune/Autopilot tenant, so the objects land where you can see and audit them in your own console, and Decolla can roll back its own changes per item afterwards.

To be clear about limits: Decolla does not monitor remediation results in real time — you review outcomes in Intune's own reporting, exactly as described above. Decolla is currently pre-launch; if packaged, pre-tested fixes deployed against your own tenant would save you this class of work, the waitlist is open at decolla.app.

Sources

• Andrew Taylor — Proactive Remediations 101: Intune's hidden secret
• Microsoft Learn — Deploy remediations in Intune
• tbone.se — Enable Windows features with Proactive Remediations