If there is absolutely no way, the registry value would be a better option, as it's a quicker solution, and furthermore can be integrated into the actual BypassESU script making 2012R2 systems fully patchable via WU right after installation/integration (if installed in an offline WIM). I did that yesterday evening, and was able to install the Jan 2025 .NET cumulative right away. I was connected to my local WSUS, but in theory it should also work with the regular WU server.
Yes.. (bypass esu blue + wsus proxy ) => 8.0 and 8.1 "64 bits" semi automatique update ( Bypass esu blue + blocked esu key ) = enable esu on windows update automatique without wsus proxy => For server 2012 / 2012 r2 Read first page @abbodi1406 can you update first page with blocked esu key and specify that unlock esu update visibility on server and allow full automatique update ( bypass wsus proxy ) + this "HKEY_LOCAL_MACHINE\Software\Microsoft\Azure Connected Machine Agent\ArcESU name it Enabled, and give it a value of 1."
UPDATE: After reading a previous post by @abbodi1406, I changed ProductType in HKLM\SYSTEM\CurrentControlSet\Control\ProductOptions from WinNT to ServerNT, and uninstalled an update I installed with the proxy to check (KB3133043). One scan later, it found the update again, meaning that the proxy should no longer be necessary for 6.3.9600 both client and server. The EditionID was left as Professional (sorry if I didn't look carefully, I forgot I changed it back), and the aforementioned key under ArcESU was also added, and after uninstalling KB5050185 for a test, a quick check later it got found again and was able to be reinstalled.
As I said after editing the comment, I forgot I changed it back to Professional. Changing ProductType to ServerNT and adding the blocked ESU key (while having the ESU Suppressor installed) is enough to get ESU updates through the Windows Update Client. If you have particular needs, you can still change the value only when you need to update and then revert it back. I'd say it's better than the proxy, as it's just a string and changing it doesn't leave permanent marks on the system; it won't affect me since I don't use that many programs, but this does not mean other people won't have problems. Plus, the string is reverted back after a reboot, so changing it monthly shouldn't be that big of an issue. Even better with a .reg file; the proxy also needed occasional run, and wouldn't allow you to use a custom WSUS server like in my case.
After further testing, I saw that you need to keep the registry open to find updates for 2012R2 using the ProductType method, as it instantly reverts to WinNT as soon as I close the registry editor; furthermore, it doesn't always work. We need to find a way to make Windows Update think that key's value is ServerNT, whilst keeping the actual value as WinNT; that would be the perfect solution, which wouldn't require anything to be open while you're searching for updates. After this, we can integrate the addition of the ArcESU - Enabled registry value + the ProductType spoof (maybe as a scheduled task) in the actual BypassESU script, making BypassESU configuration as seamless as possible. But for now, on client the proxy is still the best bet.
Sorry, what is a dll hook? Is it like the kerneles.dll that gets added while installing WU ESU Patcher on Windows 7? And can this dll hook be run only when WU searches for updates?
Those keys do not always seem to work by themselves, at least that's my experience in a VM with 2012 R2 Datacenter Edition. Only after adding the registry key mentionned by AlfCraft07 I am able to see ESU Updates on WU 100% of the time.
The 8.1 ServerNT trick, strangely, works on my actual machine but not on VMs clean-installed using 2025-updated ISOs. The physical machine (ASUS laptop running 8.1 UEFI with Core i3-4030U) was formatted in August using the original version of this ISO (the non-updated one). However, I forgot to specify a couple differences about what I did on the laptop and what I did on the VM: - On the laptop, I previously had ServerDatacenter as EditionID and I also ran the proxy once before changing the key, now the proxy has been uninstalled and the EditionID was changed back to Professional; - On the VM, I just changed the ProductType without ever running the proxy or changing EditionID.