Set up patch management for a group

Patch management in NetLock RMM is split across two places that do different jobs, and getting both configured is what makes patching work. The /patch-management page is the global approval queue — "which patches are allowed on any device at all?" The Policy Settings editor's Patch Management tab is the per-policy rollout — "when and how do these particular devices install the approved patches?" This guide covers both, using a Windows group as the worked example.

Before you start

• A policy already exists and is routed to the target Windows group via an automation (see Guide H.4).
• At least one Windows device is online in that group.
• Patches have been detected and sit in the Pending state on the Patch Management page. If the list is empty, agents have not yet reported their update inventory — wait a sync cycle.
• Required permissions: patch_management_enabled for the approval page, plus policies_enabled and the policy edit flag for the rollout configuration.

Steps

Stage 1 — Approve patches globally

1. Open Patch Management from the navigation. The Update Approval tab is the default.
2. Filter by Windows and browse the Pending patches.
3. Select a manageable first set — critical security updates from the previous month are a safe start. Avoid bulk-approving every pending patch on day one.
4. Click Approve. The selected patches move into the Approved state. The server flags every device for a resync so agents pick up the updated approval list on their next poll.

Use the other actions as needed:

• Reject — explicitly block a patch; devices never install it.
• Defer — postpone a patch for a number of days (default 7).
• Reset to Pending — revert any state decision back to pending for later review.

Approvals are global. There is no per-device or per-group target selector on this page — scoping happens in stage 2.

Stage 2 — Configure the per-policy rollout

1. Open Policies from the navigation and click Manage on the policy that routes to your Windows group.
2. Open the Patch Management tab in the Policy Settings editor. The tab is split into Global and per-platform sub-tabs; pick Windows.
3. Under the Windows sub-tab, fill in at least these three sub-tabs for a minimal rollout:
   • General — enable patching for Windows and select which sources participate (at minimum OS-Mandatory, optionally Winget and Chocolatey).
   • Schedule — pick the allowed patch days (default Monday to Friday) and a maintenance window. Outside the window the agent will not start an install; the one exception is the catch-up run described in Chapter 6.12, which runs the first check after the policy arrives, or after a missed window, right away.
   • Reboot — decide whether the agent may reboot, whether it prompts the user, how long the prompt is visible, and what happens on a device where nobody is signed in. This is the only place in the product where reboot behaviour is configured.
4. Optionally fill in Approval & Filtering (narrow approved patches by severity or source), Deployment Rings (stage the rollout across Pilot → Early → Broad), Notifications, and Retry.
5. Save the policy.

Verify it worked

• On the Patch Management page's Update Approval tab, the patches you approved show the Approved state and the Installed and Pending columns begin moving as devices pick up the change.
• On a target device's detail view in Devices, the line Last patch run: <time> – <outcome> appears after the first scheduled run that reached the install stage, and the device's Updates tab shows per update whether it was installed or why the last scheduled run held it back. Scheduled runs do not create entries in Events; the only event a scheduled run writes is the Patch management event recorded once when an outstanding restart blocks the run.
• The Patch history tab on the Patch Management page and on the device lists each scheduled run of an agent 3.3.0.5 or later next to the Patch Now jobs. Its details show per update whether it was installed, failed with the error Windows Update or the package manager reported, or was held back and why.
• The Update History tab on the Patch Management page shows the install outcomes per patch per device.

Troubleshooting

• Patches stay at 0 installed. Check that a policy with Patch Management → Windows → General enabled is actually assigned to the device. If the device's detail view shows no_assigned_policy_found, the automation is missing. On Linux, open the job or the scheduled run in Patch Management → Patch history: the item details and the note carry apt's E: lines or dnf's error lines (No match for argument, Error:, Problem:), as does the agent's Error.txt. A package that apt keeps back because the upgrade would remove another package is listed as Skipped with the packages a full upgrade would remove; enable Allow package removal (full upgrade) in the policy's Linux tab to install it. On Fedora and RHEL-based systems a package excluded by excludepkgs in dnf.conf, or a version the repository no longer offers, fails with dnf's message while the other approved packages are installed.

• Patches approved but devices ignore them. Check the policy's Approval & Filtering sub-tab — a filter there can veto a globally approved patch.

