Patch Management

The Patch Management page is the Console's view of the fleet-wide patching pipeline. It answers two questions: which patches are approved to install anywhere in the estate? and what is my compliance posture against the patches that exist?. It deliberately does not answer "when does a specific policy's devices actually reboot?" — that configuration lives inside a policy.

7.1 Scope — this page versus the policy editor

Patch Management in NetLock RMM is split across two places on purpose:

• The Patch Management page at /patch-management — the subject of this chapter — is global. It shows every patch the system knows about, holds the approval state for each, tracks compliance against SLA thresholds, displays known vulnerabilities, and configures deployment-wide patch defaults. It is a queue and an observatory, not a scheduler.
• The Policy Settings → Patch Management tab — documented in Chapter 6.12 — is per-policy. It decides when and how the devices assigned to a given policy actually install the patches that have been approved on this page. That is where the per-platform rollout rules, deployment rings, maintenance windows, reboot behaviour, notifications, and retry configuration live.

Both chapters cross-link. Do not expect to find rollout scheduling or reboot controls on the page covered here.

7.2 The tabs

Patch Management is a single page with these tabs across the top:

On the Overview and Devices Not Up To Date tabs a tenant selector appears when the account may read more than one tenant. It narrows every figure of the two tabs, including the dialogs opened from them, to one tenant. The selection is a view only: the compliance scope of the Settings tab applies to every tenant, the other tabs are not affected, and the selection is not kept across page loads.

The vulnerability view described in 7.5 is not a tab yet.

Most actions happen inline through row actions and toolbar buttons. The entries of the Patch history tab open in a details dialog.

7.3 The approval workflow

Every patch in the Update Approval tab is in one of four states:

• Pending — newly discovered; no admin decision yet.
• Approved — eligible for installation anywhere the policy-level rules allow it.
• Rejected — explicitly blocked fleet-wide; no device will install it.
• Deferred — postponed. The default defer period is 7 days; after the timer expires the patch returns to Pending.

From the table toolbar you can act on one or many selected rows. Available actions:

• Approve — set state to Approved.
• Reject — set state to Rejected. A confirmation is shown ("Are you sure?") because rejection is a fleet-wide block.
• Defer — postpone for N days (default 7).
• Reset to Pending — revert from any other state.

Every state change triggers an immediate re-sync of every device. Devices do not wait for their next scheduled poll — the updated approval set lands on every agent as soon as the server can deliver it.

Important: Approval on this page is global. There is no per-device, per-group, per-location, or per-tenant approval on the Patch Management page. Narrowing a patch's rollout to a subset of the fleet is done with the Approval & Filtering and Deployment Rings sub-tabs inside a policy (see Chapter 6.12).

7.4 The compliance model

Scored and listed

Every update the console knows is either listed, scored or neither:

• An update is listed when its approval state qualifies (see below) and it is not a definition update. Listed updates appear in the Devices Not Up To Date tab, in the device dialogs, in the Devices missing OS patches / software updates tiles and in the Updates tab of a device.
• An update is scored when it is listed and lies inside the compliance scope configured on the Settings tab: its source, its update type and its severity bucket are selected, and its grace period has passed. Only scored updates count toward the compliance percentage, the fleet and device health ratings, the SLA figures, the donuts, the top tables, the dashboard widgets and the critical tile.
• Definition updates (Defender signatures) are never listed or scored. Rejected updates, updates whose deferral is still running and updates blocked by the automatic rollback are never scored.

A listed update that is not scored carries the chip Not scored wherever it is shown, and the SLA column of the Update Approval tab reads Not scored for it. A device whose open updates all lie outside the scope is up to date for every compliance figure; the Devices Not Up To Date tab still lists it, marked with the chip, so the backlog does not disappear.

The default scope scores the operating system channels (OS-Mandatory, Apt, Dnf, Yum, MacOS), every update type except Driver, every severity and approved updates only, without a grace period. Winget and Chocolatey updates are listed but not scored until you add the two sources to the scope.

The approval state of the scope is either Approved updates only (the default) or Approved and pending updates. The second option scores pending updates and deferred updates whose deferral has expired as well, which shows the real exposure of a fleet that is not approved by hand.

The grace period (0 to 60 days) delays scoring: an update is scored only once it has been in the catalog for that many days, counted from First seen. It keeps Patch Tuesday from colouring the fleet red for the day or two before the scheduled runs have installed the new updates. The grace period has to be shorter than the SLA deadline for Critical, so a critical update can never be overdue before it is scored; the Settings tab refuses to save otherwise.

