New / Open / Unreviewed

[Feature]: [Feature]: Improve Windows update and reboot detection

What is the installation method of your PatchMon server?

Docker

What is the version of your PatchMon server?

2.02

Briefly describe the feature

Improve Windows update compliance detection for Windows hosts by handling Microsoft Defender Security Intelligence updates and reboot detection more intelligently.

Detailed description

After testing PatchMon with several Windows Server 2019 systems, I noticed two situations that generate false-positive compliance information.

Microsoft Defender Security Intelligence Updates (KB2267602)

Microsoft Defender updates its signatures automatically, but Windows Update frequently reports a new KB2267602 update shortly afterwards.

This causes PatchMon to report a pending update even though Defender is already up to date, resulting in Windows hosts appearing permanently non-compliant.

Possible solutions:

Allow ignoring specific Windows KBs (e.g. KB2267602)
Allow excluding updates by title or regex
Optionally ignore Defender Security Intelligence Updates completely

Reboot detection

PatchMon reports "Needs Reboot" when only PendingFileRenameOperations exist.

In my case these entries are created by the Windows Print Spooler (V4Dirs / printer driver cleanup) after an RDP session with printer redirection.

Windows itself does not report Windows Update reboot pending, but PatchMon still reports the host as requiring a reboot.

It would be useful if PatchMon distinguished between:

Windows Update reboot required
Component Based Servicing reboot required
PendingFileRenameOperations only

or at least made the reboot reason visible in the UI.

Why is this useful?

This would significantly reduce false positives on Windows servers.

Currently Windows hosts can appear permanently non-compliant because of Defender signature updates or harmless PendingFileRenameOperations, making it difficult to identify systems that actually require administrator action.

1 Comment

Thomas Carlin·1 day ago

Wanted to add some diagnostics to this, as it is affecting me as well. Happy to help with this agent, but i am not a programmer by any employment or training, and i have never contributed to an open source project.

Summary

Adding data from a Windows 11 Pro 25H2 host (26200.9168) running agent 2.1.3, 28 days of logs at update_interval: 15.

Result: 2198 of 2198 reboot checks reported needs_reboot=true. Zero false results, including the first check after each of 5 real restarts. 2194 of them had the reason "Pending file rename operations" alone.

time="2026-09-07T19:26:01" level=info msg="Reboot status check completed" installed_kernel= needs_reboot=true reason="Pending file rename operations" running_kernel="10.0.26200.9168 Build 26200.9168"

Live state at that moment (8 days uptime): CBS RebootPending/PackagesPending, WU RebootRequired, WUA SystemInfo.RebootRequired, pending rename, and pending domain join were all false. PendingFileRenameOperations held 18 entries, none from OS servicing: Brave updater temp files, Edge updater folder, Office Click-to-Run update folders, Office preview fonts, print spooler V4Dirs, and an MSI .rbf. App updaters re-queue these constantly, so the key is effectively never empty on a desktop.

What works: the "Windows Update requires reboot" reason fired correctly before the KB5121003 reboot on 08-11 and cleared after it. Only the PFRO heuristic is wrong.

Suggestions:

Don't let PendingFileRenameOperations alone set needs_reboot=true. If kept, only count targets under %SystemRoot% excluding fonts, spool, Installer, Temp, and drop it to a separate advisory flag.
Populate installed_kernel on Windows from CurrentBuildNumber + UBR and compare to running_kernel. This would have shown 9168 installed vs 8875 running on 08-11.
Run a check at service start and on WindowsUpdateClient event 19. Two driver-update restarts here happened within 60 s of install, between two 15-minute polls, so the WU reason never appeared.