Re: reality
So even on a test environment the DC issue didn't fire at install time or on the initial re-boot, it apparently causes the machine to crash after startup and restart periodically.
So you would need to let it run in your test lab long enough to crash and reboot a few times. Likely most organizations can't devote that deep a testing for every patch run, and it slipped by some as a result. The hyper V thing is more glaring, but showed up about when you would expect for tiered deployments.
Storage backends and Hypervisor Hosts are always some of the last things we get to patch, bout because the impact of a bad patch is high, but also because of the need to down so much of the rest of the deployment to get to them.
So the patches get applied like reverse growth rings, even in testing. If the bug only shows up on the equipment in those last, inner tiers, than we get what we saw with this months patches.
Instead of pointing fingers at each other and our test environments, we need to start pointing finger back at M$. Yes they need to raise their QC game, but they also need to unbundle the individual fixes so we can roll back a single issue w/o having to remove every fix from that month.
The attackers are already retroengineering the patch they issued, and can weaponize any of those exploits in a couple of days. Several of those were auto-exploits from the preview pane level nasty. That level of exploit should be released as a spot fix separate from the roll up to allow the most serious threats to be addressed even in the event of a problem with the monthly roll-up patch.
Biting the hand that feeds IT
