Replacing Manual Proactive Experience (DEX) Triage With a Verifiable Intune Workflow

Digital Employee Experience (DEX) work often starts as manual triage: a ticket arrives, an engineer remote-connects to the affected device, runs a diagnostic script by hand, and closes the ticket once the symptom disappears. This approach does not scale, produces no comparable evidence across the fleet, and leaves no record of whether the underlying condition was resolved or simply masked. This playbook describes a bounded, verifiable way to move one such workflow — for example, low free disk space that degrades start-up performance — into a Microsoft Intune Proactive Remediations workflow, with explicit guardrails, validation evidence and a recovery path.

Assumptions made visible: this playbook assumes devices are already enrolled in Intune and reporting into Endpoint Analytics, that the organisation holds the licensing tier required for Proactive Remediations (confirm this locally before proceeding — see the review note in this article), and that a pilot device group exists for validation before any fleet-wide assignment. Where any of these assumptions do not hold, treat the steps below as design guidance rather than an executable runbook.

#Current Method

In the manual model, the same three actions repeat for every affected device:

• A user reports symptoms (slow start-up, low storage warnings, stalled updates) through a helpdesk ticket.
• An engineer connects remotely, runs a locally-held script or manual check, and applies a fix by hand.
• The engineer closes the ticket based on the symptom disappearing, without a standard evidence record of the detected condition or the applied fix.

This produces three structural weaknesses. First, evidence is inconsistent: each engineer may check different signals, so the organisation cannot compare devices or trends. Second, there is no repeatable detection step, so the same condition often recurs and is treated as a new incident. Third, recovery relies entirely on the engineer’s memory of what they changed, with no recorded rollback boundary.

#Improved Workflow

Intune Proactive Remediations pairs a detection script with a remediation script, both run on a schedule by the Intune Management Extension on enrolled Windows devices. The detection script inspects a specific condition and exits with a status Intune can record; the remediation script runs only when detection reports the condition is present, and its outcome is also recorded. This turns an ad hoc manual check into a repeatable, reportable unit of work that can be scoped to a pilot group before any fleet-wide rollout.

The workflow has four stages: define the detection condition precisely enough to be testable; write and test the detection and remediation scripts against known-good and known-bad devices in an isolated environment; assign the script pair to a small pilot group with reporting enabled; and only then expand scope once the pilot results match expectations.

#Implementation

Start with a detection script that checks one narrow, observable condition rather than several unrelated symptoms at once. Keep it read-only and side-effect free.

1$driveInfo = Get-PSDrive -Name C -ErrorAction Stop
2$freeGB = [math]::Round($driveInfo.Free / 1GB, 1)
3if ($freeGB -lt 10) {
4    Write-Output "Free space below threshold: $freeGB GB"
5    exit 1
6} else {
7    Write-Output "Free space acceptable: $freeGB GB"
8    exit 0
9}

The remediation script should only act on the specific condition the detection script identified, and it should be reversible or, at minimum, non-destructive to user data.

1$targets = @("$env:TEMP*", "C:WindowsSoftwareDistributionDownload*")
2foreach ($path in $targets) {
3    if (Test-Path $path) {
4        Remove-Item -Path $path -Recurse -Force -ErrorAction SilentlyContinue
5    }
6}
7Write-Output "Cleanup complete"
8exit 0

Before assigning either script to any managed device, run both manually against a small set of isolated test machines representing normal and degraded states. Only after that manual verification should the script pair be uploaded as an Intune Proactive Remediation package and assigned, initially, to a pilot Azure AD group of no more than a few dozen devices.

#Guardrails

• Scope every assignment to a named pilot or ring group before it reaches production devices; never assign directly to "All Devices".
• Apply least privilege: the Intune role assigning remediation scripts should be separate from the role that manages device compliance policy, so a single account cannot alter both detection logic and enforcement in the same session.
• Run remediation scripts under the least privilege required for the action; avoid running as SYSTEM when the fix does not require system-level access.
• Set an explicit run schedule (for example, once daily) rather than the shortest available interval, to limit the blast radius of an unexpected remediation script error.
• Keep detection and remediation logic in version control with change history, even though Intune itself does not require this.

#Validation

Treat the pilot phase as evidence-gathering, not as a formality to pass through quickly.

• Confirm the detection script correctly identifies the condition on known-bad pilot devices and reports a healthy state on known-good devices, with no false positives over at least one full run cycle.
• Confirm the remediation script only executes when detection reports the condition present, by checking the Intune run report for each pilot device.
• Confirm the remediation script’s action is visible and explainable: for example, freed disk space matches the expected cleanup targets, not an unexplained change elsewhere on the device.
• Confirm no pilot device shows a script failure, timeout or unexpected exit code before widening scope.

#Common Mistakes

• Assigning the script pair straight to a production-wide group without a pilot ring, which turns any detection logic error into a fleet-wide incident.
• Writing a remediation script that fixes several unrelated symptoms at once, which makes failures difficult to attribute to a single cause.
• Treating a passing pilot run as permanent validation, without periodically re-checking that the detection threshold still matches current fleet conditions.
• Granting the account that authors remediation scripts the same privilege used to assign them to production groups.

#Recovery

If a remediation script produces an unexpected result on any pilot or production device, the immediate stop condition is to remove the device group assignment for that script pair in Intune, which halts further scheduled runs without needing to touch the affected devices directly. Do not attempt to write a second, corrective script while the original assignment is still active, as this risks stacking unverified changes.

• Unassign the Proactive Remediation package from the affected group as the first recovery action.
• Review the Intune run report for the affected devices to confirm no further scheduled runs occurred after unassignment.
• Where the remediation script altered a reversible state (for example, deleted temporary files), confirm with the device owner whether any expected files are missing; where it altered a non-reversible state, treat this as a incident requiring manual, device-by-device remediation rather than a further automated fix.
• Only re-enable the assignment after the script logic has been corrected and re-tested against the same isolated test devices used during initial validation.

#Measurable Outcome

Define success in terms that can be checked from Intune reporting rather than from anecdote. Reasonable observable measures include: the proportion of pilot devices where detection correctly identifies the condition without false positives; the proportion of remediation runs that complete without error; and the reduction, if any, in manually-raised tickets for the same symptom among pilot-group devices compared with the same period before the pilot, drawn directly from ticketing records rather than estimated. Do not report a specific percentage improvement or cost saving unless it is drawn from your own ticketing and Intune reporting data for the pilot period; this playbook does not assert a fixed improvement figure because no verified fleet data was supplied for this assignment.

#Checklist

1. Detection script tested read-only against known-good and known-bad isolated devices, with results recorded.
2. Remediation script tested against the same isolated devices, with its action confirmed to be limited to the intended condition.
3. Script pair assigned only to a named pilot group, not to a production-wide group.
4. Run schedule set explicitly, and role separation confirmed between script authoring and group assignment.
5. Pilot run reports checked for false positives, failures and unexpected exit codes before any scope expansion.
6. Recovery step (unassign the group) confirmed as understood and immediately actionable by the on-call engineer before go-live.
7. Ticketing and Intune run data agreed as the source of measurable outcome, before any wider rollout claim is made.