Search Results for '3177467'

[ch100]

This is an ongoing discussion.
I would say the SSU should be installed by itself instead of has to.
There are SSUs indeed which have to be installed by themselves, KB3177467 being a good example for Windows 7.
Most other SSUs are not required to be installed separately, although this is certainly the best practice when installing manually.
An example in favour of my statement would be that when installing from Windows Update, the SSU is bundled and installed with other updates in one step.
Another one would be when using WSUS (or SCCM leveraging WSUS), although the SSU comes separately there, it can be bundled and installed with the other updates coming on Patch Tuesday to avoid unnecessary multiple reboots. At least this is the most common practice.

[abbodi86]

Server 2012 R2 was skipped too 🙂

what’s wrong on having SSU for one or certain Windows only?
they never were synced together for downloevel Windows, except for last few months (KB3177467 was released on its own for Win 7)

and yes, 2019-12 SSUs for Win7/2008/2008R2 are only to update ExtendedSecurityUpdatesAI.dll component

1 user thanked author for this post.

nazzy

[PKCano]

You should only need the SSUs I linked to. But installing old SSUs, like KB 3177467 from Dec 2018, won’t hurt anything as long as it’s done in chronological order and one at a time. It’s just not necessary unless the later ones won’t install.

1 user thanked author for this post.

tom341

[tom341]

So on the servicing stack side of this would i need to also install KB 3177467 (Dec 18 ssu)? or just the latest which you linked to?

[EP]

but KB3020369 is an obsolete update and KB3177467 should be used instead. avoid using KB3020369 since windows update does not offer that one anymore

KB3177467 was originally released in late September 2016 but got a V2 release on October 2018 as a “security update”. download & install KB3177467 from MS Update Catalog:

https://www.catalog.update.microsoft.com/Search.aspx?q=3177467

• This reply was modified 11 months, 2 weeks ago by EP.
• This reply was modified 11 months, 2 weeks ago by EP.

[EP]

whoops. it seems the KB4516655 servicing stack update fails to install on Win7 systems without the previous SSU KB4490628 update installed (MS made a boo-boo on their support article 4516655 saying it superseded the KB4490628 update but in reality it was not. on the MS update catalog site, MS got the info about KB4516655 correct where it does NOT replace KB4490628 but KB4516655 does replace KB3177467)

so I take back my statement of KB4516655 superseding KB4490628 in my previous post as KB4516655 truly requires the older KB4490628 update installed first.

• This reply was modified 1 year ago by EP.

[EP]

all except KB3020369 which the August 2018 Win7 ISOs have KB3177467 instead

[EP]

AVOID installing KB3020369 as THAT update is OBSOLETE and replaced by newer updates like KB3177467 and KB4490628.

Substitute KB3020369 with either KB3177467 or KB4490628 as either one can be installed first

[PKCano]

There is a new servicing stack since that method was written. You should install KB4490628 in place of the older KB3177467. But basically, that is still a good method.

[ardvark]

One more question… does Kb4490628  require removal of the old Stacking Kb3177467 or will the ne one just replace it?

Regards, ardvark

[Speccy]

-For separate updates, CBS handle files per assembly component version, update package version does not matter at all

you can install 10 SSUs, CBS is smart enough to make the latest one with higher components version to be effective

in this case: KB4490628 v6.1.7601.24383 < KB3177467 v6.1.7601.23505

Thank you!!! Now it suddenly made sense. 🙂

I just dig into the first “main” .mum (of the “package chain”, let’s put it this way, overlooking the fact that the whole package contains multiple .mum files) and didn’t realize that the “final” Servicing Stack version was both at the end of the “package chain” (in the last .mum) and also in the package contents (in the very own name of the sub-directories!).

But you meant

“KB4490628 v6.1.7601.24383 > KB3177467 v6.1.7601.23505″

right? 🙂

– SSUs are always safe, Windows users should accept this fact and stop struggling about to install them or not

He he… Point taken. 🙂 But I was not struggling (or expecting anyone here to go into the lengths I did), just testing. 😉

– removing the permanence tag is what made KB3177467 to be removed,

Yes.

editing KB4490628 mum file has no effect here

Right. In this case, I simply edited it for “compliance” (and to describe it correctly as a “Security Update”).

separate update package name = no direct relation or effect (SSUs)
chained update package name = auto supersedence (W10 CUs or W7 Monthly Rollups)

I see. That explains why KB4490628 won’t remove KB3177467 (only new, updated releases of a given package – or an updated, different package that embedds that one as one of multiple dependencies [chained updates] – may actually remove it).

abbodi86, once again: Thank You. I was wrong. I didn’t understand correctly a few important things about the package supersedence model. You posted perfectly: shortly, but enlightening – and generously shared invaluable knowledge (we grasshoppers try to learn something new each day… you taught me a lot, today). 🙂

2 users thanked author for this post.

Elly, RDRguy

[abbodi86]

– For separate updates, CBS handle files per assembly component version, update package version does not matter at all

you can install 10 SSUs, CBS is smart enough to make the latest one with higher components version to be effective

in this case: KB4490628 v6.1.7601.24383 < KB3177467 v6.1.7601.23505