Security-relevant updates

An update is security-relevant when its update type is Security, or its severity is Critical, High or Important, or its catalog row carries at least one CVE. This definition is fixed and not part of the configurable scope. It drives the headline figure and the health ratings below. A monthly Malicious Software Removal Tool rollup without CVEs or a driver update is not security-relevant.

Fleet health

The headline figure of the Overview is the security compliance: the percentage of reporting devices without an open security-relevant scored update. A device reports once it has at least one catalog row that is not a definition update. The second line, X of Y devices fully patched, counts the devices without any open scored update. The colour of the headline follows the tier thresholds: 90 % and above green, 75 % and above amber, below red.

The fleet health rating takes the first matching row:

The reason line under the rating names the security compliance, the fully patched count and every figure above zero.

Device health

The smiley in the Patch status column of /devices rates one device on the same scale:

1. A device that never reported its update state is grey.
2. A device without an open scored update is Up to date, whatever its last job did. The tooltip names the listed updates that are not scored and the updates not approved yet.
3. Up to two open scored updates are Good, up to five Fair, more need attention. A backlog without a security-relevant update stops at Fair.
4. An overdue critical update is Critical; an open critical update within its SLA or an overdue security-relevant update is at least Needs attention.
5. A Patch Now job that finished in the last 14 days lowers the rating when it failed, but only for failed items whose update lies in the catalog scope.
6. An outstanding restart that pauses the scheduled runs with operating system updates open is at least Fair.

SLA status

Each row in the Update Approval tab carries three compliance indicators in addition to its approval state:

• Installed — count of devices that already have the patch installed.
• Devices pending — count of devices where the patch is available but not yet installed.
• SLA — one of Compliant, At Risk, Overdue or Not scored.

SLA status is computed per row based on the patch's severity and how long it has been known. The threshold for each severity is the number of days after first discovery within which a device is expected to have installed the patch:

SLA state transitions:

• Compliant — within SLA. The deadline has not passed.
• At Risk — three days or fewer to the deadline.
• Overdue — the deadline has passed.
• Not scored — the compliance scope does not score the update, so no SLA applies to it.

Grace period and SLA both count from First seen: the grace period decides when an update starts to count, the SLA deadline when it is overdue.

Dashboard widgets

Widgets that make a compliance or health statement follow the scope: Patch compliance, Patch SLA status, Most missing updates and Missing updates by platform. Widgets that break down the inventory show every approved update regardless of the scope: Pending approved updates by severity, Available updates by type and Update approval status; the history and job widgets are unchanged. The description of each widget says which rule it follows.

7.5 The Vulnerabilities tab (cooming soon)

The Vulnerabilities tab shows known CVEs that affect devices in your fleet. Data comes from two sources:

• The National Vulnerability Database (NVD) — the authoritative public feed of CVE records.
• The Console's own device inventory, which pairs each device's installed software with the CVE records that reference those products.

The tab is a cross-reference of the two: rows represent CVEs affecting devices you manage, with counts of how many devices are exposed and links through to those devices.

NVD data is refreshed on an interval controlled by the nvd_auto_download_enabled flag on the Settings tab. When the toggle is on, the server downloads NVD feeds automatically; when it is off, the existing data is still available but is not refreshed until you turn the toggle back on.

7.6 The Patch history tab

The Patch history tab lists what was installed or removed on the devices, and why a run installed nothing. It shows two kinds of entries in one list, newest first:

• Jobs. Patch Now and uninstall jobs that an operator started. The Action column reads Install or Uninstall, and Triggered by names the operator.
• Scheduled runs. The runs an agent started on its own from the patch schedule of its policy. The Action column reads Scheduled run, and Triggered by reads Schedule. Scheduled runs are reported by agents 3.3.0.5 and newer. Runs of older agents appear only as the Last patch run line on the device.

The same list exists for a single device as the Patch history tab next to Updates in the device's detail view on /devices.

Columns and filters

The columns are Device, Tenant, Location, Action, Status, Triggered by, Created, Finished, Items and Actions. For a scheduled run, Created is the start of the run and Items shows how many updates were installed, failed and held back. A skipped run has no items.

The status of a scheduled run follows its result:

The toolbar filters the list:

• Status accepts several statuses at once. With none selected every entry is listed, including Skipped. Select every other status to leave the skipped entries out.
• Trigger switches between All entries, Patch Now & uninstall and Scheduled runs.
• Action narrows the list to Install or Uninstall. Scheduled runs count as installations: Install lists them together with the Patch Now jobs, Uninstall hides them.
• Period loads Last 7 days, Last 30 days, Last 90 days or All time. The default is Last 30 days.
• The search box also matches the note of a run and its outcome text.

