Ok, maybe this whole Delta / Cumulative package isn’t working the way that I thought.
tl;dr -
Why do each of my Win2016 / Win10 hosts appear relevant to only the Cumulative or only the Delta package for June 2017? I expected that anything that could install this month’s Delta would be able to install this month’s Cumulative instead?
Does “Package_for_RollupFix~31bf3856ad364e35~amd64~~14393.1198.1.6” correspond to the May 2017 Delta Package, the May 2017 Rollup Package, or to something else entirely?
If this is the May 2017 Delta, does this mean that systems that installed the May 2017 Delta will only be relevant to the June 2017 Delta, and that systems that did not install the May 2017 Delta will only be relevant to the June 2017 Rollup?
I had anticipated that we could switch to Cumulative at any point without regard to the previous packages; and that we could switch to Delta packages only if we had the previous month’s Delta or Cumulative; - is that not correct?
I had expected that all of my Windows Server 2016 systems would be relevant to “402271505, MS17-JUN: Cumulative Update for Windows Server 2016 - Windows Server 2016 - KB4022715 (x64)”, and that only some would be relevant to “402271501, MS17-JUN: Delta Update for Windows Server 2016 - Windows Server 2016 - Delta Update - KB4022715 (x64)”.
What I’m finding is that some of my Win2016 servers are relevant to this month’s Delta; others are relevant to this month’s Cumulative, and none of my servers are relevant to both.
Here are the results from a server that’s relevant for the Delta, but not for the Cumulative - the most recent patch installed on this host was KB4019472, on 5/20/2017:
//From the Delta update:
q: (exists key "Package_for_RollupFix~31bf3856ad364e35~amd64~~14393.1198.1.6" whose (value "CurrentState" of it as integer = 112) of key "Packages" of it AND not exists key "Package_for_RollupFix_Wrapper~31bf3856ad364e35~amd64~~0.0.0.0" whose (exists value whose ((it = "14393.1358.1.9") of (following text of last "~" of name of it as version)) of it) of key "PackageIndex" of it) of key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing" of native registry
A: True
T: 0.241 ms
// From the Cumulative update:
q: not exists key "Package_for_RollupFix~31bf3856ad364e35~amd64~~14393.1198.1.6" whose (value "CurrentState" of it as integer = 112) of key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages" of native registry
A: False
T: 0.370 ms
Since the introduction of delta updates, we have received reports about severe incidents where, if both of the Cumulative Update and the Delta Update are applied, BSOD is caused. It was also recommended by Microsoft that both should not be applied together.
Therefore, we have intentionally made the Relevances in this way such that:
if the previous month’s CU or DU has been applied, only this month’s DU is applicable;
otherwise, only this month’s CU is applicable.
Your understanding “If this is the May 2017 Delta, does this mean that systems that installed the May 2017 Delta will only be relevant to the June 2017 Delta, and that systems that did not install the May 2017 Delta will only be relevant to the June 2017 Rollup?” is correct.
Please also note that, if your system has May CU installed, installing June’s CU or DU on top of that would bring your system to the same status.
If we make them both applicable, users would run into BSOD by putting both into a single baseline. We intentionally make only one of them relevant.
Technically speaking, this corresponds to the “patch level” that May Delta/Rollup brings you to.
Correct except that those with May Rollup will only be relevant to June Delta, too.
Like I said, applying Cumulative or Delta brings you to the same patch level, so switching wouldn’t have made any difference. The liberty of switching is not worth the risk of causing BSOD.
Hi, so we applied the MS17-JUN Cumulative Update (which has been superseded by MS17-JUL), but only the MS17-JUL Delta Update is relevant now per what you said in #1 above. However, we want to apply the MS17-JUL CU and not the Delta, which I believe shouldn’t cause a bsod. How do we apply the CU from last month and then the CU from the current month?
Hi, our policy is to apply only CU each month and not DU. These changes to the fixlet relevancy are now preventing us from applying the July CU if we applied the June CU, which seems a little restrictive.
May I know the reason behind your policy? Like I have shared multiple times, they are identical to your environment.
Also, please understand the reason behind BigFix’s decision on making CU/DU Fixlets this way - making them both applicable to one environment can cause BSOD on a vast majority of endpoints.
I understand the reasoning for this, having encountered the BSODs in April on my test systems and the painful workaround to uninstall the updates through WinPE. This is something Microsoft should have handled in the wusa installer, but since they didn’t I do thank IBM and BigFix for handling it themselves.
But I think there could still be a better way to do the relevance. I think there should be a way to say “CU or DU for July is not relevant if the July CU or DU is pending restart”, rather than basing it on whether the prior June update is present. They could both be relevant to start with, and have each of them make the other one non-relevant once an action is taken and before they reboot. “not pending restart <DU_GUID> and not pending restart <CU_GUID>”, or maybe checking the component statuses for the current update’s state rather than the previous month’s update state (I haven’t looked, but surely there’s a way in to tell in Component Servicing the status for an update that’s pending restart?)
My motivation is to keep only the current CU in my patch baselines, rather than having to include both the CU and DU because I don’t know the prior state of the targets. I understand that I could apply either the CU, or all of the DU packages, to get the system up to the same state; I’d just rather have fewer baseline components to manage.
Yes, agreed. Thanks for providing a preventative measure to the bsod. We’re in the same boat. When the new bundle methodology was released, we decided to only push CU every cycle as oppose to both BU and CU. Not having the ability to push only CUs month after month is breaking some of our internal processes.
The content team is discussing internally and performing tests in the progress. A decision is yet to be made. In the meantime, it’s recommended to include both the CU and delta in a baseline, which should not add much effort (if it does, please let me know the reason), and produce the same output.
Apologies for the delay, but the discussion and testing of the proposed change is still ongoing and we will not implement this change in the coming August release. I sincerely seek your understanding of our caution when dealing with potential BSOD.
Same as my previous comment, it is still recommended to put both CU and delta in a baseline.
Unfortunately, due to bandwidth consideration, the decision is not to change the current behavior of Delta / CU Fixlets. You could open an RFE to request for this.