Win7 End Of Support - KB4524752 MS Nagging Has Started

[Tripredacus]

I am going to go out onto a limb and say that there is nothing built-in Windows 7 to produce those kinds of messages. So for those who use the "as needed" update method instead of the "all critical/all" updates method may not ever see anything.

[Mathwiz]

On 1/15/2020 at 9:16 AM, WalksInSilence said:

Had a later update offered too: another servicing stack update:- 

2020-01 Servicing Stack Update for Windows 7 for x64-based Systems KB4536952.

Like the earlier two it downloaded and installed without any issues, so far.

That seems suspicious to me. Why do we need a servicing stack update at end of service?

Quote

This update makes quality improvements to the servicing stack, which is the component that installs Windows updates. Servicing stack updates (SSU) makes sure that you have a robust and reliable servicing stack so that your devices can receive and install Microsoft updates.

The vagueness of that description doesn't exactly quell my paranoia. For now, I think I'll pass.

[dencorso]

22 minutes ago, Mathwiz said:

The vagueness of that description doesn't exactly quell my paranoia. For now, I think I'll pass.

But, meanwhile do ...

On 1/13/2020 at 4:44 PM, dencorso said:

[...] get yourself a full-body Velostat gimpsuit, 'cause just a cap is obviously not enough. 

[WalksInSilence]

18 hours ago, Mathwiz said:

That seems suspicious to me. Why do we need a servicing stack update at end of service?

The vagueness of that description doesn't exactly quell my paranoia. For now, I think I'll pass.

I've been suspicious of all MS updates for years but...................................

Just because Win7 OS updates are no longer being provided by MS you will still likely have other MS programs/tools on your PC that can be updated, most notably MS .NET Framework. Those will or at least should still be provided by the MS update service for as long as they're compatible. 

When MS decided to pull the plug completely on MSE support for Windows XP I had to install a new AV on the virtual machine I was using running XP. All went well installing it at first but then it stalled saying it needed the most up to date version of MS .NET Framework. I went to the XP MS updates page expecting to be told it is no longer supported and there were about half a dozen 'important' downloads available including MS .NET Framework and a similar number of optional ones.

I updated  MS .NET framework on the XP VM without any trouble and the new AV installed perfectly. I've updated my XP VM a few times since then too with new .NET Framework ones and a couple of others I think.

Stack updates will likely still be relevant for Win7 for the same purposes.  

 

[Tripredacus]

Notice: anything relating to the ESU Bypass will fall under rule 1.a until further notice.

[WalksInSilence]

Has anyone here in this thread actually mentioned it? I've been back over the posts and if someone did it passed me by.

That ^ actually does more to advertise the tool than anything else I've seen here. Perhaps I'm misinterpreting the intended purpose of the post. 

[Tripredacus]

Yes, the posts have been hidden.

Not really concerned with people using it or knowing it exists. As a wise man once said "we do not police the internet" ... the notice is in regards to discussion on MSFN only.

[Jody Thornton]

@Tripredacus One thing.  Is the topic that was "hidden" any different than POS Ready Updates for XP?  That also bypassed the proper terms of agreement for XP, no?

 

[dencorso]

It's different. For the Windows Embedded POSReady 7 updates, one has to get them from the MS Update Catalog (they don't come through MU/WU) but they just work, as in the case of Server 2008 updates for Vista. The other involves actively faking a permit, which is against our rules.

[Jody Thornton]

I meant the XP ones - that was a registry hack, yet there was a whole thread on it, since that made the end-user misrepresent what the OS was.  Just sayin' 

 

Edited January 22, 2020 by Jody Thornton
I misspselled "user"

[dencorso]

Still it's not the same. The POSReady 2009 hack simply made WU/MU deliver the updates, which otherwise were also available (and remain so) from the MS Update Catalog. Those in ESU won't be available unless by explicit unabashed deceit.

[greenhillmaniac]

12 hours ago, dencorso said:

Those in ESU won't be available unless by explicit unabashed deceit.