Details of a scheduled run

Double-click an entry or use View full details in the Actions column to open its details. A job opens Patch Job Details as before. A scheduled run opens Scheduled patch run, which shows:

• The device, tenant and location.
• Started on the clock of the instance, and underneath Device time: … on the device's own clock. Finished carries the duration of the run.
• Maintenance window: Inside the maintenance window (…) or Catch-up of a missed maintenance window (…), followed by the window of the policy, or no time restriction when From equals To.
• The status, the agent version, the note of the run and the counts of installed, failed and held-back updates, with Reboot required when the run left a restart outstanding.
• A notice when Winget and Chocolatey updates were not checked because Windows updates wait for a restart (agents before 3.3.0.11 skip the application stages of a run whose Windows stage leaves a restart outstanding; from 3.3.0.11 the application updates are installed in the same run), and when the agent reported only part of the updates of a very large run.
• One row per update with Source, Name, Status, Reason and Details. The chips above the table filter the rows by All, Failed, Installed and Held back.

The status of an update is Installed, Installed, restart pending, Failed, Held back (held back on purpose) or Skipped (nothing to do). Details carries the error text, for Windows updates the error code Windows Update returned, and for Linux the package manager's message. The reason is one of:

From agent 3.3.0.11 the Last run chip on the device's Updates tab shows the decision of the last scheduled run for Winget and Chocolatey updates as well — Installed, Failed, Retry after …, Not approved, Deferred to a later run, No upgrade available, Package manager query failed in the last run, Not offered in last run — in the same way as for Windows updates, and a Retry after … reason names the time of the next allowed attempt. An older agent reports no decision for these rows, so their chip stays empty.

When a scheduled run creates an entry

The agent checks every five minutes whether a scheduled run may start. Not every check creates an entry:

• A run that reached the installation always creates one entry, including runs with the result Nothing pending or Waiting for restart.
• Insufficient disk space and informational mode create a Skipped entry at most once per day. Neither uses up the maintenance window.
• Patch management disabled in the policy, no patch settings on the device yet and an incomplete maintenance window create a Skipped entry when the state changes, not at every check.
• Waiting for an allowed patch day, waiting for the maintenance window and already ran in the current window never create an entry. The device's Scheduled patching line in the detail view shows these states with the next possible run.

Links and retention

A link to /patch-management?run=<id> opens the details of a scheduled run, and /patch-management?job=<id> the details of a job; both open the Patch history tab. /patch-management?tab=jobs opens the tab, and &status=Skipped or another status preselects the status filter. An entry outside the selected period still opens; the tenant scope of the account applies.

Scheduled runs are deleted after 90 days by default. The retention is set under Scheduled Patch Run History Cleanup on the Settings tab, separately from the update history. Jobs are not affected by it.

7.7 The Settings tab

The Settings tab holds the page's configuration knobs. These are deployment-wide — they affect the whole Patch Management page, not a particular policy.

Changes apply once saved: the overview, the Devices Not Up To Date tab, the dialogs, the Patch status column of the devices list and the dashboard widgets read the saved values within a few seconds. The Save Settings button of the Settings tab and the one of the Auto-Approval tab write the same settings record; both need the permission described under Permissions. Without it the fields are read-only and a hint names the required permission.

The earlier switch Include software updates in patch compliance has become the Winget and Chocolatey entries of the sources list; an instance that had the switch on keeps scoring both sources after the upgrade.

7.8 Platforms and sources

The Update Approval tab filters by platform and by source. The platform dropdown supports:

• Windows
• Linux
• MacOS
• Docker

The source dropdown supports:

Approval is per patch regardless of source. An Approved patch from Winget installs under the same rules as an Approved patch from OS-Mandatory — the per-policy Approval & Filtering sub-tab is where you gate which sources a particular policy's devices accept.

On Apt systems, a package update can ask what to do with a configuration file that was modified on the device. The agent answers this automatically according to the policy's Configuration file conflicts option (Linux tab, Approval & Filtering): by default the currently installed file is kept; alternatively the package maintainer's version is installed. Dnf and Yum never ask — rpm writes .rpmnew / .rpmsave files instead — so the option does not apply to them.

