As usual, McAfee only addresses the latest release of each product, even though previous releases are still under Platinum Support Agreements. For example VirusScan Enterprise 8.8 Patch 4 is still supported by McAfee but is not explicitly listed in the bulletin above. The same goes for their other products. I tested the Microsoft updates on VSE 8.8 Patch 4 and Agent 4.8 Patch 2 and no issues on Server 2012 R2.
MS have confirmed that without the presence of the registry keys, the January cumulative patch & all future updates will not reply. Hopefully, once McAfee have released a full list of products that have been tested, we can proceed with deploying the registry key should there be no impacted products.
As per a suggestion in McAfee's KB, I've setup a Group Policy Preference to apply the registry key... this is currently targeted using an Active Directory group, so I am able to add PCs & servers to that group when I've checked they are running supported products.
Certainly now, VSE 8.8 and HIPS 8 are supported down to Patch 4, but I'm waiting for confirmation on DLP 9.3 (as they only list 9.4 onwards, and 9.3 is still supported until September this year). Although I will do some of my own tests in the meantime on some systems.
For non-AD systems, and with the current lack of a Mcafee option to push out the registry key, I'm expecting to get it done manually, either by myself, or the sys admins who look after those specific servers. Although there is still the matter of the performance hit from installing the MS Patch.
The patch itself will get pushed out via our internal WSUS server. It only shows as "needed" once the registry key is present, so in that respect it is perfectly save to approve in advance.
It would seem McAfee has updated their KB to indicate of both a DAT and a custom package available that will write the registry key/value pair necessary to allow the MSFT patch to install as it should. What I truly find amazing is how the article at no point indicates if either the package or the DAT will verify that no incompatible products (McAfee) are installed. Yes, I understand that the tested products list is quite lengthy and shame on you for not getting within the last 3 versions. However if the package (which I will extract and review) ONLY writes the key, shame on you McAfee.
For those who have not read this article yet, I think you will find this interesting.
The authors of the KB need to put themselves in the place of the lone sysadmin when writing these articles. Many have been on 20 hour+ days, with a flurry of emails from random C-levels all asking the same questions. Yes, this is a huge mess, and its not McAfee's to clean up, I am also aware that Microsoft is creating an even larger vulnerability by leaving the writing of the registry key up to consumers and enterprises for this and all future security updates. However this is the opportunity for an organization like McAfee to stand out and stand above the others in this field and with all honesty I do not see that happening. I believe the fault in this issue, or at least the delay in mitigation will be blamed heavily on that of the security vendors.
Shame on McAfee for not allowing the registry key to be deployed via DAT on systems running VSE 8.8i. We are in a university environment and have student systems who are not part of AD, not connected to ePO. What do we do with these systems running VSE 8.8 and who are unmanaged. If it is true that Microsoft won't be deploying future security updates without this registry key then we have a major problem.
Not veryone has yet migrated to ENS so shame on McAfee for not supporting VSE via the DAT method
Just started testing the package that McAfee released, KB_90167100.zip, and it does deploy via ePO and adds the correct registry key to my test system. Does anyone know if there is a ePO query that can be used to see which systems successfully received this update?
This isn't a way to do it through the ePO, but if you're comfortable with powershell you could do something like this:
$properties = Get-ItemProperty -Path "hklm:\SOFTWARE\Microsoft\Windows\CurrentVersion\QualityCompat"
Get-Member -InputObject $properties -Name cadca5fe-87d3-4b96-b7fb-a231484277cc
If the key is there it will return:
Name MemberType Definition
---- ---------- ----------
cadca5fe-87d3-4b96-b7fb-a231484277cc NoteProperty int cadca5fe-87d3-4b96-b7fb-a231484277cc=0
You'd need to expand the script to check every computer and you could add a return for just a true/false, but for brevity I just added the key check.