Monthly patches relevance, here we go again

So, not blaming anyone here, just puzzled… We had many meetings with Microsoft before this new model, and they swore up and down that the one monthly Quality rollup contained all of the monthly Security patches.

Yet, Jan, and now March, if I push the Quality rollup (KBxxx2215), reboot, the PC is still relevant for the security patch which in theory is already done. specifically KB4012204 and KB 2212… If you read the doc on microsoft’s site they say either/or… Bigfix wants both.

Is this MS messing with how they sign files ? Is it relevance ? I’ve had the same issue in January, and if you pushed security after quality it took it and immediately satisfied relevance - no delay, but essentially reran existing patches. Is it their model that’s broken / innacurate ? I think your relevance looks for the security rollup KB and not the individual components, so it’s never satisfied after the quality rollup… Feel free to correct me, but I see what I see here… Thanks !!!

2 Likes

i’m getting the same results.

For Windows 7, i’ve pushed KB4012215. Afterwards the system is still relevant using QNA tools for KB4012204 and KB4012212…

According to the MS KB article
https://support.microsoft.com/en-us/help/4012215/march-2017-security-monthly-quality-rollup-for-windows-7-and-2008_r2

KB4012215 has the contents of KB4012204 and KB4012212.

Geeeez again IBM … !!!
@BaiYunfei @shwesc can you look into this urgently pls.

So I pushed Quality KB 4012215. Waited after a reboot. Security 40122012 was still relevant for that same PC 3 hours later. so I pushed it as well… I get back from lunch and get this:

2212 is showing on that computer as both “non-relevant” as a pushed action, and “relevant” under “relevant fixlets and tasks” - conflicted much ? :wink:

I think you’re looking at the rollup signature instead of the components maybe…

Thanks all for reporting this issue!

In the security-only Fixlets, there is a relevance to detect whether the corresponding monthly rollup has been installed. It should evaluate false when a monthly rollup has been installed. e.g. in Win7 x64 Fixlet:

not exists key "Package_for_RollupFix~31bf3856ad364e35~amd64~~0.0.0.0" whose (exists value whose ((it >= "7601.23710.1.2") of (following text of last "~" of name of it as version)) of it) of key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\PackageIndex" of native registry

This is the same relevance used to detect the installation of monthly rollup is successful. Could you check that after a successful installation and reboot, whether this relevance is still evaluating true in your environment?

This is one of the tests done in our environment.

This worked as expected for me. Once the monthly quality rollup was installed, both security only updates (incl.IE11) became non-relevant.

1 Like

As of this morning, two test boxes I was looking at yesterday now seem to be OK relevance wise… So possibly it takes a long time to evaluate what changed after installing 2215 ? that still does not explain the weirdness of installing 2215, rebooting, and then seeing 2212 showing both as “not relevant” if pushed, but “relevant” in “relevant fixlets” for this computer. Clearly there’s something that needs more time to get processed here. Will test another box and wait patiently…

Edit: Seems OK now… I have screen shots from that not working yesterday, so I don’t understand why time would help, since this relevance for 2212 is a direct result of 2215 being installed, not something it needs to process on its own… this AM, pushing 2215 and rebooting almost immediately excluded 2212, so that was quick. Did anything change / was anything fixed ???

Again, not seeing things, I have pictures; -)

It works, evaluates to false… It appears the console is lagging behind A LOT and is not reporting this correctly…

I just did another PC with 2215, still showing relevance for security and IE11, but I will sit and wait for as long as it takes and see what the delay is…

Update: 2 reboots, 3 hours later, the PC evaluates corectly with qna but still shows relevant for security and IE11 in the console… Will keep waiting…

Thanks all for the updates! Glad to know it’s working :slight_smile:

There you go… Pushed Quality at 8:30AM, rebooted a few minutes after application…QNA immediately was good. But not the console… (security still relevant)

PC reported every 15 minutes or so between then and now, and was still relevant in the console for security and IE11. At 10:40 I got annoyed and rebooted again (2nd time)… Still relevant…

Finally at 11:30AM the patches were no longer relevant, after many many reports in between…

I need to add about 2 hours to my normal patience level… Thanks guys !

I am sorry to hear that it’s not exactly working as we would expect. Just curious, do you see this delay of reporting happening in any other scenario than the monthly rollups?

Thanks!

Well, at last now we know ! I think January was the same for us. It’s hard to tell if this scenario is common in our environment because we don’t often have one push where it’s “pick and choose” between 2 fixlets, where completion of one triggers/excludes the other - we’re not actively looking for that behavior per se.

