Replies

if I turned off TPM, would that stop any Windows 11 upgrade prompts from appearing?

Not exactly. you’ll still get a Windows 11 box, but it will just say that your hardware isn’t compatible rather than offering to, um, “upgrade”.

Also, if you made the mistake I did and installed the enablement pack without having first installed KB5022906, KB5022906 becomes suppressed. KB5022906 contains the features that the enablement pack is supposed to enable! So what was enabled? Don’t know.

If you do that, then you’ll see Win 22h2 but only build 2604 vs if you did it the “right” way. Install KB5022906 and then the enablement and you’ll have build 2673.

Once you do KB5023696, the version and build will update to the latest and greatest papering over the mistake.

And, as of today, pi day, this is already no longer an issue. Today MSFT released…

2023-03 Cumulative Update Win 10 21H2 x64 KB5023696

…which supercedes the 21H2 version of KB5022906. That is, with TRVI 21H2, KB5022906 will no longer be offered. Instead you’ll get KB5023696. After a reboot, you can change TRVI to 22H2, and then the 22H2 feature update will be offered. Basically, back to business as usual.

In the event you already installed KB5022906, which suppresses the 22H2 update, KB5023696 is still offered and, if you install it, you’ll again get the 22H2 offer once you update TRVI.

Alright! I have news! This is my unlucky timing!

I used the awesome WuMgr tool (and VM snapshots) to exhaustively run through many update scenarios. The short story is, after applying

2023-02 Preview for Win 10 21H2 x64 (KB5022906)

the 22H2 feature update is no longer offered. This regardless of whether I set the target release to 21H2, 22H2, or unlocked; and regardless of whether I used InControl or gpedit to do the locking/unlocking. AFAICT both the InControl and gpedit methods are equivalent.

Starting from a fresh ISO 21H2 installation, using WuMgr I applied all previous updates one-by-one. I then used both methods (InControl and gpedit) to control version locking. In all cases, 22H2 continued to be offered when toggling 21H2 locking off (ie, either locking to 22H2 or unlocking altogether). Even as I started I intuited that this would be the case, because whenever the settings allowed 22H2 to be available, KB5022906 was no longer offered (all other 21H2 updates were still offered). So that told me that 22H2 and KB5022906 were probably mutually exclusive. But I continued to run through the updates one at a time, to be sure  that this would actually bear fruit.

Finally I ended up with no other updates available except for the KB5022906. Again, just to be clear, when I had the system locked to 21H2, only KB5022906 would show available. If I changed to 22H2-locked, only 22H2 feature update would show available. Then after installing KB5022906, the 22H2 feature update was no longer shown available.

The bad timing part here is that KB5022906 would obviously have only just come out (feb 14 2023). So no one would have experienced this until very recently.

We all know that available updates are based on prereqs, so sometimes an update isn’t made available until you install some predecessor. But another oddity in my journey was that only after applying 2023-02 security update (KB5022834), did the earlier dated 2022-08 security update (KB5012170) become available.

After KB5022906, About your PC shows

21H2 19044.2673, Experience 120.2212.4190.0.

When I rewind the state, unlock the target releases, and apply 22H2, About your PC shows

22H2 19045.2604 Experience 120.2212.4190.0

At this point, with target release set to either 22H2 or unlocked, WuMgr now does show the KB5022906 suddenly available again. However this time, the update is titled for 22H2 instead of 21H2, and the date is 2/21/23 instead of 2/14/23, even while the KB reference is the same. After installing it, the build# changes to match 21H2, in About your PC:

22H2 19045.2673 Experience 120.2212.4190.0

OK lastly, after reading KB5022906, I see it points to enablement pack KB5015684, which says that this update to 21H2 has the 22H2 features installed but “dormant” and that the tiny enablement pack (185k) will turn them on. So I feel quite confident that the correct update path for my existing 21H2 fleet is to install all updates, including KB5022906, then the enablement pack, then either remove the version lock or update the lock to 22H2.

What a ride!

I recognize that (now). But at the time I deployed 21H2, I was only aware of the registry method. All the machines I’m trying to update to 22H2 have had the registry changes applied to them.

I’ll do a test run on it using the gpedit method and see if 22H2 is presented … but that won’t help me except that I’ll know that gpedit is what I should have done all along.

I’ll report back my findings

Thanks Paul, but that link is for 21h2, not 22h2. I’m having a problem getting an update to 22h2. I do now have InControl installed and used that instead of my manual reg editing, and I have the exact same problem. Also I have installed a new VM that isn’t sysprep’d and still have the problem, so I’m convinced it isn’t my installation method.

This should be very easily reproducible, I can reproduce it 100%. If anyone has time it would be interesting to know if you can also repro.

1. Install win 10 21h2 in a VM. disable network so that no updates can be downloaded.
2. Use InControl to fix the version to 21h2.
3. Turn on network, and windows will find all the 21h2 updates. Install them.
4. Use InControl to “release control”.
5. Settings > Update will now ask for Win 11, but won’t show 22h2.

Reboot at each step if you feel it necessary, but it doesn’t seem to matter.

Thanks for the ref to WuMgr. But it reports 0 updates available, just like the control panel.

I also tried wushowhide.diagcab as found in a related thread here. I was hoping that fixing TRVI to 21H2 maybe caused the 22H2 updates to be hidden. But the tool showed no hidden updates.

I was finally able to update to 22H2 using the link provided by DrBonzo! It’s a tiny little file and runs super fast, so this will be easy to deploy to my 21h2 users. Now I just have to worry about this again for the next feature update …

I cannot seem to get my Win 10 Pro machines to update to 22H2.

I’ve installed a bunch of Win 10 Pro machines and applied the 3 reg keys during installation using sysprep and an unattend.xml file. This was with TRVI set to 21H2. I didn’t do this to necessarily limit to 21H2, but this was how I found I was able to suppress the Windows 11 prompting.

Now, in a VM, if I remove the TRV and TRVI values, leaving just ProductVersion (“Windows 10”), I get the Win 11 prompts back (“this hardware does not meet requirements” — my guess is due to lack of TPM), but I do not get offered 22H2. If I remove the entire WindowsUpdate reg key, it’s the same thing.

Also, again in a VM, if I instead set the TRVI to “22H2”, I still don’t get offered 22H2. It  seems my VM has permanently decided it would just be on 21H2. Can anyone confirm they were able start from 21H2 reg settings, and then somehow able to update to 22H2?

If I’m reading correctly, the instructions here say that if you set PV to “Windows 10” you stay on the Win 10 train with all updates, and don’t get asked for Win 11. So I’m a little bit disturbed that I’m getting the Win 11 prompt, after removing TRV and TRVI. Now, I didn’t start with just PV. I started with PV, TRV and TRVI. Then I removed the other 2 values. And this led to the Win 11 prompting.

Experimenting in a VM is super valuable, I can iterate quickly. But I am going to try it on actual hardware next, to rule out some oddness of the VM environment.

I find it hard to believe that the difference here is that I set it up in sysprep. There aren’t sysprep settings for this — the way I set it up is to add commands that add these values to the registry. So it’s just as if I’d run the reg add commands in a cmd prompt.

Thanks for any insights.