Frequently Asked Questions

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

Q. 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.

A. 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.

Q. Can I install a software with no associated vulnerability?

A. 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.

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

A. 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.

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

A. 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.

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

A. 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.

Q. 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. 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.

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

A. 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.

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

A. 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

Q. How does Patch Management handle End of Life (EOL) patches?

A. A patch is withdrawn from the catalog if vendors mark the specific version or patch for EOL or withdraws them explicitly. Such patches are marked as deprecated and withdrawn from active jobs after the EOL date. The EOL patches or patches applicable on EOL version of a software cannot be deployed through the patch deployment job. Extended support or premium support beyond the EOL date is not honored in the patch catalog. If a patch is not explicitly deprecated and just marked as EOL, it is still honored in a deployment job as long as the patch URL is valid and the patch file is accessible.