Patching: OS, apps, and CVE

A simple patching model — four layers, one question each. OS ≠ apps ≠ vulnerabilities ≠ job log. On Patch OS, Software, CVE and History the same OS / Software / CVE / History strip switches layers.

Map in 30 seconds

I want to…	Go to…	Note
Fix Windows / OS patches	RMM → Updates → Patch OS	Approve KBs, install in a maintenance window
Update applications (Chrome, 7-Zip, …)	RMM → Software (apps) or device → Apps	Needs a package ID or the software catalog
See what is vulnerable	Security → CVE registry → To fix	Risk triage — not the full upgrade list
Check whether a job ran	CVE/Software queue panel (control) or Updates → Operations history	Queue = Cancel (pending). History = log only

Golden rule: CVE answers what is dangerous. Apps answer what can be upgraded. History answers what already started.

1. OS patching (Windows Update)

1. RMM → Updates (fleet) or device Workbench → Updates (deep-link /rmm/updates/devices).
2. Filter the device list by company (MSP) and device group, then pick a host. The LED next to the host is green = online, red = powered off / offline. A ?deviceId= deep-link opens that device even when it is not on the current list page.
3. Scan → Approve KBs (or auto-approve in policy) → install in a maintenance window. If Windows is waiting for a reboot and the group does not have “Manual restart only”, the same window reboots the PC to finish patches, then the next cycle installs the rest. If the PC was off during the window, install and auto-reboot wait for the next window — not first login.
4. After Install updates the button stays disabled and reads Install in progress, and a status line above the summary shows the job was sent to the agent. A second click while that job is queued or running does not start another install. It stays that way until History gets a result (Success, Failed, In progress) or the install finishes. While an install is already running, that same line shows the stage: Scanning, Planning, Downloading, Installing, Finishing, or Restart required — often with a KB preview. That is not the same as a History row stuck on In progress after a cumulative reboot. History status is a chip (Failed is red).
5. If Windows is already waiting for a restart, the next install does not start (including Defender definitions). A note appears above the queue, Install updates offers Restart device, and History shows Waiting for restart instead of a raw failure. The alert says the same thing: restart first, then install again.
6. The History panel shows recent OS scans/installs; Full history opens Operations filtered to that device (scan + install). The KB queue, the count badge (red = at least one Critical severity, yellow = pending with no critical — e.g. optional; Security alone does not turn the badge red) and history refresh in the background — after an install, KBs leave the queue once the agent rescans; the job stays in History (a log, not the queue). The fleet strip (“critical / security”) is a different counter than the badge colour.
7. History is not a copy of Control Panel → Installed updates. It is the agent job log. A Windows cumulative update often reboots the PC before the agent reports the result, so the row stayed In progress; after reboot, a scan closes that job when the KB is no longer pending. Windows may also install an SSU or other dependency that was never on the job list.
8. This does not update Chrome or other applications outside Windows Update.

Approve / windows details: Policies and maintenance windows.

2. Application patching (Software)

On one PC / fleet hub

1. RMM → Updates & Patch → Software (apps) (/rmm/updates/software).
2. Fleet tab — available upgrades across many PCs (package manager and software catalog); Channel column. MSP: Company filter and column (same as Alerts / Patch OS); optional channel filter. You update selected rows or a single row, after confirmation (the agent will close that app’s processes). There is no one-click update for the whole fleet — that belongs to auto-update in the maintenance window.
3. Installed tab — a map, not the queue. Type a name (for example Wapro Kaper) and see which computers have it, with the version. A Windows registry program without a package manager shows Update by hand: the panel shows where it is; you update it yourself. The Company filter narrows to one customer.
4. Per device tab — application list, scan, and Update all on this PC (package manager and catalog; ARP entries without a catalog row are not queued). Above 500 rows the first batch is queued. Clicking Update again for the same app while that job is queued or running does not create a second task.
5. The application update queue shows a few of the newest jobs, not the whole fleet. The header count covers every active job and every failure from the last 24 hours; the rest is in History (active or failed application updates), so a large fleet does not push the app list off the screen. Failed (24h) is a short preview of the reasons in plain language, not the raw winget log. Before a silent update the agent closes that app’s processes (a known name, for example Core Temp, or a file in its folder) and does not start the app again. The registry is scanned once per upgrade burst. Audacity uninstalls the previous version on the first try. Failures that remain: the publisher blocks the download (HTTP 403), an installer that cannot update silently, and a dependency (for example Visual C++) whose file is held by another process. UniFi Network Server gets 20 minutes instead of the usual 10.
6. CVE risk separately: Registry → To remediate.

You usually see more rows than in CVE — an upgrade means “a newer version exists”, not only “a CVE exists”.

Dashboard: the RMM Dashboard shows Software posture (apps to update) with a link to Fleet. Failed installs may raise an alert.

App auto-update (without CVE): on a device group or in workbench → Settings enable automatic application updates in the maintenance window. Separate from CVE auto-patch and OS updates. Needs the right plan and an active window that allows “Updates”.

When there is a vulnerability (CVE)

1. Security → CVE registry → To remediate (recommended).
2. One row = app on a device → Update.
3. Check the Application update queue panel on that page.

The Impacts tab is for triaging individual CVEs (ticket, risk acceptance). Do not select every impact on a PC full of ARP entries and expect everything to upgrade — ARP is an Uninstall-registry inventory key, not a package-manager upgrade path.

CVE and auto-patch details: Security and CVE.

3. What is ARP and why did Update do nothing?

Badge / ID	Meaning	Auto-update
Package manager + normal ID (e.g. 7zip.7zip)	Upgradeable package	Yes
ARP\…	Uninstall registry entry	No via package manager
Software catalog	HTTPS + checksum in company settings	Yes

If you select only ARP rows, the product warns you / nothing new appears in the queue. That is a product limit.

What to do: run an apps scan, look for a real package ID, add the app to the software catalog, or update manually.

4. Operations history — not an app decision queue

RMM → Updates & Patch → Operations history (/rmm/operations):

• Log only: scripts, backups, scans, and application updates — no Cancel.
• The list omits the SNMP community and the full OID dump; KB result and restore mode (TEST/LIVE) stay in the details column. It loads only the current page from each table, not the whole log at once. Routine collector SNMP scans and backup-file housekeeping (reconcile / delete) stay off this log — SNMP lives on SNMP and network devices, retention on Runs; the Other filter still shows them.
• Device filter is a search (not a long host list). The OS patch (scan + install) type filter combines OS scan and install.
• The Application update filter shows only those jobs — still history, not a decision center. The app name and the failure reason are in plain language. A raw winget log is often cut off at the start — the table does not show that snippet; the full text is in the tooltip.
• After CVE/Software Update, check the queue panel first (Active + Failed 24h) — Cancel pending jobs there. Use History for full audit (UI link: History — log only).
• In the queue, Pending jobs can be Cancelled (removed from the agent queue). Once the agent has started installing, cancel is unavailable.
• Application upgrades without CVE: Updates → Software.
• OS patch: History on /rmm/updates/devices → Full history deep-links here with the device filter.

5. A typical technician day

1. Morning: Dashboard / CVE → To remediate — critical risks.
2. Software: Fleet — available application upgrades.
3. OS: Patch OS — approve and schedule install in a window. An optional daily email (Settings → Preferences) is sent only when a patch will not install on its own: no auto-update policy, a severity outside the policy, or an approved patch with no window. Defender definitions (KB2267602) and patches already waiting on a window do not send it.
4. Evening / weekend: check History and failed-install alerts.