On decommissioning of update servers for 2000, XP, (and Vista?) as of July 2019

[AstroSkipper]

Quote

How do I do that? Maybe you write me a private message.

@maile3241 The cmd file is a batch file. You can add in first line a path command for example "path c:\WINDOWS\system32\wbem\" or "set path c:\WINDOWS\system32\wbem\", If you add more than one path you have to separate by semicolon e. g. "path c:\WINDOWS\system32\wbem\; c:\WINDOWS\system32\dllcache\". In Windows XP you can set global paths. Look here: https://cs.calvin.edu/courses/cs/112/resources/installingEclipse/path/

Edited January 19, 2022 by AstroSkipper
addition

[maile3241]

4 minutes ago, AstroSkipper said:

The cmd file is a batch file. You can add in first line a path command for example "path c:\WINDOWS\system32\wbem\" or "set path c:\WINDOWS\system32\wbem\", If you add more than one path you have to separate by semicolon e. g. "path c:\WINDOWS\system32\wbem\; c:\WINDOWS\system32\dllcache\". In Windows XP you can set global paths. Look here: https://cs.calvin.edu/courses/cs/112/resources/installingEclipse/path/

Thanks very much! I will test it tomorrow.

[Dave-H]

3 hours ago, xpandvistafan said:

Ok, I understand. It is strange that the past 2 methods for getting Windows Update working again, the WSUS Server method and this method, don't work for you but work for everyone else.

Yes, that is puzzling.
Are people who have this working using the http:// URL or the https:// URL?
Looking at the screen grabs, it appears to be generally the http version.
I realised I actually have only https links set to use ProxHTTPSProxy, not http links, so I changed that to use it for all URLs, but it didn't make any difference, I'm still getting the supposed clock setting error.

[Mathwiz]

12 hours ago, Dave-H said:

I certainly didn't do anything knowingly to generate my own certificate.

When you start ProxHTTPSProxy, if there's no CA.crt found when you start it, it will create one, valid from that date until 10 years hence. It then uses CA.crt to sign all the certificates it creates for the https: sites you visit, so you must install CA.crt as a trusted root certificate for ProxHTTPSProxy to work at all.

I'm guessing your ProxHTTPSProxy install didn't come with a CA.crt, so it created the one you installed. @i430VX's install comes with the one that's valid from 10/1/2015 until 9/30/2025 (presumably it was created on the former date). The .exe I ran appears both to place that CA.crt in your ProxHTTPSProxy directory and to install it as a trusted root, so I believe ProxHTTPSProxy will create new site certificates and continue working. At worst, you may need to clear the ...\Certs subfolder to get rid of the old, no-longer-valid site certificates so that it will create new ones.

To be safe, you could back up both your current CA.crt and your entire ...\Certs folder, so you could put them back in place if anything goes wrong with the new CA.crt.

11 hours ago, Dave-H said:

IIRC I must have updated the certificate using the details in cacert Update.txt.
The one you have appears to be the default CA.crt supplied with the program.
I don't see how installing an older certificate would make Windows Update suddenly work....

I don't really understand why it would matter either. But, at least in my case, it did fix the date/time issue with Windows Update.

The message seems to indicate that your system date is earlier than the start date of a certificate, which is impossible unless either your system date is incorrect, or there's a bug in WU's certificate validation routine. Clearly it must be the latter. Perhaps there's a bug in dealing with dates after some point between 2025 and 2031. Not sure what we'll do if we still need Windows Update after 2025....

10 hours ago, AstroSkipper said:

Hello to all. First thanks all for your help!  I've examined what was going wrong in my system. I found out that the patch in Restore_WU_XP_2003.7z didn't work in my system due to system file protection. The file wuaueng.dll was replaced by sfc.

I was going to post on this myself, but you beat me to it! The .cmd file deletes wuaueng.dll from ...\DLLCache, then renames the one in ...\System32, then it copies the patched file into System32. But then SFC sees the new file, tries to compare it to the one in ...\DLLCache, and, not finding it there, it copies the original version from \i386! Then when you try to run Windows Update, it sees you have the old version and downloads the original, unpatched version that you started with. Round and round we go....

I didn't disable SFC; instead, I copied the patched file first to ...\DLLCache, then to ...\System32. That way SFC found the file in ...\DLLCache, discovered it matched, and left it in place.

3 hours ago, maile3241 said:

I will then make an extra video to activate Microsoft Update.

