Currently BypassESU-v13.7z is not fixed. To fix it yourself, go to: Or wait until @abbodi1406 fixes it.
Agreed. But Microsoft won't care either way. Windows Server 2008 R2 supposedly "is not for browsing" and therefore we are on our own if we insist on using it (or the now unsupported Windows 7) for that purpose.
Personally I only patch my various Windows installations only once every 4-6 months unless there is an urgent security issue that I consider it necessary to patch as soon as I can. The patching issues I faced with Meltdown / Spectre back in 2018 and the subsequent experiences have convinced me there is no need to keep patching Windows every month, and I shall wait and see, for weeks and even months if necessary, whether there are any issues with these patches (not just for Windows but for other software like video card drivers). The last time I patched my Windows installations was in late August 2024 and I don't plan to patch them again before the end of 2024 at least.
I'm going to play it safe for now and wait until abbodi1406 fixes the issue with BypassESU-v13. If some changes in the coding need to be made in bin\PatchWU.cmd, I prefer he do it before I use it again.
You need dotNetFx4_ESU_Installer_v4 to install this month .NET 4.x updates (which has no issues, but they are non-security updates)
# Updated - BypassESU v13f - Fixed the bug with PatchWU.cmd (thanks to @Matrix360) - LiveOS-Setup.cmd and Wim-Integration.cmd are also updated to ignore installed "WU ESU Patcher" if above file is old, and offer install option
abbodi1406: I already have Windows 7 Professional SP1 64-bit configured as Windows Server 2008 R2 64-bit with BypassESU_v13. I used the gitlab.com and box.com links to download BypassESU_v13f. I noticed the file size for the old v13 and the new v13f are both 366 KB. When I deployed v13f, the window showed it as v13. This is the first window that appeared: When I selected option #3, this is the window that appeared: Am I doing something wrong?
After switching from BypassESU-v13 to BypassESU-v13f and rebooting, I re-installed the KB5046687 SMQR update for Windows Server 2008 R2 64-bit to see what would happen. After installing it and rebooting, I quickly discovered that my Mozilla Firefox ESR 115.17.0 browser was broken again. Uninstalling KB5046687 and rebooting again resolved the issue.
1. well, i guess that after this micro-fix applied everything works just fine but i have no idea why Win7 WU now as WinServer2008R2 can't find z Nov2024 NET3.5.1+4.8 update(s) while it easily popups a Nov2024Rollup that has been skipped to be installed due to z reported uncertain issues. 2. i don't see any clear issues related to NET4-Bypass as a part of BypassESU-v13 as kindly prompted by you. Anyhow z pre-downloaded NET4.8 update Nov2024 has been installed smoothly. Appreciate always!
Moin CaptainSpeleo! Once again for better understanding: The issues that occur after installing KB5046705 & KB5046687 with the vintage browsers (Chrome 109, Edge 109, Firefox ESR 115, Opera 95) have absolutely nothing to do with the abbodi1406 ESU Bypass Tool. It has to do with the fact that Microsoft, knowingly or unknowingly, added a bug to these two updates. Solution approaches in a clear form, which also have nothing to do with the ESU Bypass Tool, can be found here: Link The bypass ESU validation for .NET 4 updates & the patch of WU engine in the BypassESU-v13f version working well for me.
Interesting because only cumulative security update from November kill browser's functions. Net work normally. You should don't let's that concrete to install. And interesting is that, when we try that Esus, VMware put only bsods but on Virtualbox work that modifications on windows 7.