Hello, It seems that we have a lot of people that likes this new “way” to handle the superseded patches for windows.
Do you guys have any idea in how it will be released for all the other patches ? I know that will be a lot of update work, but I have customers asking about it as they will have a huge benefit from this change.
If you mean patches for other OSes, yes, we would extend the logic to other sites, but it will take a little time to implement the changes across all the sites.
So…when do we expect this new behavior to be in effect? I see that the July rollup packages for Windows have been superseded, with the same old “FALSE” relevance added…
2 Likes
We will send a BESAdmin (and forum) announce a few weeks prior to the change so everyone can be prepared. I know that people are anxious for this change, but we want to make sure we’re carefully considering all the impacts, dotting the i’s and crossing the t’s, so to speak. Right now October is the target, so not too much longer.
1 Like
The proposed new methodology for superseded patching is fine, but appears to have missed a critical piece of vulnerability remediation. Will the new patches be tagged with all the CVEs they resolve? Including all of the “roll up” items they cover?
Are you asking that superseding patches include the CVEs of all the patches that they supersede?
E.g. July patch resolves CVE1, CVE2, & CVE3; and August patch supersedes July and resolves new CVE4, CVE5, & CVE6. Currently, each patch would list the three CVEs they were released to resolved. You want the August patch to list all 6 CVEs (CVE1, CVE2, CVE3, CVE4, CVE5, & CVE6)?
Steve, yes. It’s the only way to provide proof to auditors that you have properly patched a system without applying the old patch, which is explicitly against Microsoft recommendations.
Since most patches are cumulative now, though, we would potentially have 100s of CVEs listed for an individual patch as we get further in the maintenance stream. That seems quite unwieldy to manage, imho. In the new scheme, you would prove your compliance to auditors by showing that the original CVE patch is no longer applicable because it would remain so until some resolving patch was applied.
If reading correctly, the client setting will only be required if you DONT want clients to evealuate the superseded fixlets, correct ?
When will the FALSE statements be removed, this is a good change …
Are we still looking toward this change coming into effect for the October rollup packages? Will the September package be the last to get superseded, or the first to not be superseded?
For those watching this thread, here’s a query I’m beginning to use (still testing) to identify systems that may be behind or failing rollup packages. I put this into an Analysis to evaluate daily:
names of keys whose (name of it starts with "Package_for_RollupFix~" and (value "CurrentState" of it as integer is contained by set of (112;128))) of key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages" of native registry
Ref: Component-based Servicing chart, status descriptions:
Windows 10 and Windows Server 2016 Update History (mapping RollupFix Version Number to KB article):
https://support.microsoft.com/en-us/help/4000825/windows-10-windows-server-2016-update-history
1 Like
Correct.
It looks like the change won’t make the October patch cycle, but Nov or Dec. So October or November patches will be the first that do not go FALSE automatically when superseded.
We are planning to beta the supersedence changes this month, and then GA the change in the December patch cycle. If anyone is interested in getting a preview of the new behavior and is willing to load a beta site with superseded fixlets using the new logic, please message me in the forum with your email address and company name. I will forward the requests to our patch team to include you in the beta.
This change is really useful, however im now seeing backdated superseded content for the monthly rollups, specifically Win7 that are showing as relevant when the Jan rollups have been installed and are not relevant (which is good)
MS17-NOV: Security Monthly Quality Rollup - Monthly Rollup - Windows 7 SP1 - KB4048957 (x64) (Superseded)
MS17-DEC: Security Monthly Quality Rollup - Monthly Rollup - Windows 7 SP1 - KB4054518 (x64) (Superseded)
Maybe a relevance issue with these 2 ??
IGNORE - Potentially caused by us installing the security only updates not the monthly quality rollup … will investaigate further.
I have opened an RFE to get this feature added for Linux content as well: http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=121259
1 Like
Is this handling change still in effect for Windows even?
The fixlets for KB4022715 MS17-Jun, Cumulative and Delta for Windows 10 Version 1607 and Windows Server 2016, all appear to have FALSE statements added now.
These include Fixlet IDs 402271501, 402271503, 402271505, 402271507, 402271509, and 402271511 at least.
This change took effect during the July 2017 Patch Tuesday, so these fixlets from June 2017 would still use the old methodology, as you’re seeing. I’m guessing you mistook these for MS18-JUN 
Yep, that’s it. Sorry, and thanks Steve!
Hello JasonWalker
I came across your comments for an Analysis and I wish to use it [thank you!] but I have questions:
How do you decipher the 'Package for Rollup Fix"?
Can the Analysis be more specific as to which 'Packages" are missing?
Thanks,
Orlando