Replies

GoneToPlaid wrote:

KB4490628 apparently is not superseded since it is still listed under installed updates.

You can have a superseded update installed and have it listed. Aside the fact that you’ll never see an SSU disappear in installed updates.

There’s always those who use RTM installation media, and applying the SHA-2 related updates of 2019 – as suggested by Microsoft – will take them nowhere.

https://support.microsoft.com/help/4569557

it is a “fall back” update if the superseded SSUs are uninstalled

Which they won’t be.

Once a servicing stack update is installed, it cannot be removed or uninstalled from the machine.

1 user thanked author for this post.

lmacri

so simply substituting the April 2015 SSU KB3020369 with the Dec 2020 SSU KB4592510 in the above instructions doesn’t seem like a viable option.

No, but it’s no necessity either. None of the post-April-2019 SSUs is an actual prerequisite to anything. In terms of replacing recommendations of KB3020369 your choice is KB4490628. This one is an actual prerequisite to all post-August-2019 updates including SSUs. It is an SSU requirement to any later SSU. Not to mention it’s MIA at Windows Update since the release of the August 2019 Security Monthly Quality Rollup. However KB4490628, like KB4474419, has not turned into a requirement for functionality of update search in August 2020 as falsely claimed by Microsoft.

1 user thanked author for this post.

lmacri

Does that mean that the standalone .msu installer for KB3020369 will now throw an error (“The update is not applicable to your computer“) after a clean reinstall of Win 7 SP1?

You are asking if any update will throw this error just by virtue of being superseded in general. The answer to this is NO. The superseding version must be installed for this to happen.

2 users thanked author for this post.

lmacri, GoneToPlaid

This article is outdated. There are no update scan slowdowns to fix anymore. KB3172605 has lost its importance, and so has KB3020369 as a) a prerequisite to a previously issue-fixing update and b) a superseded predecessor of KB4490628.

That being said, Windows 7 including SP1 can no longer be reinstalled with Windows Update working out of the box. Automatic selfupdate has been abandoned by Microsoft in January 2021. It takes manual download and installation of a post-2014 build of the Windows Update Client to enable update search, like the Windows Update Client March 2016, KB3138612.

Efforts to restore Windows Update are futile on Windows 7 RTM.

3177467 doesn’t make a difference either. The 3-somethings are relics of the pre-SHA-2-era. Then again you can’t start off with anything newer than KB4490628 because it’s a prerequiste to the later SSUs.

KB4490628 ist the one to start with.

3 users thanked author for this post.

MrChaz, Microfix, abbodi86

This is an issue with Windows 7 RTM. Install Service Pack 1.

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

Regards, VZ

anonymous wrote:

Because

Windows Update is discontinuing its SHA-1 based endpoints

therefore you have to install manually SHA-2 to be able to connect to WU endpoints.

It’s not true.

Nothing needs to be installed to be able to connect to WU endpoints as long as it’s Windows 7 SP1 or higher. Actually nothing can keep it from connecting to WU endpoints. Windows Update cannot be made denying service by removing KB4474419 or KB4490628.

The truth is that whenever an OS is affected by the changes pertaining to article 4569557, it cannot be fixed. Whenever an OS is not affected, that means it’s supported and requires no mitigation.

Particularly Windows 7 RTM and and SP1 cannot be treated likewise, and no case exists in which KB4474419 and KB4490628 become prerequisites to even using Windows Update.

Regards, VZ

Hi lmacri,

yes, KB4474419 can be replaced by KB4039648 regarding SHA-2 support, as well as by KB4056448, KB4056564 and KB4090450, all released well before August 2018. So yes, you can have KB4517134 installed while retaining build 6002, because neither the update itself nor its two prerequisites do necessarily change it.

Regards, VZ

4 users thanked author for this post.

abbodi86, 7ProSP1, lmacri, Cybertooth

• How did you continue to manually install mpas-fe.exe installers between October 2019 and August 2020 that were signed exclusively with SHA-2 if you cannot install the KB4474419 (rel. 23-Sep-2019) that adds SHA-2 Code Signing Support?

The same way he was able to install the September 2019 SSU. If you’re lacking KB4474419, you’re not lacking a lot if you kept installing updates for 6.0.6002 after April 2017. SHA-2 support providing updates include KB4056448, KB4056564, KB4090450 and the March 2019 Security Monthly Quality Rollup.

• If you have managed to add at least one of the Service Stack Updates KB4493730 (rel. 09-Apr-0219) and/or KB4517134 (rel. 10-Sep-2019) why hasn’t your OS build changed to 6.0.6003?

Those SSUs just don’t change it.

2 users thanked author for this post.

7ProSP1, lmacri

It’s obvious to me you’re out of luck installing updates that change build 6.0.6002 to 6.0.6003.

2 users thanked author for this post.

7ProSP1, Cybertooth

That solution is not about deleting some journal on some volume. It’s about freeing up space on a too small system partition. It’s an issue you just don’t have with no “system reserved” exisiting. No “system reserved” means the system partition you have anyway is way larger than 100 MB, and not having a “system reserved” is perfectly healthy for a Vista installation. The whole concept of “system reserved” didn’t surface until the Windows 7 era.

1 user thanked author for this post.

Cybertooth

I’d aim to reclaim it with something simple like Extend Volume in the disk manager.

Not going to happen. It takes a third party tool and moving two partitions to achieve this.

Right, but it also means Microsoft is giving wrong advice regarding Windows 7 at help article 4569557.

https://support.microsoft.com/en-us/help/4569557/windows-update-sha-1-based-endpoints-discontinued

“Can be mitigated by manually installing KBs” neither applies to RTM nor to SP1, where the issue doesn’t exist in the first place.