Jump to content

Windows/Microsoft Update Not Working on Windows 2000/XP/2003


Recommended Posts

hello sir, the file C:\WINDOWS\SoftwareDistribution\AuthCabs\muauth.cab->Authorization.xml have been expired !!!


to solve the problem temporarily, please use file version

MicrosoftUpdateCatalogWebControl.dll -> 7.4.7057.248

muweb.dll -> 7.6.7600.256


You do rock and roll, sir!   worship.gif   And welcome to MSFN, BTW! :hello:


MicrosoftUpdateCatalogWebControl.dll -> 7.4.7057.248 is a actually downgrade from 7.4.7057.249 I was using and ...

muweb.dll -> 7.6.7600.256 is actually a downgrade from v. 7.6.7600.257 I was using !!!


That said, way to go, sir! It sure works, all right !!!  cheerleader.gifcheerleader.gifcheerleader.gif

Link to comment
Share on other sites

Same for me as far as muweb.dll is concerned, but the "new" version of MicrosoftUpdateCatalogWebControl.dll is identical to the one I was already using, version 7.4.7057.248.

Same from me @b3270791, welcome to MSFN!

I was so pleased that the fix you gave actually worked that I forgot my manners!

To have this happen does seem to have been a little careless on Microsoft's part!

The trouble is that if they patch it no-one will be able to get the patch unless they have automatic updates switched on, as they obviously can't get it manually through the update site if it's not working!


Link to comment
Share on other sites

Well, you're not going to believe this!

I decided to fight with it in a VM.

Seems that MUWEB.DLL v257 is the culprit.

- Deleted the "Windows\Downloaded Program Files\WUWEBCONTROLCLASS"

- Deleted all occurrences (in the Registry) of

---- "{6E32070A-766D-4EE6-879C-DC1FA91D2FC3}"

---- including "SoftwareDistribution.MicrosoftUpdateWebControl"

---- and "SoftwareDistribution.MicrosoftUpdateWebControl.1"

- Deleted (or renamed) all HDD files beginning with "MUWEB" within "Windows" folder

Rebooted, started Microsoft Update (NOT WINDOWS UPDATE!) in IE, it wanted to install the ActiveX, so I let it, and it failed with the symptoms given.


I then renamed the "Windows\System32" one (v2.57) and copied the v256 one in and VOILA! It worked! Bear in mind the "Windows Update" *used to* Redirect to "Microsoft Update" but now gets a "404" error. How weird is that?


At least so far...


DANG! EDIT! Just seen the above!

BTW, the version of "MicrosoftUpdateCatalogWebControl.dll" on mine is 7.4.7057.249!

I'll try the v248 and see if the "404" error disappears.

**EDIT2** Yep, swapping in the slightly older fixed the "404" as well! "Son of a...." :crazy:

*(edit3)* I should mention that the latest (AFAIK, and will check -later-) are in my Srv2k3 Test Bed and I have MU turned "off" - "New! Get MU now!" from (???) "Windows Update" (NOT MS-Update).


...and from me to @b3270791, also welcome to MSFN! (even though you beat me to it. :thumbup )

Edited by submix8c
Link to comment
Share on other sites

Many thanks to b3270791 for reporting this workaround. This means we have to download Microsoft Update hotfixes for our software and keep them in an HDD because Microsoft may not fix this authorization.xml in the future...

Link to comment
Share on other sites

@submix8c: I guess now is time for an update to RunMe-MakeInstallWindowsUpdateAgent.bat, with provision to force the downgrade of those two files... in case you can kindly find time to dedicate to it.

@all: Moreover, it's clear now we must find out how to fall back to Windows Update, when Microsoft Update gets broken, without using the -- always gray when needed -- "Change Settings" option at the Microsoft Update site, just in case it may prove useful in the future.

Link to comment
Share on other sites

