Engineering Out the Slow Laptop Ticket with Proactive Disk Remediation
Stop manual disk cleanup tickets by deploying Intune Proactive Remediation scripts that detect, self-heal, and escalate low disk space automatically.

Operational brief
Operational outcome
Stop manual disk cleanup tickets by deploying Intune Proactive Remediation scripts that detect, self-heal, and escalate low disk space automatically.
Target Tier
L1 support
Implement within an approved test scope before wider deployment.
Time to set aside
About 35 minutes
Includes configuration, validation and deployment.
Tutorial navigation
The Old Way: a user emails the helpdesk saying their laptop has “gone slow”, a technician remotes in, opens Disk Cleanup, watches a progress bar for ten minutes, manually runs the Storage Sense wizard, empties the Recycle Bin, deletes the Windows Update cache by hand, and closes the ticket feeling like a janitor. Multiply that by every device in the estate every few months and you have a permanent, low-value ticket category eating technician hours that could go towards actual engineering work.
The New Way: disk space starvation is detected and fixed on the device itself, before the user notices any slowdown, using a paired detection and remediation script running on a schedule through a Digital Employee Experience (DEX) platform such as Microsoft Intune Proactive Remediations. The device reports its own health telemetry back to a webhook. A human technician is only pulled in when the automated fix genuinely fails. This article builds that pipeline end to end.
#The Everyday Problem: Disk-Space Slowness Tickets
Low free disk space is one of the highest-volume, lowest-value ticket categories in any L1 queue. Symptoms reported by users are vague (“my laptop is slow”, “Teams keeps freezing”, “Windows Update won’t install”) but the root cause is frequently the same: the system drive has dropped below the threshold Windows needs for paging, temp file writes, and update staging. Manual diagnosis wastes time because the technician has to reproduce the complaint, connect remotely, and run cleanup tools reactively, days or weeks after the problem started.
DEX tooling flips this from reactive to proactive: every managed endpoint checks its own free space on a schedule, self-heals when it can, and only raises a ticket when self-healing is insufficient. This is the definition of engineering a ticket out of existence rather than resolving it faster.
#Prerequisites and Permissions
- Microsoft Intune tenant with devices enrolled in Endpoint Manager (Azure AD joined or hybrid joined Windows 10/11 devices).
- An account assigned the built-in Intune role “Endpoint Security Manager” or “Intune Administrator” scoped to a pilot device group only, not tenant-wide, for the initial rollout.
- A Log Analytics workspace (or equivalent SIEM) if you want centralised querying of remediation outcomes, plus a Logic App or Power Automate flow acting as the webhook receiver.
- A pilot Azure AD security group of no more than 25 devices, used exclusively for staged testing before wider assignment.
- PowerShell 5.1 or later on target endpoints (default on supported Windows builds), and script execution permitted under the Intune management extension context, which runs as SYSTEM.
- Change management sign-off, because this remediation script deletes files and runs DISM component cleanup, both of which are irreversible actions on the endpoint.
#Implementation Steps
-
Action: Write the detection script that checks free space on the C: drive against a defined threshold.
Expected result: The script exits with code 1 when free space is below threshold (triggering remediation) and exit code 0 when healthy.
Evidence to capture: Local console output showing the calculated free space value during manual testing.
1$ThresholdGB = 15 2$Drive = Get-PSDrive -Name C 3$FreeGB = [math]::Round($Drive.Free / 1GB, 2) 4 5if ($FreeGB -lt $ThresholdGB) { 6 Write-Output "Free space is $FreeGB GB, below threshold of $ThresholdGB GB." 7 exit 1 8} else { 9 Write-Output "Free space is $FreeGB GB, healthy." 10 exit 0 11} -
Action: Write the remediation script that clears temp locations, empties the Recycle Bin, runs a DISM component store cleanup, purges the Windows Update download cache, and posts a telemetry payload to a webhook.
Expected result: Free space increases, a local log file is written, and a JSON payload reaches the webhook endpoint.
Evidence to capture: The contents of the log file and a successful HTTP 202 response from the webhook.
1$LogPath = "C:\ProgramData\KBYOps\DiskRemediation.log" 2$WebhookUrl = "https://prod-00.westeurope.logic.azure.com:443/workflows/REPLACE_ME/triggers/manual/paths/invoke" 3 4function Write-Log { 5 param([string]$Message) 6 $Timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss" 7 Add-Content -Path $LogPath -Value "$Timestamp - $Message" 8} 9 10New-Item -Path (Split-Path $LogPath) -ItemType Directory -Force | Out-Null 11 12$BeforeGB = [math]::Round((Get-PSDrive C).Free / 1GB, 2) 13Write-Log "Remediation started. Free space before: $BeforeGB GB" 14 15Get-ChildItem -Path "C:\Windows\Temp\*" -Recurse -Force -ErrorAction SilentlyContinue | Remove-Item -Recurse -Force -ErrorAction SilentlyContinue 16 17Get-ChildItem -Path "$env:TEMP\*" -Recurse -Force -ErrorAction SilentlyContinue | Remove-Item -Recurse -Force -ErrorAction SilentlyContinue 18 19Clear-RecycleBin -DriveLetter C -Force -ErrorAction SilentlyContinue 20 21Start-Process -FilePath "Dism.exe" -ArgumentList "/Online /Cleanup-Image /StartComponentCleanup /Quiet" -Wait -NoNewWindow 22 23Stop-Service -Name wuauserv -Force -ErrorAction SilentlyContinue 24Remove-Item -Path "C:\Windows\SoftwareDistribution\Download\*" -Recurse -Force -ErrorAction SilentlyContinue 25Start-Service -Name wuauserv -ErrorAction SilentlyContinue 26 27$AfterGB = [math]::Round((Get-PSDrive C).Free / 1GB, 2) 28$Reclaimed = [math]::Round($AfterGB - $BeforeGB, 2) 29Write-Log "Remediation finished. Free space after: $AfterGB GB. Reclaimed: $Reclaimed GB" 30 31$Payload = @{ 32 device = $env:COMPUTERNAME 33 user = $env:USERNAME 34 beforeGB = $BeforeGB 35 afterGB = $AfterGB 36 reclaimedGB = $Reclaimed 37 status = if ($AfterGB -lt 15) { "ESCALATE" } else { "RESOLVED" } 38 timestamp = (Get-Date).ToString("o") 39} | ConvertTo-Json 40 41try { 42 Invoke-RestMethod -Uri $WebhookUrl -Method Post -Body $Payload -ContentType "application/json" -TimeoutSec 15 43 Write-Log "Webhook posted successfully." 44} catch { 45 Write-Log "Webhook post failed: $($_.Exception.Message)" 46} 47 48if ($AfterGB -lt 15) { 49 Write-Output "Remediation ran but free space still $AfterGB GB. Escalation required." 50 exit 1 51} else { 52 Write-Output "Remediation successful. Free space now $AfterGB GB." 53 exit 0 54} -
Action: In the Intune admin centre, navigate to Devices then Scripts and remediations, and create a new Proactive Remediation package, uploading the detection script and remediation script as the paired scripts, run context set to “System”.
Expected result: The script pair appears in the remediation list with a status of “Not yet assigned”.
Evidence to capture: Screenshot of the package configuration page showing both script names and run context.
-
Action: Assign the package to the pilot Azure AD group only, with a schedule of daily at logon plus an hourly recurring check for the first week.
Expected result: Pilot devices show a run history entry within 24 hours in the Intune reporting blade.
Evidence to capture: Run status export from Intune (CSV) showing detection and remediation exit codes per device.
-
Action: Configure a Power Automate flow (or Logic App) as the webhook receiver that parses the JSON payload and, when status equals “ESCALATE”, creates a ticket in the ITSM tool with severity flagged for L2.
Expected result: Only devices that remain below threshold after remediation generate a ticket; healthy remediations generate a log entry only.
Evidence to capture: Sample ticket created from a deliberately induced low-disk test device.
1{ 2 "device": "LT-KBY-00542", 3 "user": "j.olusanya", 4 "beforeGB": 8.42, 5 "afterGB": 11.9, 6 "reclaimedGB": 3.48, 7 "status": "ESCALATE", 8 "timestamp": "2024-05-14T09:12:03.0000000Z" 9} -
Action: Run a manual pilot test by filling a test VM’s C: drive with dummy files down to under 15GB free, then trigger an on-demand remediation from the Intune device blade.
Expected result: Free space increases and the device disappears from the “non-compliant” remediation report within one polling cycle.
Evidence to capture: Before and after screenshots of Get-PSDrive output plus the Intune run report timestamp.
-
Action: Expand assignment from the pilot group to a broader ring (for example, one regional office) over a two-week period, monitoring failure rate daily.
Expected result: Remediation success rate stays above 95 percent with no unexpected application breakage reported.
Evidence to capture: Weekly rollout report comparing ring size, success rate, and any rollback events.
-
Action: Once stable, assign to “All managed Windows devices” and remove the pilot-only scope restriction.
Expected result: Fleet-wide daily disk health becomes self-managing with no manual technician involvement for the common case.
Evidence to capture: Tenant-wide compliance dashboard showing remediation coverage percentage.
#Verification and Expected Evidence
Confirm the pipeline is working correctly using these checks:
- In Intune, Devices then Scripts and remediations then the package, the “Device status” report should show a majority of devices reporting “Issue not detected” (meaning free space is healthy) and a small remediated subset reporting “Issue detected and fixed successfully”.
- Query the local log on a sample device to confirm reclaimed space figures are plausible (typically 2 to 10 GB depending on update cache age).
- Confirm the webhook receiver’s run history shows successful HTTP 200 or 202 responses correlated with the remediation script’s execution timestamps.
- In the ITSM tool, confirm no ticket was created for devices that returned to a healthy state, and that a ticket was created only for the deliberately-failed test case.
1Get-Content -Path "C:\ProgramData\KBYOps\DiskRemediation.log" -Tail 512024-05-14 09:12:01 - Remediation started. Free space before: 8.42 GB
22024-05-14 09:12:03 - Remediation finished. Free space after: 11.9 GB. Reclaimed: 3.48 GB
32024-05-14 09:12:04 - Webhook posted successfully.#Rollback
If the remediation script causes unexpected side effects (for example, an application that relies on a persistent temp cache breaks after cleanup), take these steps:
- In Intune, remove the device group assignment from the Proactive Remediation package immediately; this halts further script executions within one sync cycle (typically under 8 hours, or immediately with a forced sync).
- Force an immediate sync on affected pilot devices via the Company Portal app or Intune’s “Sync” device action to confirm the policy has been withdrawn.
- Restore any affected application cache from its normal first-run regeneration behaviour; DISM component cleanup and temp file deletion are not reversible, so rollback is scope reduction, not data restoration.
- Document the specific application and failure symptom before re-enabling, and add an exclusion path to the remediation script’s cleanup targets if that folder should never be purged.
#Failure and Escalation Conditions
The automation is designed to escalate itself. The conditions that should wake a human technician are:
- The remediation script returns exit code 1 after running (meaning free space remains below 15GB even after cleanup) — this indicates a genuine storage problem, likely a large user profile, oversized OneDrive cache, or a failing/undersized disk, and needs an L2 technician to review disk usage manually.
- The webhook fails to receive payloads from more than 5 percent of a ring’s devices over a 24-hour period — this points to a network or Logic App outage and should be investigated before wider rollout continues.
- DISM component cleanup returns a non-zero exit code on more than a handful of devices — this can indicate corrupted component store health and needs an L2/L3 technician to run a full DISM health scan.
- Blast radius for any single automated run is one device; the script never touches network shares, other drives, or user document folders, only defined temp and cache locations, so a single bad run cannot cascade across the fleet.
#Measuring Ticket Deflection
To prove this pipeline is actually reducing ticket volume rather than just moving effort around, track the following before and after full rollout:
- Baseline: count of tickets tagged “performance”, “slow laptop”, or “disk full” per month for the three months prior to rollout.
- Post-rollout: same ticket tags for the three months after full fleet assignment.
- Remediation coverage: percentage of the fleet with at least one automated remediation event per month, pulled from the Intune reporting export.
- Escalation rate: percentage of remediation runs that resulted in an ITSM ticket (target under 3 percent); this is your genuine “needs a human” rate.
1Ticket volume, disk/performance category:
2Before rollout (3-month average): 142 tickets/month
3After rollout (3-month average): 19 tickets/month
4Deflection rate: approximately 87 percentPresent this as a simple monthly KPI to leadership: tickets deflected equals technician hours returned to engineering work rather than repetitive cleanup tasks.
#References
For platform configuration details, consult Microsoft’s official documentation on Intune Proactive Remediations and the PowerShell reference for the Clear-RecycleBin cmdlet.
Sources and verification
Vendor documentation and external technical references used by this playbook.
Advanced suggested reading
Ready to go deeper?
These articles come from KBY’s senior engineering editorial. Expect denser architecture, fewer introductory explanations and deeper production trade-offs.
Tech Fundamentals
Diagnosing DHCP Starvation Attacks at Home
How forged CHADDR floods exhaust home DHCP pools, and the tcpdump signatures, dnsmasq tuning, and switch-level snooping that stop a DHCP starvation attack.
Systems Engineering
Killing Cache Stampedes with Request Coalescing
How to stop cache stampede events using singleflight, Redis locking, and probabilistic early expiration in read-through caching architectures.
Comments
Add a thoughtful note on Engineering Out the Slow Laptop Ticket with Proactive Disk Remediation. Comments are checked for spam and held for moderation before appearing.