Intune · PowerShell · Remediations

Writing safer Intune remediations

Start with one condition, useful output and a remediation that is safe to run again. A small service check shows the basic approach.

Drafted
Published
Updated
Reading time
2 min
Author
Roberto Gramellini

Source: Authorized Intune Automation Sample · revision sample-0

  • Intune
  • PowerShell
  • Remediations
A three-step Intune remediation cycle: detect device state, apply a safe change, then verify the result.

Writing safer Intune remediations

Before adding more logic to an Intune remediation, I like to ask one fairly boring question: can it run again safely? Detection should give the same answer for the same state, and remediation should not damage anything on its second or third run. Check one condition, explain the result, and keep the exit codes consistent.

Start with one condition

This deliberately generic example checks a service. There are no tenant identifiers, secrets or private endpoints to replace.

$service = Get-Service -Name "ExampleService" -ErrorAction SilentlyContinue

if ($null -eq $service -or $service.Status -ne "Running") {
    Write-Output "ExampleService is not ready."
    exit 1
}

Write-Output "ExampleService is healthy."
exit 0

Before adding it to an assignment

Missing resources are normal input to handle, not necessarily an exceptional failure. Keep the output short enough for someone to review, but say what was found.

Then check the remediation twice. It needs to be idempotent, and it should verify the state after acting. "The command did not complain" is a rather optimistic acceptance test.

Finally, leave credentials and environment-specific identifiers out of published code. A small detection script does not need to become a small credential distribution system.