Jump to content

ItCoder

Member
  • Posts

    26
  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    Italy

Everything posted by ItCoder

  1. You can try clicking Start now and continue in the following page, if it works it will enable access to MU (without losing access to WU). If it doesn't, nothing will happen. But it might help because it will download authcabs (they are related to checking for updates at least in MU).
  2. Check if your patched wuaueng.dll is 1,xx MB or 2,xx MB. If it's 1,xx MB it's the 32bit version which won't work on 64bit systems. You can try putting it in SysWow64, but I don't know if it works.
  3. Can you access https://fe2.update.microsoft.com/windowsupdate/v6/default.aspx?g_sconsumersite=1 with ProxHTTPSProxy?
  4. Check if wuaueng.dll has a digital signature into properties. If it hasn't, it's already the patched version. If it has, it must be dated 2012. Check also if you have the same copy in C:\Windows\System32\dllcache. If not, install windowsupdateagent (but version 7.6.7600.256, 320 is not for XP) with /WUForce option. After that, patch wuaueng.dll both in System32 and dllcache.
  5. This is a system error. Try running sfc /scannow and reinstalling Windows Update Agent. Tell me also if ProxHTTPSProxy shows a call to fe2.update.microsoft.com/v6/ClientWebService/client.asmx
  6. You should click on Advanced on the last screen and put the IP address only into "Secure", leaving the other ones blank. The Proxy works only with HTTPS.
  7. You should replace wuaueng.dll in system32 and in system32\dllcache, otherwise it gets restored. But the website should open anyway, only the scan should fail. Where does it exactly stop loading?
  8. Check if you have Windows Update Agent 7.6.7600.256, and the patched wuaueng.dll (it's not signed by Microsoft). Check also if you have the WuRedirOverride keys. Once everything is done and you start a scan, you should have a v6-win7sp1-wuredir.cab in one of those folders
  9. Check into C:\winnt\softwaredistribution\wuredir if there is one file that contains fe2.update.microsoft.com
  10. The installer is in English, but it installs in any language. You can try to see if it works, but then you have to reconfigure the system to work with your proxy (reinstall the Agent, add registry keys, replace wuaueng.dll with patched version, set your proxy in IE). That happens because redirection, in my method, is done on the server to allow Automatic Updates to work. Alternatively, you can try unregistering muweb.dll, uninstall IE6 (and IE5.5 if it gets restored), reinstall it and register muweb.dll again.
  11. I've simulated this and Microsoft Update opened fine. Try my installer (https://1drv.ms/u/s!AsVjtW11rJfA3FQANrgg_QXRMgfx?e=7q2PhN).
  12. If Windows Update works and muweb.dll is registered, it has to work (tested). I once ran into an issue on Vista, regsvr32 didn't see muweb.dll anymore (and IE did the same). Try to place muweb.dll in a different location and register it again (mucltui.dll is not needed, as it's automatically installed at first run).
  13. I created a GUI installer for my method using Legacy Update's one as a base. You can download it and view sources at the same link (https://1drv.ms/u/s!AsVjtW11rJfA3FQANrgg_QXRMgfx?e=7q2PhN). I've tested it on any version from 2000 to 7 and it works. Tell me if something doesn't.
  14. 7.4 is the same as 7.6 with AllowAnySSL key. It's only that I didn't want to use a patched version. The wuredir key forces Windows Update to download the correct wuredir.cab (XP's one has the old www.update.microsoft.com which doesn't work) but this method breaks Automatic Updates and doesn't work in Vista (error related to wuident.cab SHA-2-only signature). That's why I prefer setting the correct URLs in the proxy
  15. Check if you have the correct agent version (version of wuweb.dll in system32 must be 7.x.7600.xxx). Check also if you have HTTP/1.1 over proxy and TLS1.0 enabled. If that's all ok, check the latest lines of windowsupdate.log. You can try to load the https version of Windows Update and see in ProxHTTPSProxy if wuredir.cab, wuident.cab and wsus3setup.cab (XP SP3 only) get downloaded to know where the error happens.
  16. You have to add ?g_sconsumersite=1 after aspx to open the website. But scanning won't work unless you apply redirects (patching wuaueng and registry or using another proxy). If you run my installer (any Windows) or the one in the 1st post (XP only) you'll have everything working
  17. In this post I'll explain how my method to restore Windows Update functionality works. First of all, I'll do a recap on what Windows Update does by default: When you start a new detection, it will: 1) Download wuredir.cab from a hardcoded URL and extract wuredir.xml (which contains URLs for wuident.cab, client.asmx, updateregulation.asmx and stat2fe) 2) Download wuident.cab from wuredir URL and extract wuident.txt 3) Look into wuident.txt to build an URL for selfupdate (for every Windows build there is a part of the URL that gets built togheter, the /SKIP means "do not selfupdate") 4) If selfupdate is to be done, download wsus3setup.cab and extract wsus3setup.inf (if 2000, XP or Server 2003) or *.cab files (Vista, 7 and Server 2008) 5) Check in wsus3setup.inf if every file version is correct and download and replace it in case (or check if *.cab files are installed) 6) Scan for updates using client.asmx and updateregulation.asmx URLs Using the website this is a little different: wuident.cab URL is hardcoded and step 2-5 gets done before getting to the homepage. The problem is that URLs in wuredir.xml for client.asmx and updateregulation.asmx are now non-functional and also https connections (client.asmx and wuident.cab) use a TLS1.2 certificate. To restore functionality my proxy server: 1) Handles any HTTPS request with ProxHTTPSProxy v1.3a to ship a TLS1.0 certificate (supported on these OS). 2) Redirects any request made to fe2.update.microsoft.com and www.update.microsoft.com to Requestly (another proxy software) 3) Redirects www.update.microsoft.com/v6/ClientWebService/client.asmx (in wuredir.xml, not working) to fe2.update.microsoft.com/v6/ClientWebService/client.asmx (working) 4) Redirects www.update.microsoft.com/v6/UpdateRegulation/updateregulation.asmx (in wuredir.xml, not working) to fe2.update.microsoft.com/v6/UpdateRegulation/updateregulation.asmx (working) This make Windows Update work well on every agent version (v3) except for the latest (7.6.7600.256) which blocks any non-Microsoft https connection. This is bypassed avoiding selfupdate: 5) Redirects any requests to /wuident.cab to a web.archive.org URL that contains a wuident.cab from 2006 (designed to work with agent 1 and 2) and add headers (required by Windows Update) content-length and last-modified (web.archive.org doesn't provide these). This wuident.cab doesn't contain any URL for agent v3 so selfupdate gets skipped (sometimes with 0x000000 code) Now what the installer does: 1) On 2000, installs MSXML 4.0 (required to set the proxy) 2) On 2000, copies winhttp.dll to winhttp5.dll (in system32) to fix a bug with MSXML 4.0 3) On 2000, copies msxml3.dll to system32 (a bug in wusetup) 4) Installs Windows Update Agent 7.4.7600.226 (with WUForce to rollback on XP) 5) Copies Windows Update and Microsoft Update websites links on the desktop (they require ?g_sconsumersite=1) 6) Registers wuweb.dll (only on NT6.x) and muweb.dll 7) On 2000, updates root certificates 8) Imports ProxHTTPSProxy's CA (with updroots -l) 9) Adds some registry keys (to enable TLS1.0, HTTP1.1 and the proxy on IE) 10) Enables the proxy system-wide (proxycfg or netsh winhttp set proxy) 11) On Vista and 7, restarts the system (required) The fix for Vista and 7 simply runs wusetup /uninstall to rollback the agent.
  18. The installers are simply sfx which execute setup.cmd on extraction. You can look and see what they do. The method simply set the proxy on the client system. The proxy redirects the old URLs to the new ones and ship a very old wuident.cab so that WU won't selfupdate (the latest version blocks any non-Microsoft SSL)
  19. Now my installers works for any OS from 2000 to 7 SP1. Download your from https://1drv.ms/u/s!AsVjtW11rJfA3FQANrgg_QXRMgfx?e=lCF2lV and run it (follow eventual prompts). It restores WU, MU and AU (including website on Vista and 7). Notes: 1)On Windows 2000, you need SP3 or SP4 and IE6 installed before you run this 2)On Windows XP RTM, SP1, SP2 AU doesn't work if MU is enabled (unsolvable) 3)On Windows Vista and 7 already used installations run the fix before installing 4)On Windows 7 SP1 error 0x8007000A is related to wuaueng.dll and cannot be solved. If you have it, install SHA-2 support 5)The installer can be run multiple times if you need
  20. Now installers for NT5.x work! Download from https://1drv.ms/u/s!AsVjtW11rJfA3FQANrgg_QXRMgfx?e=lCF2lV, run it on your system and everything will work! Installers for NT6.x currently do not work. I'm testing them.
  21. I've put online my proxy server: to use it add as "Secure" proxy 34.205.92.217:8079, import the CA.crt and install Windows Update Agent (remember to run "proxycfg -u" or "netsh winhttp import proxy source=ie" to make AU work as well). Here is the link to the installers (run it on a fresh installation and it should work): https://1drv.ms/u/s!AsVjtW11rJfA3FQANrgg_QXRMgfx?e=7q2PhN Warning: installers for windows 2000 and XP partially works. You'll get some errors and have to manually import CA and set IE proxy (while AU proxy is automatically set).
  22. I've tested it two months ago. MSE 4.4 works even with autoupdate (there's no need to run mpam-fe)! I want to avoid 6003 because it isn't "Vista" and if you want to install some updates (such as Ultimate Extras) you must have Windows Update working (with a proxy)
  23. Hi, although it could be a little too late, I have discovered you can add SHA-2 kernel-level support in Windows Vista SP2 installing KB4039648. This won't change the build number to 6003 and works fine (for example to update MSE and Defender).
×
×
  • Create New...