Patch Compliance Failing: 90+ Day Uptime, Missing Updates

LIMEHAWK - Managed IT

Home>Incident Reports>Patch Compliance Failing: 90+ Day Uptime, Missing Updates

Incident

Compliance audit flagged a healthcare client for "missing critical patches." 23 of 47 workstations showed patches downloaded but not installed. The audit report was damning: "49% of endpoints missing KB5034441 and KB5034763 — critical security updates." The client panicked. They were certain we'd pushed those updates months ago.

We pulled up WSUS. Every single machine showed "Installed — Pending Reboot." The patches were there. They'd been there for weeks, in some cases months. They were just waiting for a reboot that never came.

Problem identification

Fleet uptime analysis told the real story:

- highest uptime: 97 days — front desk workstation, "we never turn it off"
- average uptime: 34 days across 47 workstations
- compliance status: 0% — every "installed" patch was actually pending reboot
- root cause: Fast Startup + user behavior = months without real reboots

Windows 10's Fast Startup was the culprit. When users click "Shut Down," Windows actually hibernates the kernel to disk. The machine appears to power off, but it isn't a true reboot — the running kernel and session state are persisted and restored on the next boot. Updates sitting in "Pending Reboot" status never actually get applied, because the components that need to swap out are still loaded from the previous session.

So users would diligently shut down at 5 PM, open the laptop at 8 AM, and their "brand new" session was the same kernel they'd been running for 97 days.

Why standard solutions failed

We'd already configured Windows Update deadlines and auto-restart through policy. Here's why none of it worked:

- Active Hours: users had set 6 AM to 11 PM (essentially "never auto-restart")
- deadline forcing: would trigger at 2 AM, but laptops were in sleep mode (lid closed) — nothing happened
- user prompts: "Restart now" banners dismissed for weeks — users learned to click them away without reading
- smart scheduling: Windows picked "inactive times" when the laptop was asleep in a bag — no activity, no reboot

The fundamental problem: Windows Update can only restart a machine that's awake and online. Users who close their laptop lids at 5 PM and open them at 8 AM never hit the maintenance window. Ever.

Resolution

Needed to enforce reboots through a mechanism that actually controlled when machines restarted, regardless of Windows Update's "smart" scheduling. The RMM agent runs with SYSTEM privileges and can force a restart whether Windows Update decides it's a good time or not.

Why this works

The script uses WMI to query the actual kernel boot time — not the last "shutdown" time that Fast Startup fakes. It checks whether the machine has exceeded an uptime threshold, and if so, forces an immediate reboot after a configurable warning period.

Technical details:

1. Win32_OperatingSystem: returns the real LastBootUpTime — immune to Fast Startup hibernation
2. user session detection: uses quser to enumerate logged-in users, logs who was on the machine before the reboot
3. active user skip: optional $SkipIfUserActive flag to defer reboot if someone is actively working
4. warning period: configurable 5-minute warning gives users time to save work before reboot

Key insight: the RMM agent can wake a machine from sleep to run scheduled tasks. Combined with this script, machines that "never reboot" now reboot weekly — automatically, during off-hours, with no user action required. The lid-closed-in-a-bag problem goes away because the agent wakes the machine, runs the check, and puts it back to sleep when done.

Outcome

Deployed the script across the fleet with a 7-day uptime threshold. Within one week, every machine had rebooted at least once. Average uptime dropped from 34 days to 4 days. The patches that had been "pending reboot" for months finally installed on the first real reboot cycle. Re-ran the compliance scan: 100% compliant. Audit passed.

- average uptime before: 34 days (unpatched endpoints)
- average uptime after: 4 days (within policy threshold)
- compliance rate: 0% → 100%

Key takeaways

Takeaway

"Shut Down" doesn't mean reboot — Fast Startup hibernates the kernel, leaving pending patches stranded.

Takeaway

Windows Update deadlines only work if machines are awake during the maintenance window.

Takeaway

RMM-based enforcement catches the machines that slip through Windows Update's cracks.

Takeaway

uptime is a proxy for patch compliance — high uptime almost always means low actual install rate.

Need help with something like this? Contact us

• Automating CrushFTP Upgrades and In-Place Updates (Automation)

• PC Replacement: Zero Data Loss User Profile Migration (Automation)

• Winget for RMM: Silent Software Deployment at Scale (Automation)