Security vs Quality rollups is such a case… The first push of 4012215 is returning completion results and non-relevance for itself right away (normally)… Pushing security immediately after that quality rollup has been processed and a reboot, and another buffer of time does returns a non-relevant action result (correctly - but the target PC still shows security under “relevant fixlets” - jekyll/hyde?)… It just seems the console then needs 3-4 hours to get the hint that the security patch is no longer needed - at least in our environment… The console seems to lag for the MS rollups. I’ve only seen this happen with patches since the new model came out.

It’s fine, now we know, last time around it took even longer for this relevance to process/exclude correctly (a day?) so our first baseline actually included BOTH security AND Quality to be sure. And both ran, believe it or not… This time we wanted to avoid redundancy…

I’ve got a similar issue with Windows 2008 R2 SP1 endpoints showing as “Failed” for KB4012215 after installing / rebooting with the following patches as part of a March 2017 "baseline:"
KB4012204
KB4012212
KB4012215
This baseline was deployed to 111 (Windows 2008 R2 SP1) “test environment” endpoints. 102 were successful; however, 9 endpoints failed and I am unable to determine root cause.
The failure appears to be an issue with a registry entry not being created during the installation process; however, my biggest concern at this point is that I have roughly 1200 “production” endpoints that are relevant for all three patches and no idea how many will work successfully…
I’m gathering more info / details to post, but any insight in meantime would be great…

Hi Rob,

KB4012204 - Security-only for IE
KB4012212 - Security-only
KB4012215 - Monthly Rollup

So you need to deploy either KB4012215 alone (it includes the first two), or deploy KB4012204+KB4012212 to fix only security vulnerability.

That being said, the Fixlets should not fail even if you apply all of them. I would suggest to try the following:

  • Take one of the failed endpoints, make sure windows update on it has been disabled and it has rebooted
  • Apply the above mentioned KB(s) to this single endpoint
  • If the Fixlets still fail, note down the return code, log on to this machine and try manually install the patch, note down the error message
  • Open a PMR with IBM if the above still showing error and machine still relevant to the KBs

Ok, something strange going on again.

I have machines reporting as requiring the following fixlet -

MS16-144, MS16-146, MS16-147, MS16-149, MS16-151, MS16-153: Security Only Quality Update - Security Only - Windows 7 SP1 - KB3205394 (x64)

The following fixlet is not relevant (as expected) because its been superseded -

MS16-144, MS16-146, MS16-147, MS16-149, MS16-151, MS16-153: Security Monthly Quality Rollup - Monthly Rollup - Windows 7 SP1 - KB3207752 (x64) (Superseded)

HOWEVER

These machines have the latest (MS17-006, MS17-008, MS17-010, MS17-011, MS17-012, MS17-013, MS17-016, MS17-017, MS17-018, MS17-020, MS17-021, MS17-022: Security Monthly Quality Rollup - Monthly Rollup - Windows 7 SP1 - KB4012215 (x64) fixlet installed, so surely this should clear all the backdated Security Only Quality update fixlets ?

@BaiYunfei

Also @BaiYunfei… Re: this Security Only update:

MS16-144, MS16-146, MS16-147, MS16-149, MS16-151, MS16-153: Security Only Quality Update - Security Only - Windows Server 2012 R2 - KB3205400 (x64)

Where in the relevance is the detection to determine whether or not the corresponding monthly rollup has been installed?
I.e. Either the superseded rollup KB3205401 or the new rollup that replaced it; KB4012216…

For example, you stated earlier that this is the detection for the Win7 x64 fixlet:

not exists key "Package_for_RollupFix~31bf3856ad364e35~amd64~~0.0.0.0" whose (exists value whose ((it >= "7601.23710.1.2") of (following text of last "~" of name of it as version)) of it) of key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\PackageIndex" of native registry

But I can’t find the word “Rollup” anywhere in the relevance for the Security Only update referenced above (KB3205400 (x64)). So not sure how it is detecting if the rollup is already installed.

Please advise. Thanks.

@shwesc @BaiYunfei

Any updates on this please ?

(Updated)

Hi @nicksberger @it_cat thanks for reporting the issue!

You are correct that the relevance used to detect Monthly Rollups are not included in the batch of Dec 2016 security only Fixlets. Apologies for the negligence causing this issue. We have taken the following actions:

  • Updated Dec 2016 security only Fixlets to include this check; changes are published to site Patches for Windows version 2725.
  • Checked existing (Oct 2016 - Mar 2017) security only Fixlets to make sure this relevance is included. Actions were already taken to ensure future content include this logic. (Update: Note for this item - .NET Fixlets for Oct and Dec 2016 will undergo similar checks, and will be updated if necessary)

Apologies again for the inconvenience caused!

1 Like

Great stuff, issue resolved. Thanks for the quick turnaround.