Frequently Asked Questions for Patch Management

We have compiled a list of a few questions that you may have for Patch Management.

- How does Patch Management handle a co-dependency of system reboot for two patches that are a part of the same job? For example, I have two patches A and B, and both require reboot to fix the vulnerability, but patch A vulnerability can only be fixed if patch is already applied, and a reboot is performed.How does Patch Management handle a co-dependency of system reboot for two patches that are a part of the same job? For example, I have two patches A and B, and both require reboot to fix the vulnerability, but patch A vulnerability can only be fixed if patch is already applied, and a reboot is performed.

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.

- Can I install a software with no associated vulnerability?Can I install a software with no associated vulnerability?

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.

- How often are new patches detected and reflected in the catalog?How often are new patches detected and reflected in the catalog?

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.

- Why is the Failed Patch Installs widget not showing updated data?Why is the Failed Patch Installs widget not showing updated data?

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.

- Will the patch install job run if my computer is locked?Will the patch install job run if my computer is locked?

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.

- If I have a patch job running and the patch job is deactivated, how long does it take for the Cloud Agent to stop trying to patch systems?If I have a patch job running and the patch job is deactivated, how long does it take for the Cloud Agent to stop trying to patch systems?

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.

- Why are some versions of the software not automatically downloadable and patchable by Qualys Patch Management?Why are some versions of the software not automatically downloadable and patchable by Qualys Patch Management?

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.

- How does Patch Management check the patch integrity while installing a patch?How does Patch Management check the patch integrity while installing a patch?

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

- Do I need to update the Servicing Stack before installing cumulative patches?Do I need to update the Servicing Stack before installing cumulative patches?

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.

- Why are some versions of the software not automatically downloadable and patchable by Qualys Patch Management?Why are some versions of the software not automatically downloadable and patchable by Qualys Patch Management?

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.

- Does the patch catalog show the patches that Qualys Patch Management did not install?- Does the patch catalog show the patches that Qualys Patch Management did not install?

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.

- What does it mean if a listed patch shows 0 Missing and 0 Installed?- What does it mean if a listed patch shows 0 Missing and 0 Installed?

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

- Is there a way to view a filtered list of patches that apply to my environment?- Is there a way to view a filtered list of patches that apply to my environment?

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.

- Why is the missing patches count on the Asset tab and Patches tab different?- Why is the missing patches count on the Asset tab and Patches tab different?

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.

- For which type of patches a system reboot is required after the patch deployment?- For which type of patches a system reboot is required after the patch deployment?

It is essential to let users know about the possibility of a reboot in advance because though a reboot is inevitable, it might cause interruption to the business. Reboot Maybe Required alerts users about a possible reboot after deploying the patch.

For vendor patches, the reboot requirement can be ‘Yes’, ‘No’, and ‘Maybe’.  Some vendors specify the reboot requirement as ‘Yes’ or ‘No’, and some mention it as ‘Maybe’.

A reboot is required for certain OSs, architectures, or processors, and for certain ones, it is not required. Hence, some vendors specify the reboot requirement as ‘Maybe’.  It's complex to elaborate on this. So to simplify, they specify the reboot requirement as Maybe.

As ‘Maybe’ has unpredictability associated with it and is ambiguous, and clarity and predictability are highly expected, we chose a conservative approach.

For Qualys Patchable patches, Maybe is mapped as Yes so that users are never caught off guard and have a clear simple status.
If there is even one single scenario wherein a reboot is required, Reboot Maybe Required is shown as Yes.

Reboot Maybe Required

Note: The Reboot Maybe Required is a possibility, not an assurance. The simple implication of it is that though Reboot Maybe Required is specified as Yes, a reboot might not be required at the run time. To sum up, the reboot requirement is evaluated at the run time during patch deployment.

- Is there any data retention period for deployment job results?Is there any data retention period for deployment job results?

For deployment job results along with actions, if eligible, the data retention period is set.

-  For monthly jobs, the data will be retained for twelve months from the creation date. The data that is older than twelve months will be deleted.

-  For other jobs, such as run-once, daily, or weekly, the data will be retained for six months from the creation date. The data that is older than six months will be deleted. 

Why the Next Trigger details and Start Date time details shown on the job details page are different?Why the Next Trigger details and Start Date time details shown on the job details page are different?

The Next Trigger details represent the date and time when the manifest is sent to the agent. The manifest is sent approximately three hours before the job starts.

The Start Date time details represent the date and time when the job starts.

Note: Irrespective of the system time zone, the Next Trigger and Start Date time details are shown based on the browser time zone.