• My scheduled run never happens. First check where you are looking. With agent 3.3.0.5 or later, every scheduled run that reached the installation is an entry in the device's Patch history tab and on the Patch history tab of the Patch Management page, with the result of each update and the reason an update was held back or failed (see Chapter 7.6). Runs skipped for disk space, informational mode, a disabled policy, missing patch settings or an incomplete maintenance window are listed there as Skipped. Waiting for an allowed day or for the maintenance window creates no entry; the Scheduled patching line in the device's detail view on /devices shows it with the next possible run. Further traces are the Last patch run line, the chips on the device's Updates tab, and the Last scheduled run column on the Devices Not Up To Date tab; with an older agent they are the only ones. The agent decides every five minutes whether a scheduled run may start and checks the following stages in this order. Go through them from the top; the first stage that fails is the reason.

  1. Patch settings on the device. The device has received the policy's patch settings. The detail view names the assigned policy (not no_assigned_policy_found) and, with a 3.3.0.5 agent, the Scheduled patching line does not say The device has not received its patch management settings yet. Until the agent has reported anything, the detail view shows the schedule facts of the device's policy — mode, allowed days, window, catch-up — so you can compare them with what you expect. If the policy is missing, fix the automation and wait for the next sync.
  2. Platform mode is Managed. Informational only reports: Last patch run: … – informational mode, nothing installed. Disabled skips without a run; a 3.3.0.5 agent reports Patch management is disabled in the policy of this device in the Scheduled patching line. Check Patch Management → Windows → General in the policy.
  3. Allowed patch day. The default is Monday to Friday. On an unticked day no scheduled run happens, not even as a catch-up run. A 3.3.0.5 agent reports Waiting for an allowed patch day with the next possible run; an older agent leaves no trace in the Console and Last patch run stays empty. Check Schedule → Allowed patch days. A policy saved on Friday evening and a check on Saturday morning is the classic case.
  4. Maintenance window or catch-up. Inside the window the run starts at the agent's next check. Outside the window a run starts only as a catch-up: the first check after the policy arrives on the device, or the first check after a missed window, runs right away even outside the window (Catch up a missed maintenance window on the platform's Schedule sub-tab, on by default). From equal to To means no time restriction. A 3.3.0.5 agent reports Waiting for the maintenance window with the next possible run, or The maintenance window of the policy is incomplete, no run is scheduled when it cannot read the From/To pair — nothing runs until the window is corrected.
  5. One run per window occurrence. After a run the agent installs nothing more until the next window opens — once per day for a 24/7 window — whatever the outcome of that run was. A 3.3.0.5 agent reports Already ran in the current maintenance window with the next possible run. If that run installed nothing, the reason is in one of the following stages.
  6. Free disk space. With Check minimum free disk space before patching on, a device below the threshold is skipped: Last patch run: … – skipped, insufficient disk space. This skip does not use up the window; the agent tries again at its next check.
  7. Windows: no outstanding restart. While a restart from an earlier update run is outstanding, a scheduled run installs no Windows updates: Last patch run: … – restart pending, Windows updates held back. From agent 3.3.0.11 the Winget and Chocolatey updates are still installed in such a run and the tooltip of the line names how many of them were installed, failed or held back; agents before 3.3.0.11 install nothing at all. The device shows the Restart pending since … banner with the note that scheduled runs install no Windows updates until the device has restarted, together with the restart behaviour of its policy, and the blocked run is recorded once as an event of type Patch management on the device. With Ask user a device where nobody is signed in asks nobody; the If nobody is signed in option on the Reboot sub-tab decides whether such a device restarts in the maintenance window, immediately, or not at all (the default). With the default the restart has to happen another way — a user or the Console restarts the device, or you change the option — and scheduled runs keep installing no Windows updates until then. Patch Now still installs Windows updates too.
  8. Windows Update query. The agent asks Windows Update for the available updates. When the query times out, fails or returns no result, the run is recorded as completed and its note — the tooltip of the Last patch run line — says that the query for available updates failed and no update was installed. Windows Update itself, not the policy, is the place to look then.
  9. Per-update filters. The run happened (completed or nothing pending) but a specific update is still missing: open the device's Updates tab, where the chip on each update names the reason from the last scheduled run — Blocked by severity filter, Blocked by update type filter, Not approved, Deployment ring until …, Retry after …, Waiting for restart, Not offered in last run. nothing pending means Windows Update offered nothing that the policy's sources cover. A deployment ring set to Immediate only removes the waiting time after an update's release; the allowed days, the maintenance window and the one-run-per-window rule still apply. Only Patch Now bypasses the schedule, the rings and the retry budget.

  On the device itself, a 3.3.0.5 agent writes every change of its schedule decision and every run outcome to Logs\Patch_Management.txt in the Comm Agent folder (C:\ProgramData\0x101 Cyber Security\NetLock RMM\Comm Agent\) without debug mode; state changes and outcomes only, so the file stays small. The full detail of every five-minute check needs debug mode: create an empty debug.txt in the Comm Agent folder and restart the service, as described in Guide — Debug an agent. The agent's run bookkeeping lives in patch_cycle_state.json under C:\ProgramData\NetLock RMM\Agent\ (Linux: /var/lib/netlock-rmm/); a missing or empty file means that no scheduled run has reached the install stage yet.

