Frequently Asked Questions for Patch Management

Currently, we do not have a mechanism that support the functionality where a mandatory sequential reboot is required between 2 patches that are a part of the same job. This functionality is not factored because it contradicts the basic philosophy of single reboot after an entire job, instead of after each patch is installed.

Patch Management does not install a software but only upgrades it to a newer version. It is extremely rare that a software version has no vulnerabilities associated. However, there might be vulnerabilities associated in future. To ensure future vulnerabilities are effectively remediated, we recommend regular and frequent patching for a software version.

We sync and update the catalog 30 minutes. However, sometimes a patch might take more time to reflect in our catalog. Depending on the vendor, the maximum time taken for a patch to reflect in our catalog is tentatively, 24 hours.

The Failed Patch Installs widget is not clickable by design. It just gives number of patches which failed to install overall in the account. The date range filters are not applicable for Patch Management widgets.

Yes, the patch install job proceeds to download and deploy patches even if a computer is locked or you are not logged in. If you are not logged in, the deferment option is skipped, and the reboot countdown is initiated immediately. Deferring a reboot is permitted only for a limited period to ensure quick closure on remediation, within the defined time (maximum 168 hours). Also, if the Suppress Reboot option is enabled, then the locked system does not matter, you must reboot manually.

A modification to a job (disable or delete) is ideally expected to be updated anywhere between 5 to 30 minutes. Server sends the job 3 hours prior to the job start date time. If the job is in agents’ queue and the job is deleted or disabled from the UI, then the time for new job manifest to reach agent depends on following:

- Time it takes to send the updated manifest to Cloud Agent UI and server
- Network connectivity
- Agent must be communicating to the server
- Next CAPI call of agent

If the agent receives a new manifest before starting execution of the job, it will remove the job from its queue. If not, then the job will continue taking the time it needs.

A deployment job execution is in 3 main stages:

 1. Download of Patches
2. Deployment of successfully downloaded patches
3. Optional reboot after deployment based on the patches successfully deployed

A deployment job can be cancelled only before its scheduled time or before start of the second stage, that is deployment of patches. After initiation of the second stage, a deploy job cannot be canceled.

The reason is that the vendor does not store multiple versions. For example, Chrome will publish the binaries for all its patches using the same URL that is the same file. As such the agent can only download the latest version that is offered by Chrome and has no access to old versions.

While executing a deployment job, the agent checks if the patch binary file is signed or not. If the signed information is not available for a patch, checksum is compared for the file integrity. In case the patch integrity fails, the agent marks the patch installation as failed with following error codes:

- FileSignatureFailed

- FileHashValidationFailed

To detect and patch a cumulative update, some Servicing Stack Updates (SSU) are a prerequisite. For best performance, Microsoft recommends that you apply the SSUs before installing the monthly cumulative update.

The reason is that the vendor does not store multiple versions. For example, Chrome will publish the binaries for all its patches using the same URL that is the same file. As such the agent can only download the latest version that is offered by Chrome and has no access to old versions.

On Windows assets, once the Patch Management is enabled on the agent, we detect the previously installed patches irrespective of who applied them.

On Linux assets, we do not detect previously installed patches. We report missing patches based on vulnerabilities in the system within 4 hours of detection.

An irrelevant or not applicable patch for an asset will generally show as 0 Missing and 0 Installed.

Yes, you can add QQL for a Windows deployment job instead of patches to select dynamically applicable patches for your environment. A QQL allows you to choose patches based on application, severity, vendor, and so on. A well-defined QQL can provide a sliding window of time to select patches published in a limited period like the last 3 months, 1 week, etc.

For more information, see Using QQL to Automate Patch Selection for Windows Assets.

We store the patch supersede information in the patch catalog. And we store the count of non-superseded missing patches count when we receive the patch scan results from the agent.

If the vendor publishes the new superseded patches, then the same is applied in the patch catalog. But the non-superseded missing patches count is calculated only when we get the next agent patch scan results. Till we get the patch scan results, the previous count is shown.