1. Automox
  2. Using Automox
  3. Reporting

Activity Log is Reporting a False Positive

Avatar
Alexander
Updated:

Objective

To explain why the Automox Activity Log may report an OS patch installation as successful even though the update was skipped or not installed on the endpoint.

Problem / Symptoms

The Automox Activity Log displays an entry stating that a patch was installed successfully:

 
Installed patches: "2022-09 Cumulative Update for Windows Server 2019 (1809) for x64-based Systems (KB5017315)" (Status: 0)

However, checking the endpoint directly reveals the update was not actually applied, and expanding the execution details shows raw payload output similar to:

 
{"args":"\"e902424c-97e9-480f-b72c-574fee79e846\"","response":"[\"0\",\"Installing MS updates: \\\"e902424c-97e9-480f-b72c-574fee79e846\\\"\\r\\nCouldn't find update for e902424c-97e9-480f-b72c-574fee79e846, skipping.\\r\\nNothing left to do\",null]"}

Root Cause

Automox acts as an orchestrator and initiator for operating system updates, relying on the native OS package manager (such as Windows Update API, apt, or dnf) to evaluate, download, and install OS-level patches. (Note: Automox only hosts repositories for software listed in Third-Party Software Support).

When Automox sends an installation command to the endpoint:

  1. The native OS package manager processes the request.

  2. If the OS package manager determines the update is no longer needed, already superseded, or missing from its current catalog, it outputs "Couldn't find update... skipping. Nothing left to do".

  3. Because the native OS package manager completed its task without returning an explicit error code (null error output and exit code 0), the Automox Agent interprets the transaction as clean and logs a successful installation status.

Resolution & Next Steps

  1. Re-Scan the Device: Run a manual scan on the endpoint from the Automox console to force a fresh inventory check against the local OS package manager catalog.

  2. Inspect Native OS Update Logs: Review local system logs (e.g., Get-WindowsUpdateLog on Windows or /var/log/dnf.rpm.log on RHEL) to see why the native update engine determined the KB/package was unapplicable or missing.

  3. Check Group Settings: Ensure patch policy settings and OS update source settings in the Automox Device Group match your environment's patch staging requirements.

Related Articles

Articles in this section

See more
Was this article helpful?
0 out of 0 found this helpful