• Winget or Chocolatey updates are not installed by the scheduled run, although Patch Now installs them. Patch Now only proves that the installer works on the device. The scheduled run has further places where it holds an application update back, and each one leaves a trace. Open the device's Patch history tab, open the last scheduled runs with a double-click and check in this order:

  1. The notice Winget and Chocolatey updates were not checked in this run because Windows updates are waiting for a restart. Agents before 3.3.0.11 skip the Winget and Chocolatey stages whenever the Windows stage of the same run leaves a restart outstanding, and that run uses up the maintenance window, so the next attempt is the next window at the earliest. On a device that is only switched on on days with new Windows updates the application updates never get their turn. From agent 3.3.0.11 the application updates are installed in the same run after the Windows updates, and a restart that is still outstanding when the run starts holds back only the Windows updates while the Winget and Chocolatey updates are still installed (stage 7 of the previous point). With an older agent, make sure the device restarts on the same day (Reboot sub-tab) or use Patch Now.
  2. Items with source Winget or Chocolatey and the reason Retry after …. The update failed in earlier runs and the retry budget is used up: after the policy's Retry count (default 3) failed attempts the agent waits seven days before it tries again; the attempts are kept in patch_retry.json under C:\ProgramData\NetLock RMM\Agent\. The Failed items of the earlier runs carry the installer's result in Details. Patch Now ignores the budget, and a successful installation resets it.
  3. The note The winget upgrade query failed, so application updates from winget were not attempted (or the same wording for Chocolatey). The package manager could not be queried when the run started, for example because winget is not usable from the agent's system account; the device then also carries the event winget is not usable from the agent's system account. The Updates tab keeps the rows of the last successful inventory, so the list looks current although the query fails. From agent 3.3.0.11 the rows of that source show Package manager query failed in the last run. Patch Now with Patch All runs the same query and shows the failure in the job's note.
  4. Items with the reason Deferred to a later run. Install all pending patches before rebooting is off on the Reboot sub-tab, so the run installs one update and the others follow in later runs.
  5. No Winget or Chocolatey items and no notice. The package manager reported nothing to upgrade when the run queried it, even if the Updates tab lists updates from an earlier inventory. From agent 3.3.0.11 such rows show Not offered in last run.

  From agent 3.3.0.11 the Last run chip on the device's Updates tab shows these decisions for Winget and Chocolatey updates as well, in the same way as for Windows updates; a Retry after … chip names the time of the next allowed attempt. The device's patch status is no indication either way: software updates only count toward it when the compliance scope on the Patch Management Settings tab includes the Winget and Chocolatey sources (see Chapter 7.4).

• Reboots happen at unexpected times. Review Patch Management → Windows → Reboot and Schedule in the policy. Reboot prompts follow the schedule's maintenance window.

• SLA chips show Overdue. Adjust the SLA thresholds on the Patch Management Settings tab if the defaults (7 / 15 / 30 / 60 days by severity) do not fit your environment.

Related

• Chapter 7 — Patch Management — the global approval queue, vulnerabilities tab, update history, and SLA settings.
• Chapter 6.12 — Patch Management tab — the complete per-policy rollout reference.
• Guide H.4 — Build and apply a policy — the prerequisite routing setup.