Group hopping A->B->A

Topic

New Reply

Does the term Group B describe a method, or define a status?

The question was brought to mind again by @OldBiddy ‘s comment in one of the Win7-SSU topics.

Sheesh, this is disappointing about the forced telemetry if one stays with Group A. I don’t think I could revert to Group B at this point, so I guess I’m stuck with this when it starts in October.

I do see that to have a pristine state that can be achieved by the pure application of the Group B method requires reverting to a artificial theoretical 2016 state and proceeding through the list until current. But I also believe that an up to date (August 2018) Group A system could apply the Group B method for an indefinite period without causing internal difficulties.

Then the system owner would have the option to receive a Cumulative Rollup Update (Group A method) at some future date that fits their needs. This future date may never come, as we are in a dwindling number of months until end of life. (Please direct all alternative OS suggestions to a topic in Other Platforms > Linux for Windows Wonks, thanks)

Following this suggestion would not create the same internal state boasted by Group B adherents from the beginning. But would seem to allow some flexibility for owners who think like Lounger OldBiddy. Is this hybrid method appropriate or should it be dismissed as not workable?

2 users thanked author for this post.

Sueska, OldBiddy

Reply | Quote

Replies

Group B people can start installing the Monthly Rollup through Windows Update at any time (obviously). If so, it would wipe out the benefir(s)? of having been in Group B from the time they started the practice.

Group A people can start manually downloading/installing SOs and IE11 CUs (Group B method) at any time also (obviously). If they wanted to be “pure” Group B, it would entail uninstalling all updates after Oct. 2016, then manually installing the SOs and IE11 CU since that time. But the Group B method can be used going forward from any given Group A point.

That brings us to the current situation. Beginning with the 2018-09 Preview Rollup and going forward, MS is going to include the part of the telemetry in the Month Rollups that the Group A people have been so far able to avoid (KB2952664 for Win7 and KB2976978 for Win8.1). To continue to avoid this telemetry, represented by KB2952664 and KB2976978, Group A people can switch to the Group B method (with the realization that they are not removing the part of the telemetry that they have until now accepted). As long as MS doesn’t decide to include the same thing in the SOs!!!!

So, yes, either group can move either way at any given point, with those caveats considered.

I believe compatprovider.dll.mui is the culprit.

11 users thanked author for this post.

Chessie, cesmart4125, OscarCP, walker, WildBill, SueW, jburk07, Sueska, Elly, OldBiddy, abbodi86

Reply | Quote

Thank you, @PKCano

I appreciate you checking my thoughts and pointing to compatprovider.dll.mui

I look forward to reading Woody’s thoughts on the available options when the MS-DEFCON changes. For now, I will continue to hold fast.

Reply | Quote

Well, well. And they said Group B was doomed.

1 user thanked author for this post.

SueW

Reply | Quote

And, I must ask again…

why is Microsoft so determined to collect telemetry from an operating system (Windows 7) that they have no intention of releasing any more feature updates and improvements for (besides the questionable security updates) and an operating system that they’ve been so desperately trying to kill off since the release of Windows 10?

Reply | Quote

In my opinion, Microsoft isn’t profiting from the data collected via telemetry, either from Windows 7, Windows 8.1, or Windows 10. I believe that their primary use of this data is to improve Windows’ performance and security. They have disbanded their testing dept and instead are using AI, along with telemetry data, to improve the security and performance of Windows.

The only way they “monetize” the telemetry data is with their own products. In other words, they try to get you to use their own products via ways that their telemetry data tells them would be most effective. But they aren’t providing that telemetry data, or their analysis of it, to other companies.

Group "L" (Linux Mint)
with Windows 10 running in a remote session on my file server

2 users thanked author for this post.

Chessie, jburk07

Reply | Quote

The general consensus seems to be that due to SatNad firing the QA team, they are now using telemetry data to do the job for them. 7 & 8.1 still get updates, so the telemetry data on them appears to also be geared towards making parallels and baselines about a particular update and whether or not it will fail, and why.

2 users thanked author for this post.

Chessie, jburk07

Reply | Quote

He-he @TSurfingP – Group B just got revived for me, even though late to the party. Already do group B with 2 other pcs, so not much of an effort to add one PC more starting next month. I know I won’t have as “pure” of a system as those who started B early, but I am perfectly ok with that.

Reply | Quote

I hope Woody will tell us whether he recommends we stay with Group A or go back to Group B. He had a CW post awhile ago about not knowing what these telemetry programs actually do:

https://www.computerworld.com/article/3168397/microsoft-windows/microsoft-re-releases-snooping-patches-kb-2952664-kb-2976978.html

