I've already solved this, but since Quest support wasn't aware of the issue, I figured I'd post the symptoms and resolution here in hopes of saving someone else from the frustration that I went through this past week. 

When running patch detection jobs after February updates were released from Microsoft, I noticed that my 64 bit Windows Servers were still reporting 0 missing updates.

It didn't take long to realize that our antivirus software was not setting the registry key Microsoft requires to enable detection of the updates that include Meltdown/Spectre remediation, so I created a script to push out that registry update. Unfortunately, it didn't change anything as far as Kace patch detection went. 

Looking at the device details for a server after it had been scanned revealed that the 2018 updates from Microsoft didn't even appear in the patch list under Device Detail > Security > Patching Detect/Deploy Status > Deployment Status > All.

Reviewing the Kace ProgramData patch directory on a server showed that the .checksum and .pls files for the missing updates were present. The kagent.log files showed that those updates had a detect_status = 2, meaning Not Applicable. 

Resolution to follow...
Answer Summary:
1 Comment   [ - ] Hide Comment


  • I had come to the same conclusion. A few additional notes ...

    1. After performing the detection schedule, the patches needs to be downloaded (if they had not previously been), as patch deployments would otherwise get stuck in "Downloading" state and eventually time out.

    2. As the K1000 I'm working with is configured to update patch signatures and download patches on a schedule, I initiated this process from "/adminui/settings_patching.php" and experienced an issue, where Kace completely removed its patch catalog. Luckily, it re-populated it again during the following scheduled run.

    3. From what I understand, additional registry keys ("FeatureSettingsOverride" and "FeatureSettingsOverrideMask") are required in order to enable the mitigations on servers (the patches alone only provide the mitigation functionality, but they dont enable it). These keys can be created prior to the installation of the patches. Further information can be found in Microsofts server guidance article: https://support.microsoft.com/en-us/help/4072698/windows-server-guidance-to-protect-against-the-speculative-execution

    4. Verification of (hardware/software) mitigation as well as recommendations can be seen with the SpeculationControl powershell module provided by Microsoft: https://gallery.technet.microsoft.com/scriptcenter/Speculation-Control-e36f0050

    5. Microsoft has (until further notice) blocked subsequent patches from being seen as applicable if the QualityCompat registry key has not been set. This means that you're not only missing out on the Meltdown/Spectre related patches.
Please log in to comment

Answer Chosen by the Author


Here's the quick version of the fix - 
1) Verify that HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\QualityCompat exists and contains a DWORD value of cadca5fe-87d3-4b96-b7fb-a231484277cc with data set to 0.
2) Delete the key HKLM\Software\Patchlink.com\cache
3) Rerun the patch detect job in Kace. 

I've attached a screenshot of the Kace script I've been testing to automate the registry updates - use at your own risk and feel free to post improvements here. 

For those interested in more details or how I found this, take a look at https://community.ivanti.com/docs/DOC-62968.  That article includes a link to a script that sets the Microsoft QualityCompat registry entry and deletes the Patchlink cache. Quest doesn't seem to have this documented despite using the same patch engine. 
Answered 02/21/2018 by: bwcarty
White Belt

Please log in to comment
Answer this question or Comment on this question for clarity


Nine Simple (but Critical) Tips for Effective Patch Management
This paper reviews nine simple tips that can make patch management simpler, more effective and less expensive.