Oh boy, of course... that explains why it always installed the updates for version 3.5.1. I forgot - silly me. Thanks for reminding.
@eric cabrol : in the OP (Opening Post), under "WSUS Proxy for Windows 7 to detect ESU updates after 2023-01"
I'm not getting what is going on with you .. I'm guessing you are a little bit confused .. but "run_wsus" is one of the batch files found inside WSUS proxy folder & if you are asking where is WSUS proxy ? .. then as @Bill_Boquet mentioned its link is "in the OP (Opening Post), under "WSUS Proxy for Windows 7 to detect ESU updates after 2023-01""
Has anyone successfully been able to upgrade to 10 on a windows 7 machine that has been getting the bypass updates?
It's only a small annoyance, but why does a New updates are available alert appear in the taskbar after using BypassESU-v12 and after manually installing these February 2023 updates? They're all old updates, and I've already hidden about 60 of them. About half of them are associated with NET Framework.
I read the topic, and still do not understand completely, we orients to October 2023 (eos for emvedded standard 7), or can we expect to install updates until 2024 (POSReady 7)?
Microsoft will be updating the NT 6.x codebase (Vista, 7, 8, and 8.1) until at least 2026, due to the "Premium Assurance" sales that they made to enterprise customers. This means that all of these versions of Windows continue to receive updates from Microsoft, despite the various lies and propaganda that Microsoft peddles to the public. The problem is that Microsoft will stop releasing these updates for their Windows products after the stated EOL date for that product. This is accomplished by placing artificial locks in the update files and in the Windows Update service that prevents the updates from being installed on versions of Windows that are no longer "in support". This is the problem that we play a cat and mouse game with. Jan 2020 to Jan 2023 Microsoft's stated EOL date for consumer Windows 7 clients was Jan 2020. When Feb 2020 rolled around, Microsoft was still producing NT 6.1 updates, but they stopped making them available to Windows 7 clients. These updates were only available for Windows 7 ESU, Windows Embedded Standard 7, Server 2008 R2 ESU, etc. "Windows 7 ESU" is a different logical entity than "Windows 7". Same OS and same core files, but different SKU and therefore different business & support agreements. Starting Feb 2020, the MSU update packages for NT 6.1 included artificial locks that prevented them from being installed on a "Windows 7" client. Enter abbodi's ESU Bypass. By installing Microsoft's ESU preparation updates as well as abbodi's ESU Bypass on a "Windows 7" client, you change your "Windows 7" client into a "Windows 7 ESU" client. Now when you try to install the MSU package, the artificial lock does not trigger, because your computer is now "Windows 7 ESU" and not "Windows 7" anymore. "Windows 7 ESU" is still supported by these updates; "Windows 7" is not. Same OS and same core files, but different SKU. Same updates, but different EOL date and support timeline from Microsoft. Feb 2023 to Oct 2023 Microsoft's stated EOL date for "Windows 7 ESU" was Jan 2023. Now that Feb 2023's Update Tuesday has come, Microsoft is still producing NT 6.1 updates, but they have stopped making them available to "Windows 7 ESU" clients. These updates are now only available for WES7 ESU, Server 2008 R2 ESU, etc. "Windows Embedded Standard 7 ESU" is a different logical entity than "Windows 7 ESU" and "Windows 7". Again, same OS and same core files, but different SKU and therefore different business & support agreements. Starting Feb 2023, the MSU update packages for NT 6.1 now have a new artificial lock that prevents them from being installed on a "Windows 7 ESU" client. For those counting, the SKUs that are blacklisted from accepting NT 6.1 updates now include "Windows 7", "Windows 7 ESU", and "Windows Embedded Standard 7". The SKUs that do not have artificial locks yet include "Windows Embedded Standard 7 ESU" and "Server 2008 R2 ESU". Enter v12 of abbodi's ESU bypass. It tricks our "Windows 7 ESU" clients into bypassing the new artificial lock. Now when you try to install a "WES7 ESU" or "Server 2008 R2 ESU" update MSU package, the artificial lock does not trigger, and the update can be installed successfully. WES7 ESU is the same OS as WES7 and Windows 7 and Windows 7 ESU and Server 2008 R2 and Server 2008 R2 ESU. Same core files, but different SKUs. Same updates, but different EOL dates and support timelines from Microsoft. Nov 2023 to ??? Microsoft's stated EOL date for "WES7 ESU" is Oct 2023. When the Nov 2023 Update Tuesday comes, Microsoft will still be producing NT 6.1 updates, but they will stop making them available to "WES7 ESU" clients. These updates will become only available for Server 2008 R2 ESU. (edit: and still available for POSReady 7, too, but POSReady 7 is not functionally equivalent to the mainline NT 6.1 SKUs, so we don't know (yet) if updates for POSReady 7 will work as intended on Windows 7). "Server 2008 R2 ESU" is a different logical entity than "WES7" and "WES7 ESU" and "Windows 7 ESU" and "Windows 7". Again, same OS and same core files, but different SKU and therefore different business & support agreements. Now you can probably see where this is going... Starting Nov 2023, the MSU update packages for NT 6.1 will have yet another new artifical lock that will prevent them from being installed on a "WES7 ESU" client (in addition to all the other SKUs that have already been locked out). When this day comes, Microsoft will only be releasing NT 6.1 updates for the "Server 2008 R2 ESU" SKU. All other SKUs will be blacklisted by the artificial locks. abbodi will most likely update his ESU Bypass tool again and provide us with new instructions for tricking Windows Update into bypassing the new locks and allowing us to install the Server 2008 R2 ESU update MSU packages on our Windows 7 clients. Same OS and same core files, but different SKUs. Same updates, but different EOL dates and support timelines from Microsoft. This is the cat and mouse game that Microsoft plays. It only exists because of negotiated support contracts with customers and the desire to rake in billions. It has nothing to do with the technical resources required to update NT 6.x, which are a drop in the bucket anyways. You can verify everything I've said by going to the Microsoft update catalog, picking any monthly rollup KB from the last 8 years, and inspecting the version for "Windows 7" vs "WES7" vs "Server 2008 R2". April 2016 rollup? The MSUs for 7, WES7, and Server are identical. November 2017 rollup? The MSUs for 7, WES7, and Server are identical. December 2019 rollup? The MSUs for 7, WES7, and Server are identical. They all are. Edit: To clarify, installing updates for a different NT 6.1 SKU does not magically change your Windows 7 into a different edition. Installing WES7 update MSUs on a Windows 7 client does not change it into WES7. Installing Server 2008 R2 update MSUs on a Windows 7 client does not change it into Server 2008 R2. Like Neo in the Matrix, there is no spoon. There is no such thing as WES7 or Server 2008 R2 or even Windows 7. They are not operating systems. There is only the NT 6.1 operating system, and things like "WES7" and "Server 2008 R2" and "Windows 7" are merely different labels for NT 6.1 that have different OOBEs, support packages, and support timelines from Microsoft attached to them. It's a lot like cereal brands, strange as that may sound. There might be 20 "different" plain cornflake brands in your grocery store, but they probably all contain the same damn cornflakes made in the same factory. So grab your imaginary spoon and enjoy a mixed bowl of those 20 "different" cornflakes brands, because they all probably taste the same. (This is a bit of an oversimplification, but you get the point.)
\src\index.php + Run_wsus.cmd = Emulate: Windows Embedded Standard 7 \src\both\index.php + Run_wsus-Both.cmd = Emulate: Windows 7 and Windows Embedded Standard 7 you only need to change and use the first
Glad to report it works with real WSUS server. However, I found that you must approve the Embedded updates first, as they don't show up as "needed" by W7 clients while update status is "not approved".
I have a question, why can't I use the batch processing of the offline integrated ESU, I have tried both methods, but after a window pops up, there is nothing there, and I don't see the screen to choose