Intune Remediation Script Shows Without Issues but Never Runs

#Current method: reading the status and guessing

Many teams deploy a Remediations script package, see a status of without issues or no result at all, and assume the endpoint is healthy. That is an inference, not an observation. A detection script that exits cleanly reports no issue whether the condition was truly absent or the check was written so that it can never fail. A package that never ran produces no useful evidence at all, and the two outcomes are easy to confuse in a console view.

This method creates rework. Operators edit the script repeatedly when the cause is often outside it: the tenant may lack the required licensing, the assignment may target a group with no devices, the schedule may not have elapsed, or the script may run in a context that cannot see the data it inspects. 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 documentation is the authoritative reference for these requirements; confirm licence and platform prerequisites there for your tenant and version.

#Improved workflow: eliminate platform causes before script causes

The improved workflow checks the cheapest, highest-level causes first, because each step consumes a small piece of evidence and rules out a whole class of failure. The order is: eligibility, assignment, schedule, execution context, then script logic. Each check changes nothing and produces an observable answer.

1. Eligibility: confirm the tenant and the targeted users or devices hold the licensing the Remediations feature requires, per Microsoft documentation. Without it, packages may appear but not deliver.
2. Assignment: confirm the package is assigned to a group that contains the test device, and that any filter does not exclude it.
3. Schedule: confirm the schedule type and frequency, and allow a full interval before concluding it did not run.
4. Run-as context: confirm whether the script runs as the signed-in user or as system, and whether it runs in a 64-bit host, because both change what the script can read.
5. Script logic: only now examine exit codes and output.

#Implementation

Work in a non-production tenant or a small pilot group, and confirm your product version and the permissions of your role before changing any setting. Use a role that can read and edit Remediations only; avoid broader administrative roles.

1. Prepare a known-positive test. Write a detection script that deliberately reports an issue on one pilot device, for example by checking for a marker file you create manually. Expected evidence: the console later shows an issue detected for that device. If it does, the pipeline works end to end and the production script is the suspect.
2. Verify eligibility. Read the licensing and prerequisites in the Intune documentation and compare them with the tenant. Stop if the requirement is not met; licensing changes belong to the licence owner.
3. Verify assignment. Open the package assignments, confirm the group includes the pilot device and review any filter. Expected evidence: the device appears in the package device status list rather than being absent.
4. Confirm the schedule. Note the configured frequency and wait one full interval after the device checks in. Stop waiting only after that interval has passed twice.
5. Set run-as deliberately. Choose the context that matches what the script reads: per-user data needs the signed-in context, machine-wide data typically needs system. Change one setting at a time and record it.
6. Check script output. Detection scripts signal state through exit code and output; confirm in the documentation how the console interprets them, then review the output reported for the device.

Stop conditions: if the known-positive test fails to report, do not widen the rollout. Treat it as a platform or eligibility problem and escalate to the person who owns the tenant configuration.

#Guardrails

• Limit remediation scripts to the smallest scope that proves the point; a remediation script changes devices and runs repeatedly.
• Keep detection read-only. Put changes only in the remediation script and review them before assignment.
• Do not embed credentials or private data in scripts or output.
• Use a pilot group and a filter, and expand only after the known-positive test passes.
• Record who changed which setting and when, so a result can be tied to a change.

The trade-off is speed against certainty: a pilot adds a delay of at least one schedule interval, but it prevents a faulty script from running across the whole fleet. Operational excellence guidance supports this pattern of observability, repeatable process and safe deployment.

#Validation

Success is observable. The known-positive device reports an issue; a device that meets the condition reports without issues; and, where remediation is enabled, the previously failing device reports as remediated on the next interval. Compare the result with an independent check on the device, such as inspecting the marker or setting directly, rather than relying on the console alone.

Related background can help: see tracing an endpoint management problem with Microsoft Intune for a general evidence-first method, and proactive disk remediation for a worked remediation design.

#Common mistakes

• Treating no issue as healthy. A detection check that cannot fail looks identical to a healthy fleet. Cure: the known-positive test.
• Assigning to the wrong object. A group with no devices, or a filter that excludes them, yields no data. Cure: check the device status list.
• Judging too early. Results lag the schedule. Cure: wait for full intervals.
• Wrong run-as context. A user-context script cannot read machine data and the reverse. Cure: match context to data.
• Changing several things at once. You cannot tell which change helped. Cure: one change, one record.

#Recovery

Every change here is reversible if you record the prior value first. If a modified package misbehaves, remove the assignment so it stops running on new check-ins, then restore the recorded settings (run-as, schedule, filter) and the previous script version. Scripts that already changed a device need a separate, tested undo action; do not assume removing the package reverses its effects.

1. Unassign the package from the pilot group.
2. Restore the saved run-as and schedule values.
3. Re-upload the previous script version.
4. Verify on one device, directly, that the state matches the baseline.

Post-recovery verification means the pilot device behaves as it did before the change and no further unexpected results are reported. Escalate to the tenant owner if devices remain affected.

#Measurable outcome

Establish a baseline before changing anything: the number of packages reporting no result or no issue, and how many of those have been confirmed against an independent device check. The success signal is the share of packages whose behaviour is verified by a known-positive test. Review it after each rollout and at a regular cadence agreed by the team. A sensible decision threshold is that no package expands beyond the pilot until its test has passed. No benefit figures are claimed here; measure your own baseline.

For related telemetry-driven designs see telemetry-triggered remediation for slow boots.

#Checklist

• Licensing and prerequisites confirmed against Microsoft documentation.
• Known-positive test reports an issue on a pilot device.
• Assignment and filters include the pilot device.
• At least one full schedule interval has elapsed.
• Run-as context and host match what the script reads.
• Prior settings and script version recorded for rollback.
• Independent device check agrees with the console result.
• Next safe decision: widen only after the pilot passes; otherwise escalate to the tenant owner.