That brings up a curious problem I ran into. When I started on this journey, I could click the link and pull up the Microsoft Update page without issue. (Of course neither WU nor MU worked at the time, but I could at least bring up the page.) But now, I only get "Internet Explorer cannot display the web page."

The error comes up immediately. The IE address bar shows https://update.microsoft.com/microsoftupdate and I can see a 302 (Moved Temporarily) response in the ProxHTTPSProxy window, so the link is redirecting (somewhere) but immediately failing.

Edited January 20, 2022 by Mathwiz

[xpandvistafan]

21 minutes ago, Mathwiz said:

When you start ProxHTTPSProxy, if there's no CA.crt found when you start it, it will create one, valid from that date until 10 years hence. It then uses CA.crt to sign all the certificates it creates for the https: sites you visit, so you must install CA.crt as a trusted root certificate for ProxHTTPSProxy to work at all.

I'm guessing your ProxHTTPSProxy install didn't come with a CA.crt, so it created the one you installed. @i430VX's install comes with the one that's valid from 10/1/2015 until 9/30/2025 (presumably it was created on the former date). The .exe I ran appears both to place that CA.crt in your ProxHTTPSProxy directory and to install it as a trusted root, so I believe ProxHTTPSProxy will create new site certificates and continue working. At worst, you may need to clear the ...\Certs subfolder to get rid of the old, no-longer-valid site certificates so that it will create new ones.

To be safe, you could back up both your current CA.crt and your entire ...\Certs folder, so you could put them back in place if anything goes wrong with the new CA.crt.

I don't really understand why it would matter either. But, at least in my case, it did fix the date/time issue with Windows Update.

The message seems to indicate that your system date is earlier than the start date of a certificate, which is impossible unless either your system date is incorrect, or there's a bug in WU's certificate validation routine. Clearly it must be the latter. Perhaps there's a bug in dealing with dates after some point between 2025 and 2031. Not sure what we'll do if we still need Windows Update after 2025....

I was going to post on this myself, but you beat me to it! The .cmd file deletes wuaueng.dll from ...\DLLCache, then renames the one in ...\System32, then it copies the patched file into System32. But then SFC sees the new file, tries to compare it to the one in ...\DLLCache, and, not finding it there, it copies the original version from \i386! Then when you try to run Windows Update, it sees you have the old version and downloads the original, unpatched version that you started with. Round and round we go....

I didn't disable SFC; instead, I copied the patched file first to ...\DLLCache, then to ...\System32. That way SFC found the file in ...\DLLCache, discovered it matched, and left it in place.

That brings up a curious problem I ran into. When I started on this journey, I could click the link and pull up the Microsoft Update page without issue. (Of course neither WU nor MU worked at the time, but I could at least bring up the page.) But now, I only get "Internet Explorer cannot display the web page."

The error comes up immediately. The IE address bar shows https://update.microsoft.com/microsoftupdate and I can see a 302 (Moved Temporarily) response in the ProxHTTPSProxy window, so the link is redirecting (somewhere) but immediately failing.

Try http://windowsupdate.microsoft.com/microsoftupdate I had that issue because it was using HTTPS and had a redirect error. 

[AstroSkipper]

1 hour ago, Mathwiz said:

 

I didn't disable SFC; instead, I copied the patched file first to ...\DLLCache, then to ...\System32. That way SFC found the file in ...\DLLCache, discovered it matched, and left it in place.

I know but in my system it didn't work. Either I have to disable sfc or I have to cut off sfc fetching an old wuaueng.dll file from \i386. I have an imaging system for backing up partitions so I am glad to disable sfc. No old system files anymore without my permission!

Edited January 20, 2022 by AstroSkipper
addition

[AstroSkipper]

1 hour ago, Mathwiz said:

That brings up a curious problem I ran into. When I started on this journey, I could click the link and pull up the Microsoft Update page without issue. (Of course neither WU nor MU worked at the time, but I could at least bring up the page.) But now, I only get "Internet Explorer cannot display the web page."

The error comes up immediately. The IE address bar shows https://update.microsoft.com/microsoftupdate and I can see a 302 (Moved Temporarily) response in the ProxHTTPSProxy window, so the link is redirecting (somewhere) but immediately failing.

I agree to @xpandvistafan. You have to avoid https-links to open Microsoft Update. If you want to access MU directly try http://fe2.update.microsoft.com/microsoftupdate/v6/default.aspx?ln=de  (I am German), for you http://fe2.update.microsoft.com/microsoftupdate/v6/default.aspx?ln=en. And you have to check config.ini of ProxHTTPSProxy. Under section [SSL No-Verify] I added fe2.update.microsoft.com and deleted update.microsoft.com under sections [SSL Pass-Thru] and [BYPASS URL]. This is working for me although I use predominantly HTTPSProxy. If wanted I can provide my config file of ProxHTTPSProxy.