Actually, they will be available in the Update Catalog and documented in the Windows 7 Update History page. The only thing the bypass does is tell the Windows servicing stack that indeed the system does have the ESU bit turned on. No licenses are faked or bypassed. WU won't be able to fetch the ESUs. That will be up to the user (in the same fashion we've been doing with Vista and 8.0).

Still, if it's a moderation decision that we won't have any more discussion on the issue, I won't speak about it ever again.

[Tripredacus]

As put in the FAQ, the process of using ESU is laid out. There is an update to install and then the user will be able to put in a product key (MAK) that specifically licenses the system to receive ESU. It even says that Windows Update should still work as usual.

Quote

The updates will be delivered through all the usual update delivery processes, including SCCM Current Branch, WU, WUfB, and WSUS. The update will be programmed to look for the MAK activation on the endpoint, and it will install on only those systems together with the MAK key.

As far as we are concerned, if any new updates appear on the Update Catalog site, we can talk about them. It is just the mechanism to modify the OS to fool the updates or update mechanism to install updates that is what we are talking about being against the rules.

Time will tell if something changes, if we are still around in 2023 when this program expires, we can think then how we should handle such topics.

[asdf2345]

On 1/22/2020 at 9:21 PM, Jody Thornton said:

I meant the XP ones - that was a registry hack, yet there was a whole thread on it, since that made the end-user misrepresent what the OS was.  Just sayin' 

 

I think what is meant is that the ESU updates require payment, so bypassing that is considered stealing. Besides Windows updates just make the OS slower and more unstable,

[WalksInSilence]

Oh oh!

Niche, very niche issue has appeared on one of my two Win7 64bit PCs since the January MS update installs.

I did not notice it until yesterday when I tried to open an encrypted volume made by a particular free encrypted volume program. In fact I have such volumes each on the three main drives SDD/2xHDDs I use. They open with a password and I found that when I opened any one of those, on whatever drive, I had an error message I'd not seen before about a "General problem opening the volume". When I closed it and re-entered the password it opened perfectly. Likewise the other volumes too.

But restart or from cold boot this behaviour persists first time the first volume is opened. Utterly consistent but it should not be happening.

Initial thought was a SSD/HDD issue but when I found the behaviour was system wide I ran CHKDSK on every drive and they all came through perfectly. System File Checker found no problem on the primary drive either. Full system scans with AV/Anti-Spyware/Malware/Adware produced nothing amiss.

I tried:-

1). Creating new encrypted volumes - same problem.

2). Thorough uninstall of the encryption program using Revo and then clean re-install - same problem.

Eventually I decided to use a pre-Windows January update Restore Point (11.01.20) to roll the system back. A number of other programs I'd updated since then were shown as likely to be affected along with the Windows update but I took the risk. All went perfectly apparently, took some time but it eventually rebooted OK.

Ran several tests on the encrypted volumes, restarting the PC again twice just to confirm it and everything back to normal.

Now I've updated all those other programs, about a dozen, updated since the Restore Point date. Restarted the PC at various points and the encrypt volume behaviour opening is still back to normal.

So not any of those other programs can be the culprit. All that is left now are those three MS January updates mentioned earlier:-

KB4534310: Windows January Rollup.

KB4536952: Service stack update.

KB4535102: 2020-01 Security and Quality Rollup for .NET Framework 3.5.1, 4.5.2, 4.6, 4.6.1, 4.6.2, 4.7, 4.7.1, 4.7.2, 4.8 for Windows 7 and Server 2008 R2 for x64

It has to be one of them that caused the problem and my money is on the .NET Framework KB4535102.  I'm going to try each one in order but wait and see if anyone else reports anything peculiar.

However here's the thing I do not understand: my other Win7 64bit PC was updated exactly the same way earlier, in fact I'd updated that first, and has experienced no similar problem. I've tested and restarted it multiple times.

I almost wished it had produced the same result because now I'm wondering what is on this PC that has made this minor but unwanted behaviour unique to it.  

Edited January 25, 2020 by WalksInSilence