On Apt systems the agent also decides how the packages are handed to apt. When the run covers everything apt has pending - no severity, type, approval or deployment-ring filter drops a package - apt resolves the upgrade itself: apt-get upgrade --with-new-pkgs by default, which installs new dependencies but never removes a package, or apt-get dist-upgrade when the policy option Allow package removal (full upgrade) (Linux tab, Approval & Filtering, shown for apt) is on. With the option off, packages that apt can only upgrade by removing another one - a renamed library such as libzfs6linux to libzfs7linux on Proxmox VE - are kept back and listed in the job as Skipped, together with the packages a full upgrade would remove; Proxmox VE hosts need the option on. A filtered selection installs the named packages only (--no-remove unless removal is allowed) and, if apt rejects the set as a whole, is retried package by package. apt waits up to five minutes for a package lock held by another process. When apt fails, its E: lines are shown in the item details of the job, in the job note and in the agent's Error.txt. A kernel update marks the device as reboot-required as soon as a kernel newer than the running one is installed in /boot, so the reboot policy applies on Debian and Proxmox VE hosts as well.

On Dnf and Yum systems (Fedora, RHEL and its rebuilds such as Rocky Linux and AlmaLinux, CentOS) the agent refreshes the repository metadata with dnf makecache / yum makecache before it reads what is pending. Pending updates are listed once per package, with the exact version dnf offers, and once per advisory, with the advisory's type and severity and its packages in the description; a package an advisory covers appears in both. On Fedora 41 and later (dnf5) the advisories are read with dnf advisory list. When the run covers everything dnf has pending, dnf resolves the upgrade itself with dnf upgrade, which also handles obsoleted packages, kernels installed next to the running one and every advisory. A filtered selection installs exactly the approved package versions (name-version-release.arch) in one transaction and the approved advisories (--advisories= on dnf, --advisory on yum) in a second one. A package dnf cannot use - excluded by excludepkgs in dnf.conf, or a version the repository no longer offers - fails with dnf's own message (No match for argument, matches only excluded packages) and the other packages are installed in a second run; a transaction dnf rejects as a whole is retried update by update. After the run the agent asks rpm what is installed: a package item is Success only when the approved version is installed (in a full upgrade, also a newer one), an advisory item only when dnf no longer lists the advisory as pending. dnf's error lines are shown in the item details of the job, in the job note and in the agent's Error.txt.

7.9 What is not on this page

Several controls that admins from other RMMs look for on a "patch management" page live elsewhere in NetLock RMM. Knowing where to find them saves time.

• Per-device or per-group exclusion lists. Not here. A patch is Rejected fleet-wide or not at all. If you need to exclude a subset, use the Approval & Filtering sub-tab inside the relevant policy (Chapter 6.12) — or split those devices into a different policy with stricter filters.
• Rollout scheduling — maintenance windows, allowed days, time ranges. Not here. Configure them on the Schedule sub-tab inside a policy's Patch Management tab.
• Deployment rings. Not here. Configure them on the Deployment Rings sub-tab inside a policy's Patch Management tab.
• Reboot behaviour and user prompts. Not here. Configure them on the Reboot sub-tab inside a policy's Patch Management tab.
• Retry on failure. Not here. Configure it on the Retry sub-tab inside a policy's Patch Management tab.
• Notifications. Not configured here. Per-event patch notifications are toggled on the Notifications sub-tab inside a policy's Patch Management tab; the channels and recipients those notifications are sent through live in A.8 Notifications deep dive.

The split is deliberate: one global decision ("may this patch install anywhere?") and many per-policy decisions ("how do these particular devices install the things that are allowed?").

Permissions

Patch Management uses two permission flags:

• patch_management_enabled — master flag. Users without this flag do not see the Patch Management navigation entry and cannot reach /patch-management. A user who has the flag can approve, reject, defer and delete updates and read every tab.
• Patch management: auto-approval rules and settings (patch_auto_approval_manage) — shows the Auto-Approval tab and allows saving the auto-approval rules, the auto-approval master controls and the Settings tab (SLA thresholds, compliance scope, history cleanup). Because these settings apply to the whole instance, saving them additionally requires that the account has access to every tenant.

The figures of the page follow the tenant scope of the account: an account assigned to a subset of the tenants sees the devices and updates of those tenants only, in every tab and dialog.

Related chapters

• Chapter 6 — Policies — the per-policy Patch Management tab, where rollout rules live.
• Chapter 6.12 — direct link to the per-policy Patch Management sub-tab reference.
• Chapter 12 — Events & Audit — event records for patch installs and approval changes.
• A.8 Notifications deep dive — channels and recipients for patch notifications.
• A.2 Updates & maintenance — Console and server update cadence, distinct from endpoint patching.