Edited January 20, 2022 by AstroSkipper

[Mathwiz]

2 hours ago, xpandvistafan said:

Try http://windowsupdate.microsoft.com/microsoftupdate I had that issue because it was using HTTPS and had a redirect error. 

Strangely, that redirects to http://fe2.update.microsoft.com/microsoftupdate. That trailing period looks wrong and the link just gives a server error page. (That may have been the original problem, but I couldn't see the error because IE's https: handling hid it from me.) But if you remove that trailing period (i.e., http://fe2.update.microsoft.com/microsoftupdate), it works! (BTW, MU takes way longer to scan than WU, but that makes sense because I have Office 2010 and I think one of its cumulative updates triggers the old "scans forever" bug. Oh, well; at least I can get to the scan now!)

I'd still love to know why the MU link on the WU page worked a few days ago but doesn't now, but since removing the trailing period works, I'll just bookmark the link that way and not worry about it.

1 hour ago, AstroSkipper said:

I agree to @xpandvistafan. You have to avoid https-links to open Microsoft Update. If you want to access MU directly try http://fe2.update.microsoft.com/microsoftupdate/v6/default.aspx?ln=de  (I am German), for you http://fe2.update.microsoft.com/microsoftupdate/v6/default.aspx?ln=en. And you have to check config.ini of ProxHTTPSProxy. Under section [SSL No-Verify] I added fe2.update.microsoft.com and deleted update.microsoft.com under sections [SSL Pass-Thru] and [BYPASS URL]. This is working for me although I use predominantly HTTPSProxy. If wanted I can provide my config file of ProxHTTPSProxy.

Yes I copied your config.ini entries from your screen shot earlier. They work fine but didn't solve the MU problem, since the redirect on M$'s server is apparently wrong (has that extra period as shown above).

Edited January 20, 2022 by Mathwiz

[AstroSkipper]

On 1/20/2022 at 5:18 AM, Mathwiz said:

On 1/20/2022 at 3:03 AM, xpandvistafan said:

Try http://windowsupdate.microsoft.com/microsoftupdate I had that issue because it was using HTTPS and had a redirect error. 

Strangely, that redirects to http://fe2.update.microsoft.com/microsoftupdate. That trailing period looks wrong and the link just gives a server error page. (That may have been the original problem, but I couldn't see the error because IE's https: handling hid it from me.) But if you remove that trailing period (i.e., http://fe2.update.microsoft.com/microsoftupdate), it works! (BTW, MU takes way longer to scan than WU, but that makes sense because I have Office 2010 and I think one of its cumulative updates triggers the old "scans forever" bug. Oh, well; at least I can get to the scan now!)

I'd still love to know why the MU link on the WU page worked a few days ago but doesn't now, but since removing the trailing period works, I'll just bookmark the link that way and not worry about it.

On 1/20/2022 at 4:03 AM, AstroSkipper said:

I agree to @xpandvistafan. You have to avoid https-links to open Microsoft Update. If you want to access MU directly try http://fe2.update.microsoft.com/microsoftupdate/v6/default.aspx?ln=de  (I am German), for you http://fe2.update.microsoft.com/microsoftupdate/v6/default.aspx?ln=en. And you have to check config.ini of ProxHTTPSProxy. Under section [SSL No-Verify] I added fe2.update.microsoft.com and deleted update.microsoft.com under sections [SSL Pass-Thru] and [BYPASS URL]. This is working for me although I use predominantly HTTPSProxy. If wanted I can provide my config file of ProxHTTPSProxy.

Yes I copied your config.ini entries from your screen shot earlier. They work fine but didn't solve the MU problem, since the redirect on M$'s server is apparently wrong (has that extra period as shown above).

If you want to have a working Microsoft Update shortcut in your start menu you have to add http://update.microsoft.com in trusted zone of IE (security level must be high) and to modify config file of  ProxHTTPSProxy in the way I described above. Without these modifications I had problems to open MU site randomly using Microsoft Update shortcut in my start menu. For me it is now working flawlessly. Look at my screenshot!

https://imgur.com/2Nr0xEi

 

Edited January 31, 2022 by AstroSkipper
correction

[Dave-H]

10 hours ago, Mathwiz said:

When you start ProxHTTPSProxy, if there's no CA.crt found when you start it, it will create one, valid from that date until 10 years hence. It then uses CA.crt to sign all the certificates it creates for the https: sites you visit, so you must install CA.crt as a trusted root certificate for ProxHTTPSProxy to work at all.

I'm guessing your ProxHTTPSProxy install didn't come with a CA.crt, so it created the one you installed. @i430VX's install comes with the one that's valid from 10/1/2015 until 9/30/2025 (presumably it was created on the former date). The .exe I ran appears both to place that CA.crt in your ProxHTTPSProxy directory and to install it as a trusted root, so I believe ProxHTTPSProxy will create new site certificates and continue working. At worst, you may need to clear the ...\Certs subfolder to get rid of the old, no-longer-valid site certificates so that it will create new ones.

To be safe, you could back up both your current CA.crt and your entire ...\Certs folder, so you could put them back in place if anything goes wrong with the new CA.crt.

I don't really understand why it would matter either. But, at least in my case, it did fix the date/time issue with Windows Update.

The message seems to indicate that your system date is earlier than the start date of a certificate, which is impossible unless either your system date is incorrect, or there's a bug in WU's certificate validation routine. Clearly it must be the latter. Perhaps there's a bug in dealing with dates after some point between 2025 and 2031. Not sure what we'll do if we still need Windows Update after 2025....

My install of ProxHTTPSProxy came from @heinoganda's original package.
I've checked it, and it does include a CA.crt file, which is valid from 01/10/15 to 30/09/25.
I must have subsequently updated it.
I can try going back to the original version and see what happens.

 

[Dave-H]

I went back to the version of CA.crt which came with ProxHTTPSProxy, and MS Update then didn't work at all, "unable to display page" (Error number: 0x80072F7D).
After restoring the newer version it loads and scans again, but then I'm getting the supposed clock setting error again.

[AstroSkipper]

9 hours ago, Dave-H said:

I went back to the version of CA.crt which came with ProxHTTPSProxy, and MS Update then didn't work at all, "unable to display page" (Error number: 0x80072F7D).
After restoring the newer version it loads and scans again, but then I'm getting the supposed clock setting error again.

Hi @dave-h, I had a lot of error codes getting from MU site. Now it is working perfectly. Did you use WSUS server in combination with WUMT in the past? If so maybe your DataStore.edb is corrupt. This was one of my problems. Stop Automatic Update Service, make a backup of SoftwareDistribution folder, then delete DataStore.edb. Start Automatic Update Service again and try to access MU via ProxHTTPSProxy. MU generates a new DataStore.edb file. With your backup of DataStore.edb you can go back to old history whenever you want. I have two DataStore.edb files, one for WSUS server and one for MU. One for all doesn't work in my system. If that doesn't help try HTTPSProxy which came from Thomas S.. I use it and everything works flawlessly. Editing config file is necessary. My entries I provided some posts above. In my system I have both configured ProxHTTPSProxy and HTTPSProxy and they are working without any problems if config file has the correct entries.

Edited January 21, 2022 by AstroSkipper
correction

[Dave-H]

A good thought thanks, but I tried generating an new empty DataStore.edb and just got the same error message I'm afraid.
Some research indicated that the error I'm getting is because my system time does not match the time on the server, and I wondered if this was because I'm not in the States, but I then saw that others in Europe have had this working, so it can't be that!

[D.Draker]

3 hours ago, Dave-H said:

I wondered if this was because I'm not in the States

On the contrary , you live in one of the greatest countries in the world and IPs from Great Britain are in favour ! God save the Queen.

[AstroSkipper]

23 minutes ago, Dave-H said:

A good thought thanks, but I tried generating an new empty DataStore.edb and just got the same error message I'm afraid.
Some research indicated that the error I'm getting is because my system time does not match the time on the server, and I wondered if this was because I'm not in the States, but I then saw that others in Europe have had this working, so it can't be that!

Are you running ESET/NOD32 anti-virus? If so and you have SSL protocol filtering enabled you need to add an exception for MU related sites or you have to disable this feature. Same in AVAST called HTTPS Scanning. My security program is AVAST Premier and I have disabled HTTPS scanning. Another method is letting MU generate a completely new SoftwareDistribution folder. Maybe there are faulty downloaded updates in this folder. Here some other methods to fix error code 0x80072F8F:

https://answers.microsoft.com/en-us/windows/forum/all/error-code-0x80072f8f/d5006dbe-5946-4d68-8f08-8620eeb65efd   here very interesting method 3 and 4. Hope you can fix it. Greetings from Germany