Run Intune Remediations On Demand to Fix One Windows Device Without Waiting

To fix one Windows device without waiting for a remediation schedule, open the device in the Microsoft IntuneThe KBY LexiconMicrosoft IntuneMicrosoft Intune is Microsoft's cloud-based unified endpoint management service for enrolling, configuring, securing and retiring Windows, macOS, iOS and Android devices. Read Full Context admin center under Devices > By platform > Windows, select … > Run remediation (preview), pick a script package and select Run remediation. The package does not need to be assigned to the user or device, but it does need to exist in Scripts and remediations, and you need the Run remediation permission under Remote tasks (plus Organization: Read while the feature is in preview). The key constraint is reachability: the device must be online and able to talk to Intune and Windows Push Notification Service (WNS) when you send the action, or it never receives it. Confirm the result under the device’s Monitor section > Remediations, and keep the detection and remediation status as your evidence.

#Current method: tickets wait for the schedule or a remote session

A Remediations script package is a detection script, an optional remediation script and metadata, which the Intune Management Extension (IME) runs on a schedule: once, hourly at an interval under 24 hours, or daily. That suits fleet hygiene, not the user who has just raised a ticket.

When a package already fixes the reported problem, the analyst either waits for the next scheduled run, which also depends on the IME having retrieved policy (after a device or IME restart, after a user signs in, and every eight hours), or opens a remote session and repeats the fix by hand. The first leaves the ticket open longer than the fix takes; recurring scripts also report on a seven-day cycle, only reporting earlier when something changes. The second produces free-text evidence and bypasses the review the package went through.

#Improved workflow: a curated on-demand catalogue with evidence

Treat on-demand runs as a small, curated catalogue that service-desk staff run against one device at a time, with the package’s own detection result as evidence.

1. Curate the catalogue. Choose packages that are safe to run more than once and whose detection reports the state it found. On-demand packages need no assignment, so service-desk-only packages stay out of scheduled deployments.
2. Bound who sees what. Scope tags limit which script packages a user can see in the Run remediation pane. Give the service-desk role only the tags for packages approved for on-demand use.
3. Grant one permission, not a broad role. Use a custom role with Remote tasks > Run remediation and, during the preview, Organization: Read, without the Device configurations permissions that author packages.
4. Run, then read the evidence. The analyst runs the package, then records the detection and remediation status from the device’s Remediations view in the ticket.
5. Escalate on a defined signal. If the device is unreachable or the issue is still detected after remediation, the ticket goes to the package owner rather than being retried.

The trade-off: analysts lose the freedom to run anything and engineers own the catalogue, but every fix is the reviewed script and every ticket carries machine-generated proof.

#Implementation

Do this first on pilot test devices, not in production.

#

Prerequisites

• Devices are Microsoft Entra joined or Microsoft Entra hybrid joined, and are either MDM enrolled in Intune running Windows Enterprise, Professional or Education, or co-managed.
• Users of the devices hold Windows Enterprise E3 or E5, Windows Education A3 or A5, or Windows Virtual Desktop Access (VDA) per user. An Intune Service Administrator must confirm licensing before Remediations are used for the first time.
• The IME is installed. Intune installs it automatically when a Win32 app, PowerShell script or Remediation is assigned to the user or device.
• The tenant stays within the limit of 200 script packages.

#

Step 1: prepare and review the package

The built-in Update stale Group Policies package (last refresh more than seven days ago, fixed with gpupdate) is a good first candidate. For a custom package, go to Devices > Manage devices > Scripts and remediations and select Create script package. Upload the detection and remediation .ps1 files rather than editing them in the browser, so the files keep their UTF-8 encoding.

The detection script decides everything. A remediation script only runs when detection exits with code 1. Any other exit code, including empty output, is treated as no issue found. The pattern used in Microsoft’s sample scripts is:

1# Detection: exit 1 only when the issue is present
2if ($issueDetected) {
3    Write-Host "Match"
4    exit 1
5}
6else {
7    Write-Host "No_Match"
8    exit 0
9}

The device list is paged: if the device is not on the first page, follow @odata.nextLink until it is no longer returned. To spot devices that have stopped checking in first, the script for Intune devices that haven’t synced in N days lists them. Then send the action:

1Connect-MgGraph -Scopes "DeviceManagementManagedDevices.PrivilegedOperations.All"
2Invoke-MgGraphRequest -Method POST `
3    -Uri "https://graph.microsoft.com/beta/deviceManagement/managedDevices/<managedDeviceId>/initiateOnDemandProactiveRemediation" `
4    -Body '{"scriptPolicyId":"<deviceHealthScriptId>"}' -ContentType "application/json"

A successful call returns 204 No Content, so the cmdlet prints nothing. That confirms Intune accepted the request, not that the device ran the script. To read run state for a package, list its device run states:

1(Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/beta/deviceManagement/deviceHealthScripts/<deviceHealthScriptId>/deviceRunStates").value |
2    ForEach-Object { [pscustomobject]@{
3        detection   = $_.detectionState
4        remediation = $_.remediationState
5        updated     = $_.lastStateUpdateDateTime
6        preOutput   = $_.preRemediationDetectionScriptOutput
7        postOutput  = $_.postRemediationDetectionScriptOutput
8        error       = $_.remediationScriptError
9        id          = $_.id } }

The list covers every device that has run the package, so it is easiest to read for a package used only on demand. detectionState can be unknown, success, fail, scriptError, pending or notApplicable; remediationState can be unknown, skipped, success, remediationFailed, scriptError or unknownFutureValue. Treat the device’s Remediations view in the admin center as the authoritative place to confirm an on-demand run, and use the Graph run state as supporting evidence.

#Guardrails

• Only idempotent, reversible packages go in the catalogue, so a second click after a slow response cannot cause harm.
• Least privilege for people and apps. Analysts get Run remediation, not package authoring. Automation reading IDs uses read scopes; only the call that sends the action uses DeviceManagementManagedDevices.PrivilegedOperations.All.
• Signed scripts need a trusted publisher. If you enable Enforce script signature check, scripts must be UTF-8 without a byte order mark, run under the device’s PowerShell execution policy (Restricted by default on Windows clients), and their signing certificate must be in the device’s Trusted Publishers store.

#Validation

Before you release the catalogue to the service desk, prove each package on pilot devices in three states:

1. Issue present. Create the detected condition on a test device, run the package on demand, and confirm detection found the issue, remediation succeeded and the issue is gone.
2. Issue absent. Run it on a healthy device and confirm detection reports no issue and the remediation did not run.
3. Device offline. Run it against a device that is switched off and confirm the analyst procedure treats the missing result as unreachable, not as a failed fix.

Pass condition: all three outcomes match, and the analyst role, not only an administrator, can read the evidence in the device’s Remediations view. Export saves package output as a CSV; on the Remediations list, filters and exports cover only loaded packages, so scroll to load them all first.

#Common mistakes and how to diagnose them

• Symptom: nothing happens after Run remediation. Likely cause: the device was offline or could not reach Intune or WNS when the action was sent; it does not receive the action later. Diagnosis: check the device’s last check-in and network state. Correction: wait until the device is online, then send one new action.
• Symptom: the remediation never runs although the user clearly has the problem. Likely cause: detection exits with something other than 1, or prints nothing. Diagnosis: read the pre-remediation detection output and run the detection script locally on a test device to see its exit code. Correction: fix the detection logic in a new package revision and revalidate.
• Symptom: the package is missing from the analyst’s list. Likely cause: scope tags do not match the analyst’s role assignment. Diagnosis: compare the package’s scope tags with the role assignment’s. Correction: correct the tag, not the role’s breadth.

#Recovery and rollback

Once the device has run the action it cannot be recalled, so recovery is designed into the package beforehand.

1. Back up the package. Keep the detection and remediation files in source control before any edit. The Version field in the package’s basics cannot be edited, so record your own revision in the description.
2. Record prior state in output. For a remediation that changes a setting, have detection print the current value (within 2,048 characters) so the pre-remediation output is the record of what to restore.
3. Withdraw a bad package fast. If a catalogue package causes harm, change its scope tags so the on-demand tag no longer applies and analysts can no longer select it, then fix it in the pilot.
4. Restore affected devices. Use a separate, reviewed package that sets the recorded prior value, run it on demand on the affected devices one at a time, and confirm with its detection output.
5. Verify recovery. Recovery is complete when the restoring package’s post-remediation detection reports the prior value and the user confirms the symptom is resolved.

#Measurable outcome

Baseline four weeks before release: tickets per month a catalogue package could have fixed, and their median time to resolution. After release, track the same tickets for the share resolved by an on-demand run with clean post-remediation detection, the share closed without a remote session, and the share escalated because the device was unreachable or detection still failed.

Review monthly with package owners. A package whose runs often end in remediationFailed or scriptError goes back to the pilot. A recurring issue that keeps arriving through on-demand runs is a candidate for a scheduled assignment instead, using the approaches in engineering out the slow laptop ticket with proactive disk remediation.

#On-demand remediation adoption checklist

• Devices, licences and the IME meet the documented Remediations requirements, and licensing has been confirmed by an Intune Service Administrator.
• Each catalogue package is idempotent, outputs stable state within 2,048 characters, exits 1 only when the issue is present, and contains no reboot, credentials or personal data.
• A dedicated scope tag and a custom role with Run remediation and Organization: Read limit what analysts see and do.
• Each package passed the issue-present, issue-absent and device-offline tests on pilot devices.
• The service-desk procedure says one action per device at a time, and to record pre- and post-remediation output in the ticket.
• The next safe decision is explicit: when a package’s on-demand failure rate rises, withdraw its scope tag first, then investigate.