I already shared the autounattend for you to check; everything works well without errors, it does its job. Its purpose is to avoid unnecessary things and optimize Windows. If you have anything to add, you're welcome to it; if it improves, that's excellent.
Why not keep it in MAS, just display an error if someone tried to activate Windows 11? Also ESU via TSforge works with the first ESU only update
After running the script to ESU updates for Win 10, I do not have the "Your PC is enrolled" message in windows update. Is this message only for those who uses one of the Microsoft "free" updates for one year, or should the message be there? Also my PC seems to be now enrolled into the windows insider program - is this normal after running the script? I didn't enable this myself and my PC is not logged into a Microsoft account.
The message is only showing for Store-based ESU, aka the one-year Consumer one. TSForge applies key-based ESU, which is three years and does not show any message. No, this is not normal and not caused by TSForge. Maybe you used the OfflineInsiderEnroll script in the past? Just leave the program if you don't want to be part of it.
Many thanks for the quick reply and confirmation. I'm not logged in with any Microsoft account - is there a way to leave the program or tell the PC it isn't in it without logging in? EDIT: never mind, I had telemetry disabled in GPO and it was giving an ambiguous message under Windows Insider Program in settings. Re-enabling telemetry showed that the PC wasn't enrolled. Thanks for the confirmation that the script wouldn't have been involved though.
MAS 3.9 - Minor Update TSforge Fixed an issue where IoT ESU licenses were not working (a bug from Microsoft) for the IoTEnterprise edition. The script will use the Client ESU license instead. Change Office Edition Removed the deprecated Semi Annual Preview channel from the change update channel option. Online KMS The script will no longer automatically change IoTEnterprise editions to Enterprise for KMS activation.
Technically, only two (3 and 6) are needed with 10, and the same was the case with 7. However, I'm a bit concerned that they might change something and add some year-wise verification. So we added all 3 years by default. Why not do the same with 4, 5, and 6? Because users won't get the automatic updates through WU, and they will need to manually install updates (no guarantee if that would even be possible). So even if there is a 1% possibility that they might add year-wise verification, it's fine because that's an advanced case scenario anyway, where manual intervention is required, those users can just rerun the script. Only adding 6 years reduces cluttering in the output.
I only know of amd64_microsoft-windows-s..edsecurityupdatesai_31bf3856ad364e35_10.0.19041.6575_none_e64f79a9a6307a2f.manifest and it's not at all obvious from it which years will be ever needed. Code: <?xml version="1.0" encoding="utf-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v3" manifestVersion="1.0" copyright="Copyright (c) Microsoft Corporation. All Rights Reserved."> <assemblyIdentity name="Microsoft-Windows-Security-SPP-Component-ExtendedSecurityUpdatesAI" version="10.0.19041.6575" processorArchitecture="amd64" language="neutral" buildType="release" publicKeyToken="31bf3856ad364e35" versionScope="nonSxS" /> <ExtendedSecurityUpdatesAI ActiveLicenses=";" ExtendedSecurityUpdates="0x13;" SKUs="0x7D;0x7E;0xBF;0xAB;" /> <ExtendedSecurityUpdatesAI ActiveLicenses="Client-ESU-Year1;" ExtendedSecurityUpdates="0x03;" SKUs="0x79;0x7A;0x04;0x1B;0x30;0x8B;0xA4;0xA5;0x31;0x8A;0xA1;0xA2;0xAF;0x77;0x62;0x63;0x64;0x65;0xBC;" arguments="/B f520e45e-7413-4a34-a497-d2765967d094:060000001-060000001; /B f520e45e-7413-4a34-a497-d2765967d094:001900009-001900010; " /> <ExtendedSecurityUpdatesAI ActiveLicenses="Client-ESU-Year2;" ExtendedSecurityUpdates="0x03;" SKUs="0x79;0x7A;0x04;0x1B;0x30;0x8B;0xA4;0xA5;0x31;0x8A;0xA1;0xA2;0xAF;0x77;0x62;0x63;0x64;0x65;0xBC;" arguments="/B 1043add5-23b1-4afb-9a0f-64343c8f3f8d:060000001-060000001; " /> <ExtendedSecurityUpdatesAI ActiveLicenses="Client-ESU-Year3;" ExtendedSecurityUpdates="0x03;" SKUs="0x79;0x7A;0x04;0x1B;0x30;0x8B;0xA4;0xA5;0x31;0x8A;0xA1;0xA2;0xAF;0x77;0x62;0x63;0x64;0x65;0xBC;" arguments="/B 83d49986-add3-41d7-ba33-87c7bfb5c0fb:060000001-060000001; " /> <ExtendedSecurityUpdatesAI ActiveLicenses="Client-ESU-Year4;" ExtendedSecurityUpdates="0x03;" SKUs="0x79;0x7A;0x04;0x1B;0x30;0x8B;0xA4;0xA5;0x31;0x8A;0xA1;0xA2;0xAF;0x77;0x62;0x63;0x64;0x65;0xBC;" /> <ExtendedSecurityUpdatesAI ActiveLicenses="Client-ESU-Year5;" ExtendedSecurityUpdates="0x03;" SKUs="0x79;0x7A;0x04;0x1B;0x30;0x8B;0xA4;0xA5;0x31;0x8A;0xA1;0xA2;0xAF;0x77;0x62;0x63;0x64;0x65;0xBC;" /> <ExtendedSecurityUpdatesAI ActiveLicenses="Client-ESU-Year6;" ExtendedSecurityUpdates="0x03;" SKUs="0x79;0x7A;0x04;0x1B;0x30;0x8B;0xA4;0xA5;0x31;0x8A;0xA1;0xA2;0xAF;0x77;0x62;0x63;0x64;0x65;0xBC;" /> <ExtendedSecurityUpdatesAI ActiveLicenses="Client-IOT-ESU-Year1;" ExtendedSecurityUpdates="0x03;" SKUs="0xBC;" arguments="/B b8527af1-5389-447c-9a88-2d1691ea33d3:060000001-060000001; " /> <ExtendedSecurityUpdatesAI ActiveLicenses="Client-IOT-ESU-Year2;" ExtendedSecurityUpdates="0x03;" SKUs="0xBC;" arguments="/B 7b76ee02-0a75-4f08-85d5-bd0feadad0c0:060000001-060000001; " /> <ExtendedSecurityUpdatesAI ActiveLicenses="Client-IOT-ESU-Year3;" ExtendedSecurityUpdates="0x03;" SKUs="0xBC;" arguments="/B 4dac5a0c-5709-4595-a32c-14a56a4a6b31:040000001-040000001; " /> <ExtendedSecurityUpdatesAI ActiveLicenses="Client-IOT-ESU-Year4;" ExtendedSecurityUpdates="0x03;" SKUs="0xBC;" /> <ExtendedSecurityUpdatesAI ActiveLicenses="Client-IOT-ESU-Year5;" ExtendedSecurityUpdates="0x03;" SKUs="0xBC;" /> <ExtendedSecurityUpdatesAI ActiveLicenses="Client-IOT-ESU-Year6;" ExtendedSecurityUpdates="0x03;" SKUs="0xBC;" /> <ExtendedSecurityUpdatesAI ActiveLicenses=";" ExtendedSecurityUpdates="0x41;" SKUs="0x79;0x7A;0x04;0x1B;0x30;0x8B;0xA4;0xA5;0x31;0x8A;0xA1;0xA2;0xAF;0xBC;" /> <ExtendedSecurityUpdatesAI ActiveLicenses="Microsoft.Windows10ConsumerExtendedSecurityUpdates_8wekyb3d8bbwe;" ExtendedSecurityUpdates="0x51;" SKUs="0x30;0x31;0x62;0x63;0x64;0x65;0xA1;0xA2;0xA4;0xA5;" /> <ExtendedSecurityUpdatesAI ActiveLicenses="MicrosoftCorporationII.Windows10ConsumerExtendedSe_8wekyb3d8bbwe;" ExtendedSecurityUpdates="0x51;" SKUs="0x30;0x31;0x62;0x63;0x64;0x65;0xA1;0xA2;0xA4;0xA5;" /> <ExtendedSecurityUpdatesAI ActiveLicenses="MicrosoftCorporationII.829702A5274C_8wekyb3d8bbwe;" ExtendedSecurityUpdates="0x51;" SKUs="0x30;0x31;0x62;0x63;0x64;0x65;0xA1;0xA2;0xA4;0xA5;" /> </assembly>
From a clean install with 19045.3803.231204-0204.22h2_release_svc_refresh_CLIENTBUSINESS_VOL_x64FRE_en-gb.esd converted to ISO, what are all the updates needed in specific order till ESU can be enabled with MAZ and what updates after that. Thanx in advance.
Answered here (before you reposted it here): https://forums.mydigitallife.net/threads/windows-10-esd-repository.59082/page-185#post-1897995
Someone recently said on here that there are now required manually configed registry entries to keep TSforge ESUs running on Win10. Is this true and if so what are those registry entries ?
The registry entries are for detecting the ESU updates, it's not directly related or part of TSforge ESUs activation itself https://forums.mydigitallife.net/posts/1896375/ if you used MAS 3.8 or later, or ran ClipESU.exe yourself, the registry values are populated (both require 19045.6159 at least)
I used the original MAS TSforge from several months ago, can I just rerun MAS (from the URL) and get those registry entries now ?