Silencing Slow-Boot Complaints With Telemetry-Triggered Remediation

The old way of handling a slow-boot complaint goes something like this: a user calls in and says their laptop “takes forever” to start. The technician asks them to time it with a phone stopwatch, remotes in once the user is finally logged on, opens Task Manager’s Startup tab, eyeballs a list of fourteen enabled entries with no impact data attached, disables two or three at random based on gut feeling, and closes the ticket with a note to “monitor and reopen if it happens again.” It almost never gets reopened. It just gets worse, quietly, boot after boot, until the device is replaced a year early because it “always felt slow.”

The new way treats boot time as a metric that Windows is already collecting for you, not a complaint that has to be manually investigated after the fact. Every startup writes a structured performance event to the local event log, complete with a millisecond-accurate boot duration. Instead of waiting for a frustrated employee to notice and dial the helpdesk, you read that event on a schedule, compare it against a baseline, and let an automated remediation script strip out the startup bloat before anyone reaches for the phone. The ticket gets engineered out of existence before it is ever typed.

#Prerequisites and Permissions

• Windows 10 22H2 or Windows 11 devices enrolled in Microsoft Intune, or any MDM platform capable of running paired detection and remediation scripts on a schedule.
• Minimum role: an Intune role with Remediations: Read, Write and Device Configurations: Read permissions (built-in “Endpoint Security Manager” satisfies this; do not grant Global Administrator for this task).
• Scripts execute as SYSTEM through the Intune Management Extension, so no interactive administrator session is required on the endpoint itself.
• Confirm the source log exists and is enabled by default: Microsoft-Windows-Diagnostics-Performance/Operational. This is present on every supported Windows build without additional licensing.
• Test scope: a pilot group of no more than 50 devices in a dedicated Entra ID dynamic group before any tenant-wide assignment.
• Blast radius: the remediation only touches HKCU and HKLM Run keys and logon-triggered scheduled tasks that are not on an explicit allow list. It never stops services tied to domain join, EDR agents, disk encryption, or VPN posture checks.

#Implementation Steps

1. Action: Confirm the performance diagnostics log is populated on a representative test device by running Get-WinEvent -LogName 'Microsoft-Windows-Diagnostics-Performance/Operational' -FilterXPath '*[System[EventID=100]]' -MaxEvents 5.
   Expected result: at least five Event ID 100 entries are returned, each containing a BootTime field expressed in milliseconds.
   Evidence: capture the console output showing five timestamped events; if none appear, escalate to check Group Policy log retention settings before proceeding.
2. Action: Author the detection script that averages the last five boot times and flags a regression above a 60-second threshold.
   Expected result: the script exits 1 (non-compliant) when the average exceeds the threshold and exits 0 otherwise.
   Evidence: the script’s own Write-Output line, captured in the Intune remediation report per device.
   PowerShell

   1$thresholdMs = 60000
   2$events = Get-WinEvent -LogName 'Microsoft-Windows-Diagnostics-Performance/Operational' -FilterXPath '*[System[EventID=100]]' -MaxEvents 5 -ErrorAction SilentlyContinue
   3
   4if (-not $events) {
   5    Write-Output 'No boot performance events found in the last 5 boots.'
   6    exit 0
   7}
   8
   9$bootTimes = foreach ($event in $events) {
   10    [xml]$xml = $event.ToXml()
   11    $data = $xml.Event.EventData.Data | Where-Object { $_.Name -eq 'BootTime' }
   12    [int]$data.'#text'
   13}
   14
   15$averageBootMs = ($bootTimes | Measure-Object -Average).Average
   16
   17if ($averageBootMs -gt $thresholdMs) {
   18    Write-Output "Boot time regression detected. Average: $([math]::Round($averageBootMs / 1000, 1)) seconds over $($bootTimes.Count) boots."
   19    exit 1
   20} else {
   21    Write-Output "Boot time within tolerance. Average: $([math]::Round($averageBootMs / 1000, 1)) seconds."
   22    exit 0
   23}

   Example expected output on a healthy device: Boot time within tolerance. Average: 34.2 seconds.

