Frequently Asked Questions for TruRisk™ Eliminate
We have compiled a list of a few questions that you may have for TruRisk™ Eliminate.
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:
- Download of Patches
- Deployment of successfully downloaded patches
- 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.
How does Patch Management check the patch integrity while installing a patch?How does Patch Management check the patch integrity while installing a patch?
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.
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
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.
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.
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.
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.
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.
Irrespective of the system time zone, the Next Trigger and Start Date time details are shown based on the browser time zone.
Each subscription is allocated 15GB of storage on the Qualys Cloud to upload the software installer file. Storage is not allocated on user level, but only on subscription level.
To free up space on the Qualys Cloud storage, perform either of the following:
- Remove the Install Software pre/post action configured using the Upload File to Qualys Cloud option in the patch deployment job.
- Remove the files from Qualys Cloud storage that you uploaded after enabling the vendor acquired patches.
Some patches, such as Java, require manual download from the vendor's website due to login requirements. The agent does not have the ability to log in and download these patches, resulting in a lock on such patches. Similarly, certain URLs, like those for FileZilla patches, are not easily accessible, and the agent cannot download the patch directly from the FileZilla URL.
Qualys leverages your existing OS repository configuration, which is unique to each enterprise. There's no fixed source it controls for patch content. Yes, you can use local repos. Internal mirrors or caching proxies are supported, just ensure they're reachable by the asset.
How can I identify who disabled a patch job? How can I identify who disabled a patch job?
On the Administration application, navigate to the Activity Log tab and perform the following steps:
- In the Search bar, enter the following QQL query, replacing the sample UUID with your job’s UUID:
The results will display a chronologically ordered list of matching events.targetName:844ee6ad-929b-4ab2-afc2-e6177af5051f - Locate the row where Action =
Job Disabled. The User column displays the Qualys username that performed the disable operation, and the Time column records the exact timestamp (in your subscription’s locale).
If no results are returned:
-
Verify you have the correct Job UUID. You can copy the UUID from the job details page (Jobs > select job > Job details).
-
Permission denied message: Request Manager‑level access or have a manager run the query on your behalf.
If a reboot countdown starts while critical activities are still running on the asset, you can temporarily stop the Qualys Cloud Agent service to delay the reboot. After you complete the activities, restart the service to allow the reboot to proceed.
Qualys does not recommend stopping the Cloud Agent service. Doing so can delay updates, disrupt patch deployment, and affect agent communication. Use this option only when necessary and restart the service as soon as possible.
Some vendors, such as Google, maintain a single download link that always resolves to the latest version. In Patch Management, patches are associated with a download method:
Automatic: The patch has a direct vendor download link and can be deployed through a job.
AcquiredFromVendor: The patch is still relevant but no longer has a direct download link and cannot be added to a deployment job, unless enabled with a custom download link provided by the customer.
When a vendor releases a newer version, the previous patch's download method changes from Automatic to AcquiredFromVendor, since the link now points to the newer version. If a deployment job was already created with the older patch, the deployment will fail with a hash value mismatch because the downloaded file no longer matches the expected patch.
Recommendation:
Schedule deployment jobs to run as soon as possible after adding patches to minimize the risk of version rollover.
Alternatively, use a Zero-Touch Patch Job to deploy patches automatically as soon as they are marked as missing on target assets. This eliminates the window in which a version rollover can occur.
The target machine must have sufficient free disk space before deployment. The minimum free space required depends on the platform:
| Platform | Minimum Free Space Required | Total Patch Size of the Job |
|---|---|---|
| Windows | 5× the total patch size | Total size of all patches included in the job. |
| macOS | 3× the total patch size | Total size of all patches included in the job. |
When a deployment job contains multiple patches, the free space requirement is calculated based on the combined size of all patches in the job. For example, if a Windows job contains 3 patches, each 200 MB (600 MB total), the target machine must have at least 3 GB of free space.
If the target machine does not have the required free space, the deployment will fail with the message "There is not enough space on the disk" and error code 112.
Ensure there is adequate disk space on target machines before initiating deployment to avoid this failure.