Following my previous post on this topic a quick, preliminary “sneak peak” into the binary not only confirms abbodi86‘s disclosed findings (here and here) but it also provides additional insight: the IsBlockedSku built-in check appears to be dormant for now (it will only kick in once the metadata.json file is updated with a new BlockedSkus section – which doesn’t exist, yet).
The initial .cab file (dated Mar 20, 2019) was also re-released (on Mar 22, 2019). Its contents remain mostly the same (including the metadata) but the new cabinet is smaller (69Kb instead of 108Kb) due to a couple of subtle, tiny changes:
-A slightly different picture for the nag screen (a different, zoomed in laptop, slightly rotated/distorted using a lower resolution – an (un?)intentional “subliminal message” to make Windows 7 look “uglier” when compared to Windows 10?) and
-A different URL. The initial link
https://www.microsoft.com/windows/reasons-to-upgrade-to-a-new-windows-10-pc?OCID=win7_app_omc_win
changed to
https://www.microsoft.com/windows/windows-7-end-of-life-support-information?OCID=win7_app_omc_win
meaning that while Windows 7 users were previously redirected to
https://www.microsoft.com/en-us/windows/windows-7-end-of-life-support-information
(a land page primarily focusing on the EOL support information)
they will now be redirected to
https://www.microsoft.com/en-us/windows?OCID=win7_app_omc_win
(a land page primarily enticing you to buy a new Windows 10 PC)
This subtle, but enlightening shift of focus (from presenting EOL support information first, at the top of the page to a page that dives straight into a blatant consumer marketing campaign) raises a few red flags, if you ask me – contradicting PKCano’s optimism (it sure looks like GWX v2.0 is coming up… hopefully I’m wrong). IMHO it is a very good reason to hide, block and ignore KB4493132.
Regarding the speculation about the weird triggering conditions of the KB4493132 update being offered only to some (apparently, not all) users sharing the same targeted OS editions, similar settings and the same installed patches, RDRguy’s reply was right on the spot:
“Maybe having the Mar servicing stack update installed triggered being offered KB4493132.”
Indeed.
Unfortunately for RDRguy, his decision to go ahead and install the March Servicing Stack Update (SSU) KB4490628 (despite Woody’s MS-DEFCON system advising to wait and hold back while we’re still at MS-DEFCON 2) might have been a really bad idea.
Back in October, I posted about the KB3177467 (SSUv2) release. Well, it appears that Microsoft “messed up” (?) – big. Again.
You see, KB4490628 (the 2019 SSUv3 package, digitally signed with and using a build date of February, 2019) is version 6.1.1.2, marked – wrongly – as an “Update” Package (like SSUv1 was) and not – rightfully, as expected – as a “Security Update” Package (like SSUv2 was).
Meaning, the version numbering increment got messed up again: SSUv1 was v6.1.1.1, SSUv2 was v6.1.2.5 and SSUv3 is now v6.1.1.2!
Problem #1: Because KB4490628 (SSUv3) is missing the extended package ‘exclusive=”true”‘ metadata tag, it will NOT remove KB3177467 (SSUv2) automatically.
Thus, if you install KB4490628 (SSUv3) you will mess up your Windows 7 Servicing Stack and end up with both KB4490628 (SSUv3) and KB3177467 (SSUv2) installed.
Problem #2: Worse, keeping both installed will throw you into a jar of pickles and create a conflicting issue between the two
C:\>dism /online /get-packages /Format:Table|findstr KB3177467 Package_for_KB3177467~31bf3856ad364e35~amd64~~6.1.2.5 | Installed | Security Update | 2018/10/10 01:23 C:\>dism /online /get-packages /Format:Table|findstr KB4490628 Package_for_KB4490628~31bf3856ad364e35~amd64~~6.1.1.2 | Installed | Update | 2019/03/27 01:23
or three (if you kept SSUv1) packages:
C:\>dism /online /get-packages /Format:Table|findstr KB3177467 Package_for_KB3177467~31bf3856ad364e35~amd64~~6.1.1.1 | Superseded | Update | 2016/09/22 01:23 Package_for_KB3177467~31bf3856ad364e35~amd64~~6.1.2.5 | Installed | Security Update | 2018/10/10 01:23 C:\>dism /online /get-packages /Format:Table|findstr KB4490628 Package_for_KB4490628~31bf3856ad364e35~amd64~~6.1.1.2 | Installed | Update | 2019/03/27 01:23
Now, sit tight and get comfortable (this is tricky – and messy): the KB4493132 “EOL nagging package” is version 6.1.2.2. See where this is coming (and what the side effects might be)?
The apparently “random offering” of KB4493132 might be related with the installed SSU version(s). There might be dragons. And multiple, unforeseen conflicts coming up.
Microsoft’s (bad? intentional?) decision to increment version numbering by “rolling back” from SSUv1 up to SSUv3 (OVER SSUv2, which has a HIGHER value than SSUv3!) may very well be messing up the Windows 7 Servicing Stack (again) and creating additional conflicting scenarios.
Regardless of what you did with SSUv1 after installing SSUv2 (I simply removed it, because I still don’t see any point in keeping a superseded leftover; others preferred to keep it, like GTP did – but it really doesn’t seem to matter, at all), installing SSUv3 “as it is” right now is, IMHO, a bad idea and a risky move. If you happen to do so you WON’T be able to uninstall SSUv2 (since it has a HIGHER version than SSUv3) and you WON’T be able to remove SSUv3 neither!
Once KB4490628 (SSUv3) is installed, the commands that could be used to remove SSUv3 and SSUv2
dism /online /remove-package /packagename:Package_for_KB4490628~31bf3856ad364e35~amd64~~6.1.1.2 dism /online /remove-package /packagename:Package_for_KB3177467~31bf3856ad364e35~amd64~~6.1.2.5
will both fail miserably with a 0x800f0825 error.
To revert back the situation you will need to resort to System Restore or a previous image backup.
Currently, we can only hope for the best (that Microsoft will eventually realize the goof (?) and re-release a new, fixed KB4490628 (SSUv3) update with a proper version number of 6.1.2.6 or above).
On the other hand (conspiracy theories aside), Microsoft might as well do nothing: intentionally or not, the KB4490628 (SSUv3) might be Redmond’s way to pass the message along, loud and clear: “-Time’s up, R.I.P. (EOL support) Windows 7!”
Right now, I’m just as clueless as anyone else about what will happen. Fixing KB4490628 (SSUv3) is probably not a top priority to Microsoft. That leaves us (users) with the “choice” (decision) to upgrade, or not, the Servicing Stack (from SSUv2) to SSUv3.
If we don’t (and we keep relying upon SSUv2), will WU (or, alternatively, the updates downloaded directly from the Microsoft Catalog) continue to work? For how long? 🙁