– SSUs are always safe, Windows users should accept this fact and stop struggling about to install them or not 😀

– removing the permanence tag is what made KB3177467 to be removed, editing KB4490628 mum file has no effect here

separate update package name = no direct relation or effect (SSUs)
chained update package name = auto supersedence (W10 CUs or W7 Monthly Rollups)

Regards.

5 users thanked author for this post.

Elly, RDRguy, Speccy, ve2mrx, PKCano

[Speccy]

Hi abbodi86,

I do realize KB4490628 is a separate update from KB3177467 (not only because the KB numbers are different), but shouldn’t the former be replacing (superseding) the latter?

And, if so, isn’t the incremental version numbering relevant?

In which case yes, the exclusive tag DOES have an interest here and yes, installing multiple SSU versions with conflicting version numbers MIGHT be causing undesired side-effects (of which the fact of the KB4493132 “EOL nagging update” not being consistently offered is a minor issue, compared with the potential problems that might arise due to the SSUs conflicting and blocking each other).

You are totally right in the assumption that, under “normal” circumstances, SSUs are usually safe and should be installed prior to other security and cumulative updates. I also admit having the wrong info: in fact, I already wrote before that I’m NOT an MVP – just another dude here trying to help people – and, therefore, I lack the skills and expertise required to fully grasp the technical complexity and subtle inner details of how XML works (and Microsoft uses it). Therefore, please correct me and help us to better understand and handle this complex subject. I do appreciate reading and learning from the valuable comments and knowledge that you and other MVPs kindly share with us! 🙂

I am truly sorry for over-complicating things up (I really tried not to…) but, right now, from what I’m able to understand about the inner details of how SSUs work I can not endorse your recommendation to promptly install KB4490628 (SSUv3) ASAP. Instead, I can only recommend people to WAIT and see if Microsoft releases an updated (fixed?) version of the SSU – that will automatically handle and fix what, in my view, is a complete mess.

Most of our readers should stop reading right now and decide if they should, or should not, install KB4490628 (SSUv3) immediately or, at least, wait until we’re at MS-DEFCON 3: what follows below is not for the faint-hearted.

You see… I was actually able to create a working, updated version of my Windows 7 system with SSUv3 *ONLY* and SSUv2 removed (my “beta testing” branch). Here’s how:

cd %WINDIR%\servicing\Packages
takeown /F Package_for_KB3177467~31bf3856ad364e35~amd64~~6.1.2.5.mum /A
takeown /F Package_for_KB4490628~31bf3856ad364e35~amd64~~6.1.1.2.mum /A
cacls Package_for_KB3177467~31bf3856ad364e35~amd64~~6.1.2.5.mum /E /G BUILTIN\Administrators:F
cacls Package_for_KB4490628~31bf3856ad364e35~amd64~~6.1.1.2.mum /E /G BUILTIN\Administrators:F
notepad Package_for_KB3177467~31bf3856ad364e35~amd64~~6.1.2.5.mum

Removed the ‘permanence=”permanent”‘ attribute of the <package> tag, saved the .mum file and exited Notepad. Then,

notepad Package_for_KB4490628~31bf3856ad364e35~amd64~~6.1.1.2.mum

changed the ‘releaseType=”Update”‘ attribute to ‘releaseType=”Security Update”‘, added the

<mum:packageExtended xmlns:mum="urn:schemas-microsoft-com:asm.v3" exclusive="true"/>

tag right above (before) the closing </package> tag, saved the .mum file and exited Notepad. Finally, I removed SSUv2:

dism /online /remove-package /packagename:Package_for_KB3177467~31bf3856ad364e35~amd64~~6.1.2.5

and now I’m left with (a properly installed?) SSUv3 *ONLY*:

C:\>dism /online /get-packages /Format:Table|findstr KB3177467

C:\>dism /online /get-packages /Format:Table|findstr KB4490628
Package_for_KB4490628~31bf3856ad364e35~amd64~~6.1.1.2
| Installed | Security Update | 2019/03/27 01:23

Under Control Panel > All Control Panel Items > Programs and Features > Installed Updates, KB4490628 is listed as

Security Update for Microsoft Windows (KB4490628)

with no “Uninstall” option (as expected, because it is a permanent update).

I tried WU: it appears to be working well. I rebooted and tried again: all OK.

Isn’t that how we should expect KB4490628 to behave like? 🙂

1 user thanked author for this post.

RDRguy

[abbodi86]

– I get KB4493132 without any update installed, vanilla Win7 SP1 installation

you are overcomplicate the situation and have wrong info 🙂

– KB4490628 is separate update from KB3177467, they don’t have any CBS relation or obligated to have inceremental version

– the exclusive tag has no interest here, KB3177467 v2 cannot be removed except with new KB3177467 v3
or modifying the package .mum file to remove permanency
https://forums.mydigitallife.net/posts/1154312/

– while KB4490628 itself is classified as general Update, Windows Update metadata classify it as Security Update, and what matter most
but yes, they should have make it seurity update to avoid confusion

5 users thanked author for this post.

Elly, RDRguy, Speccy, PKCano, woody

[Speccy]

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? 🙁

5 users thanked author for this post.

Elly, RDRguy, OscarCP, ve2mrx, woody