From Ticket Volume to Proactive Remediation and a 13-Month Reporting History

Shape: one proactive remediation, detection script + remediation script, run in 64-bit PowerShell as SYSTEM - the spooler is a machine service, so a user-context script would either fail or get lucky depending on who was logged in.

Detection script contract:

• Query the Spooler service state.
• Exit 0 when Running - remediation does not run.
• Exit 1 when Stopped or StartPending - remediation runs.
• Keep to those two codes; anything else should be treated as a script error, not as a health signal, or you will remediate on a typo.

Remediation script: attempt a graceful Start-Service, wait, re-check, and write a clear line to output either way. If the service will not start, that is a genuine fault - let the script fail and surface in the remediation report rather than looping.

Schedule and reality: run daily at a fixed hour, not hourly. About a third of devices are offline for a week at a time, so the design must tolerate missed runs: the device catches up on next check-in, and the report shows 'without data' devices as a separate population from 'failed'. Do not read 'no data' as 'healthy'.

Licensing check before you build: confirm the fleet's licence (Windows Enterprise E3/E5 or Microsoft 365 E3/E5) actually covers proactive remediations; the script working is not the same as the feature being entitled.

Scope: target a pilot group of the 60 known-affected machines first, not all 3,000, so a bad script has a blast radius of 60.

Refuse to automate: deleting user files, moving user data, or any cleanup whose safety depends on guessing what a file is. A script running as SYSTEM that removes 'large files' will eventually delete something a finance user needed, and no time saved on 90 tickets is worth that.

Automate only deterministic, vendor-safe cleanup:

• Temp files in known system locations older than N days.
• Delivery Optimization cache, which has a supported cmdlet for clearing it.
• Windows Error Reporting queues and stale update leftovers.
• Per-user temp folders: loop the profiles explicitly, because SYSTEM's own %TEMP% is not the user's - a common reason a disk script reports success while the disk stays full.

Report rather than act: if the drive is still under threshold after safe cleanup, exit non-zero with the top offenders in the output so the service desk has the diagnosis in the ticket instead of starting from scratch.

Threshold judgement: do not set the detection threshold at exactly 10 GB - a device at 10.1 GB flips in and out of scope on every run and you get alert noise. Use a lower remediation threshold and a higher report threshold.

Feedback loop: track remediation success rate over a month. If the same devices keep needing cleanup, the root cause is a profile or cache problem, not disk hygiene, and the remediation is masking it.

Out of the box: Intune reports (including Windows Update compliance) have short retention - roughly a month for many reports - and no site dimension. Weekly CSV exports give you no trend and no audit trail. This requirement is not met by the portal.

What to build:

1. Diagnostic settings on Intune exporting to the existing Log Analytics workspace. That gets device, compliance, and update data into queryable tables and outlives the portal retention.
2. Retention: set the workspace retention to at least 13 months (default interactive retention is 90 days; longer retention or long-term retention costs money - price it before promising 13 months).
3. Per-site dimension is the hard part. Site/location is not a first-class Intune property. Options, cheapest first:
   • Sync an AD site value into an Entra ID extension attribute and derive device groups per site; filter reports by group. Low maintenance, limited to portal/report filtering.
   • Query the exported data by device name prefix if your naming convention encodes site - free, but only works if naming is disciplined.
   • Deploy a small inventory script writing site to a registry value and collect it - most accurate, most maintenance. Pick based on how often sites change; naming convention plus group filters usually wins.
4. Dashboard: an Azure Monitor workbook or Power BI report on top of the workspace, scheduled and emailed, replacing the Monday CSV.

Startup score: address the 40 percent separately. Endpoint analytics drills down to per-device boot time and startup processes, so you can confirm or clear the third-party agent with evidence. Note that the score only improves if devices actually restart - which depends on the update ring deadlines you control.