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
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.