Reply | Quote

For those wanting to stay in Group A and still neutralize the telemetry added, see

@abbodi86 ‘s Topic on how to Neutralize telemetry and sustain Win7/8.1 monthly Rollup model .

5 users thanked author for this post.

OscarCP, walker, jburk07, Elly, OldBiddy

Reply | Quote

@oscarcp # 229804, @The Surfing Pensioner #229807, and @anonymous #229810 from the other thread,
https://www.askwoody.com/forums/topic/ms-defcon-4-with-the-win7-monthly-rollup-now-working-its-time-to-get-everything-updated/#post-229934:

My original post was removed from the other thread for being off-topic so I’m reposting here. The original text was deleted so I’ve tried to reconstruct it.

I was joking a little when I said there was “no going back” to change to Group B now that I’ve installed the October 2018 rollup.

If I wanted to go to Group B now, I realize I could still restore using the image I made before installing the October rollup, or I suppose I could uninstall the October rollup (or in the future, uninstall and keep uninstalling back to the September 2018 update), if that would also really remove the KB2952664 telemetry. Or maybe there’s some other method I’m not aware of. Then I would probably just start patching Group B going forward from there rather than trying to roll back to a “safer” time.

So it’s not that there’s no going back, but rather that there’s no longer the easy option to just start patching B-style at any point. I’m not as likely to switch now since it would take some effort to roll back first. As it is, I can just continue in Group A but also block the KB2952664 telemetry by following @abbodi86‘s manual instructions (AKB 2000012, https://www.askwoody.com/forums/topic/2000012-neutralize-telemetry-sustain-win-7-8-1-monthly-rollup-model/), which are pretty simple and involve only one extra step after the updates.

I don’t think that Group B patching is too difficult to follow, nor do I feel that anyone has tried to dissuade me from trying it. I think the instructions given by the MVP’s are very clear, along with all the great feedback provided by Group B patchers. I just find it simpler to do things from Windows Update *if and when possible,* especially since some patches (Office updates? .NET rollups?) are done through Windows Updates anyway. I also haven’t had any problems caused by Group A patching; it’s not as if there are problems I could have avoided if I had followed Group B.

So at least for now, the combination of Group A plus blocking the telemetry works best for me for the remaining 14 months. Of course, if some unforeseen new difficulty should arise, I might need to reconsider Group B in the future. Who knows what obstacles Microsoft might throw in our way?

Linux Mint Cinnamon 21.1
Group A:
Win 10 Pro x64 v22H2 Ivy Bridge, dual boot with Linux
Win l0 Pro x64 v22H2 Haswell, dual boot with Linux
Win7 Pro x64 SP1 Haswell, 0patch Pro, dual boot with Linux,offline
Win7 Home Premium x64 SP1 Ivy Bridge, 0patch Pro,offline

2 users thanked author for this post.

OscarCP, The Surfing Pensioner

Reply | Quote

jburk07 wrote:

My original post was removed from the other thread for being off-topic

I couldn’t find anything that would suggest a post had been removed, when I looked…

1 user thanked author for this post.

jburk07

Reply | Quote

@Kirsty,

You’re right; I didn’t mean that the post had been removed, but that only the first sentence survived. The rest of the text was deleted, so I had to reconstruct it. Thanks for your help and response.

Linux Mint Cinnamon 21.1
Group A:
Win 10 Pro x64 v22H2 Ivy Bridge, dual boot with Linux
Win l0 Pro x64 v22H2 Haswell, dual boot with Linux
Win7 Pro x64 SP1 Haswell, 0patch Pro, dual boot with Linux,offline
Win7 Home Premium x64 SP1 Ivy Bridge, 0patch Pro,offline

Reply | Quote

@jburk07 , I am that @anonymous #229810. I think your approach for your needs is an excellent match. I hope it makes sense when I say I’m actually indifferent to how others update or why. I only wish them the best success possible. And enjoy reading reports of success.

My only purpose in that brief post was to attempt to address OscarCP’s Question Nº 2 of the moment directly above in #post-229804. I thank you for the cordiality of including me with the list of voices in that subthread. I believe you are trying to be every bit as helpful.

You may be interested to see where more is presented from that point:
https://www.askwoody.com/forums/topic/the-ease-of-group-b-patching

Reflecting back to you in like manner, I had considered avoiding the KB2952664 functionality altogether by hopping as discussed in this topic. After reading more, I am also satisfied by abbodi86’s instruction and followed the Group A method in AKB2000004, followed after restart with AKB2000012. Every indication is success.

2 users thanked author for this post.

Elly, jburk07

Reply | Quote