3. Action: Author the remediation script that removes non-essential startup entries and defers logon-triggered scheduled tasks not present on an explicit allow list.
   Expected result: only allow-listed entries survive; Delivery Optimization is set to manual start to stop it competing for disk I/O during boot.
   Evidence: the list of removed entries and disabled tasks printed to stdout, which Intune stores against the device record.
   PowerShell

   1$allowList = @('SecurityHealthSystray', 'OneDrive', 'Teams')
   2$runKeys = @(
   3    'HKCU:\Software\Microsoft\Windows\CurrentVersion\Run',
   4    'HKLM:\Software\Microsoft\Windows\CurrentVersion\Run'
   5)
   6
   7$startupApps = Get-CimInstance -ClassName Win32_StartupCommand | Select-Object Name, Command, Location, User
   8
   9foreach ($app in $startupApps) {
   10    if ($allowList -notcontains $app.Name) {
   11        foreach ($key in $runKeys) {
   12            if (Test-Path $key) {
   13                $property = Get-ItemProperty -Path $key -Name $app.Name -ErrorAction SilentlyContinue
   14                if ($property) {
   15                    Remove-ItemProperty -Path $key -Name $app.Name -ErrorAction SilentlyContinue
   16                    Write-Output "Removed startup entry: $($app.Name)"
   17                }
   18            }
   19        }
   20    }
   21}
   22
   23Stop-Service -Name 'DoSvc' -Force -ErrorAction SilentlyContinue
   24Set-Service -Name 'DoSvc' -StartupType Manual -ErrorAction SilentlyContinue
   25
   26$logonTasks = Get-ScheduledTask | Where-Object { $_.Triggers.TriggerType -contains 'AtLogon' }
   27foreach ($task in $logonTasks) {
   28    if ($allowList -notcontains $task.TaskName) {
   29        Disable-ScheduledTask -TaskName $task.TaskName -TaskPath $task.TaskPath -ErrorAction SilentlyContinue
   30        Write-Output "Disabled logon-triggered task: $($task.TaskName)"
   31    }
   32}
   33
   34exit 0

4. Action: Package both scripts as a Proactive Remediation in Intune, either through the portal or via Graph, and schedule an hourly run with a daily user-context option disabled (SYSTEM context only).
   Expected result: a new deviceHealthScript object exists in the tenant with detection and remediation content encoded and a schedule of hourly, interval: 1.
   Evidence: the Graph response body containing the generated script ID.
   JSON payload

   1{
   2  "displayName": "Boot Time Regression Auto-Remediation",
   3  "description": "Detects average boot time above 60s over last 5 boots and strips non-essential startup entries",
   4  "publisher": "DEX Engineering",
   5  "runAsAccount": "system",
   6  "detectionScriptContent": "BASE64_ENCODED_DETECTION_SCRIPT",
   7  "remediationScriptContent": "BASE64_ENCODED_REMEDIATION_SCRIPT",
   8  "roleScopeTagIds": ["0"]
   9}

5. Action: Assign the remediation to the pilot Entra ID group only, with a schedule frequency of every 1 hour for the first 7 days.
   Expected result: the Intune remediation status report shows a mix of “Issue detected and resolved” and “No issue detected” states, with zero “Issue detected, not resolved” entries above 2% of the pilot population.
   Evidence: the per-device remediation report exported as CSV from the Intune console.
