patch agent marked wave complete while half the hosts still showed pending reboot

TL;DR

A wave is not complete when installs finish; it is complete when hosts have installed, rebooted, and verified healthy after the reboot. Fix the agent completion rule: pending reboot is an open state that keeps the wave in progress, the agent tracks reboots to completion or to an escalation deadline, and the final wave report separates installed-and-verified from installed-awaiting-reboot. Then chase the pending reboot population down with scheduled restarts instead of discovering it at the next wave.

patch agent marked wave complete while half the hosts still showed pending reboot

Use this when

• Wave reports say complete while dashboards or host checks show many wave hosts still pending reboot days later.
• The next wave finds previous updates still not committed on the same hosts.
• Hosts are servers or shared machines whose reboots nobody owns after the agent finishes installing.

Not for this skill when

• Hosts failed the install and need repair. They are not pending reboot; they belong in the failed workflow.
• A deliberate design closes waves at install and tracks reboots in a separate program. Then the report must say so, and this skill is about that reporting gap instead.

Steps

1. Quantify the hidden population: for the last closed wave, check every host present state directly - update installed, reboot pending flags, and uptime - and count how many complete hosts were actually still awaiting reboot at closure and how many still are now. This number is the size of the reporting lie to fix. Verify: you have the count and list of hosts that were pending reboot at wave closure and their current state
2. Change the wave state model: add installed-awaiting-reboot as an explicit non-complete state, and make wave completion require every host to reach installed-and-verified, failed, skipped with reason, or an escalated exception approved by a human. The agent should refuse to write a complete status while open states remain, and say which hosts block closure. Verify: a test wave with one host held in pending reboot cannot be marked complete and names that host as the blocker
3. Make the agent drive reboots to closure: within the wave policy, the agent schedules or requests the reboot in the host approved window, detects the reboot actually happened by uptime and boot time change, and then runs the post-reboot verification - update present, services healthy - before moving the host to verified. Verify: a test host moves from awaiting reboot to verified only after a detected reboot and a passing post-reboot check
4. Escalate the stubborn tail on a clock: hosts still pending reboot after the wave deadline are escalated as a named list to their owners with the risk stated plainly - the patch is not protecting them until the reboot commits it - and they remain visible on an exceptions report rather than vanishing into a closed wave. Verify: an exceptions report lists overdue pending reboot hosts with owners and age, and it empties only by reboot or by a signed risk acceptance
5. Restate recent wave history honestly: annotate the last few wave reports with their true verified counts alongside the original installed counts, so trend lines and audits are not built on inflated completion. Keep both numbers; the point is a truthful record, not rewriting history. Verify: recent wave reports show installed and verified figures side by side with the difference explained

Why it happens

Many patches only take effect when the machine reboots: files in use are replaced at boot and the new code starts running then. Until that reboot, the vulnerability the patch fixes is still live, even though the install step succeeded. Agents that model completion as install success close waves with a large invisible tail of uncommitted hosts, and because the wave is closed, nobody is assigned to chase the reboots. The hosts are often the most sensitive ones - busy servers whose reboots need coordination. Treating pending reboot as an open, owned, escalating state keeps the safety claim honest and gives the tail the operational attention it needs.

Variants and edge cases

Hosts pending reboot because users keep deferring

Workstations with user deferral need deadline and notification policy, not just agent tracking. Align the agent escalation with the deferral limits set in your update policy.

Pending reboot flag is stuck, not real

Some hosts show a permanent pending flag from a stuck source. The agent post-reboot check should include the flag-source diagnosis from the pending reboot skill so a stuck flag does not block a host forever.

Reboots happen but the agent does not notice

If the agent only checks during windows, it misses reboots done manually. Poll boot time periodically for awaiting hosts so manual reboots close their state promptly.

Compatibility: Applies to patch agents for Windows fleets where updates require reboots, integrated with WSUS, Configuration Manager, Intune, or custom trackers.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_92OApSh68qMDm4VOxQ2Y1A