To fall back to Windows Update locally, dencorso:

  • Open a Run box (WindowsKey + R) and type "services.msc".
  • Stop the Automatic Updates service.
  • Delete the file "%WinDir%\SoftwareDistribution\DataStore\DataStore.edb"
  • Restart the Automatic Updates service.
My procedure is the scalpel compared to MrMaguire's hammer. Edited by 5eraph
Link to comment
Share on other sites

hello *


downgrade muweb.dll to r256 and WU&&MU work without delete additional file!!1!








Bye ^^

Edited by b3270791
  • Upvote 1
Link to comment
Share on other sites

Correct. All Windows Update data seems to be in DataStore.edb: WU/MU preference, updates installed from the website and whether they succeeded or failed, hidden updates, et cetera.

Link to comment
Share on other sites

if you delete the DataStore.edb, the History of updates is compromised :°°°°

Yes. I'm fully aware of that, and so is 5eraph. :(


And that's why I'm wondering whether one can make this particular omelette while keeping the corresponding eggs intact, so to say, or not...  DataStore.edb is a database file, after all, and not even encripted... can we maybe edit it successfully? :angel

Link to comment
Share on other sites

This is being highly discussed here:


The above link was just updated with a post about 1hr ago. It's starting to look like MS has screwed up ROYALLY!

There are *two* CAB files: "MUAUTH.CAB" and "AUTH.CAB".


I just ran MBSA2.2 and copied "MUAUTH.CAB" to my MU-WU work folder. The contents clearly indicate LEGACYsites and CABS. I downloaded the AUTH.CAB indicated inside and... Definitely different from previous. MBSA works!


I'll do some further work on what I've found on my XP VM to see if that's the only bugaboo and see if there's a "latest" workaround.


Contents of the XML downloaded

<?xml version="1.0" encoding="utf-8"?><ProviderAuthorizationInfo xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/msus/2002/12/SUSProviderAuthorization">  <ServiceID>7971f918-a847-4430-9279-4a52d1efe18d</ServiceID>  <CabVersion>8110</CabVersion>  <IssuedDate>2013-12-03T11:59:25.7927833-08:00</IssuedDate>  <ExpiryDate>2017-12-03T11:59:25.7927833-08:00</ExpiryDate>  <RedirectUrl>http://ds.download.windowsupdate.com/v11/2/microsoftupdate/redir/v6-legacy-muredir.cab</RedirectUrl>  <RedirectUrl>http://www.update.microsoft.com/v11/2/microsoftupdate/redir/v6-legacy-muredir.cab</RedirectUrl>  <OffersWindowsPatches>true</OffersWindowsPatches>  <UIPluginCLSID>3809920F-B9D4-42DA-92E0-E26265E0FB89</UIPluginCLSID>  <IsManaged>false</IsManaged>  <CanRegisterWithAU>true</CanRegisterWithAU>  <ServiceUrl>https://www.update.microsoft.com/v6/</ServiceUrl>  <SetupPrefix>mu</SetupPrefix>  <LocalizedProperties>    <Language>en</Language>    <Name>Microsoft Update</Name>  </LocalizedProperties></ProviderAuthorizationInfo>

It really is starting to look like (according to the link) that the Date is the go-bang *but* may be "patch-able". :unsure:

Edited by submix8c
Link to comment
Share on other sites

@submix8c I'm afraid it's not patchable.. I have examined the CAB file and it is signed with a special Microsoft Update certificate. If you sign it with everything else it will redownload the muauth.cab from Windows Update.

Edited by harkaz
Link to comment
Share on other sites

This problem occurs on Windows 2000 as I'm running it in VMware Player right now. I'm also wondering if this problem also occurs on Windows XP x64 and even Windows Embedded POSReady 2009.


I'm wondering if tampering the expiration date of the XML files in the MUAUTH.CAB and AUTH.CAB files will fix this or not. It seems that Microsoft was unaware of this mess.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    • No registered users viewing this page.

  • Create New...