6. Action: Wire a failure-escalation path so a human is only paged when automation genuinely cannot fix the problem, not on every run. Configure a Log Analytics alert rule that fires when a device reports remediation attempted twice with no improvement, and route it through a Power Automate flow to create a ServiceNow incident.
   Expected result: a single incident is created per persistently failing device, tagged for L2 triage, rather than a ticket per boot.
   Evidence: the incident payload received by ServiceNow, matching the schema below.
   JSON payload

   1{
   2  "short_description": "Boot time regression persists after two automated remediation attempts",
   3  "description": "Device DESKTOP-4F2K91Q recorded an average boot time of 92.4 seconds across the last 5 startups. Proactive Remediation attempted startup cleanup twice with no improvement below the 60-second threshold.",
   4  "category": "Hardware",
   5  "subcategory": "Performance",
   6  "urgency": "3",
   7  "impact": "3",
   8  "assignment_group": "DEX Engineering",
   9  "cmdb_ci": "DESKTOP-4F2K91Q",
   10  "u_source_system": "Intune Proactive Remediation",
   11  "u_average_boot_ms": 92400,
   12  "u_threshold_ms": 60000,
   13  "u_remediation_attempts": 2
   14}

#Verification and Expected Evidence

Verification happens on two levels: per-device and fleet-wide. At the device level, re-run the detection script manually after a scheduled remediation cycle and confirm it now exits 0. Capture the console line showing the reduced average boot time as evidence attached to the pilot change record.

At the fleet level, build a Log Analytics workbook that plots average boot time per device group over a rolling 14-day window. Expect to see the pilot group’s median boot time fall below the 60-second threshold within the first 3 to 5 days as accumulated startup bloat is cleared out. A device that never trends downward despite successful remediation runs is a candidate for hardware-level investigation, not a script bug.

#Rollback

If the remediation disables something business-critical, for example a VPN client’s posture-check helper that was not added to the allow list in time, recovery is immediate and low-risk:

1$appName = 'ExampleVpnHelper'
2$appCommand = 'C:\Program Files\VendorVPN\helper.exe'
3Set-ItemProperty -Path 'HKLM:\Software\Microsoft\Windows\CurrentVersion\Run' -Name $appName -Value $appCommand -Force
4Write-Output "Restored startup entry: $appName"

For a broader rollback, disable the remediation’s assignment in Intune, which halts future runs immediately, and use the remediation’s version history to revert to the previous script revision rather than editing in place. Because the remediation only ever removes Run key entries and disables scheduled tasks, no reboot or reimage is required to reverse its effects; a single script run or manual registry restore is sufficient.

#Failure and Escalation Conditions

• If the detection script itself errors out for a reason unrelated to boot time, such as access denied reading the event log, flag the device for manual triage rather than allowing silent retries beyond 3 cycles.
• If remediation completes successfully but boot time has not improved after two consecutive cycles, escalate to L2 for a driver or storage-health investigation using the ServiceNow payload shown above rather than continuing to run the same fix.
• Human wake condition: more than 5% of the pilot group failing remediation twice within 24 hours, or any single device exceeding 180 seconds average boot time, which points to a hardware fault rather than startup bloat and should page the on-call DEX engineer directly.
• Monitoring signal: a Log Analytics alert rule on the custom telemetry table where AverageBootMs_d greater than 60000 and RemediationAttempts_d greater than or equal to 2.
• Rollback trigger: a spike in unrelated helpdesk tickets referencing missing tray icons or failed VPN connections immediately following a remediation rollout, which indicates an allow-list gap rather than a scripting fault.

#Measuring Ticket Deflection

Establish a 90-day baseline of tickets categorised as Performance with free-text matches for “slow to start,” “boot,” or “startup” before deployment. After rollout, track the same category weekly and calculate a deflection rate using (Baseline Weekly Average minus Current Weekly Average) divided by Baseline Weekly Average. Pair that figure against the percentage of the fleet covered by the remediation and the Intune “Issue detected and resolved” rate; a rising resolved-rate with a falling ticket count is the causal signal you want, not just a seasonal dip. Most teams running this pattern for 90 days on a full fleet see startup-related ticket volume fall by 60 to 80 percent, because the fix now runs before the employee finishes their coffee, not after they have already dialled the helpdesk.