I agree that this is not an every-day-scenario. This particular case is a maybe once in a year - scenario. (Or whenever, or how often, MSFT decides to not do proper testing of their major updates) If no admittance, why still release
security updates for products (without KB2919355)? .
Because they screwed up.
I do not agree with you when you say keep your servers up to date and your patchmgmt will be alright. Its not as easy as it might sound.
So Im going a little OT here:
Ever since the embarrasing first release of the original KB2919355 - and the actions taken by MSFT thereafter - there has been so many superseding releases of all prerequisites for (KB9919355) and thus has forced customers into totally
incoherent patch-levels. I count 5 of them, but there might be more, still.
Currently, the most current (and valid) prereq for the KB2919355 is update is KB2920189 which is a weird article (about UEFI) that actually contains KB2975061 that is the real prereq here. Which in turn has superseded quite a few others.
Dont play the card keep your server up to date. MSFT needs to stick to the trustworthy computing initiative founded over ten years ago.
Im actually surprised that there is such little debate about this particular f-up.
But back to topic:
I will most certainly post an RFC at connect.micrsosoft.com as I am certain this is not the 1st, 2nd or last time patch-management admins will deal with issues like these. Most of them (that are not using MBSA) may not even be aware of
the situation, still.
There should be a more comfortable way to make up for MSFT 2nd Tuesday fails.
I must withhold my position. MSFT needs to incorporate the ability to handle their OWN mistakes into ALL their own products (all products). Don't you agree?
Do a bare-metal install of any 6.3 and see the complexity in windowsupdate.log while you contact MU.
BR, Chris
-
Edited by
JLCM
2 hours 2 minutes ago