Jump to content

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


MrMaguire

Recommended Posts

There is an alternative muauth.cab available at http://download.windowsupdate.com/v6/windowsupdate/redist/standalone/muauth.cab which has a 2027-05-02 expiry date, but it doesn't seem to work. When I substituted the current muauth.cab by the one downloaded from the address above, MU redownloaded the one having a 2014-11-17 expiry date and overwrote the newer one... go figure!   

Link to comment
Share on other sites


I have yet to find out where the latest MUATH.CAB is. It *seems* that MU is looking at the Digital Signature date(?).

Also, there seems to be *something* about AUTHCAB.CAB. :unsure:

ATM, i'm ignoreing the MU part of the "problem" since...

 

As for the script to build v256 (with the v257 WUWEB) I'll correct/remove that as soon as I have the chance.

In the meantime, it seems that Ricktendo (one of the folks that helped with the project) has been holding out, or at least forgot to inform us of this development.

http://www.wincert.net/forum/topic/9907-official-windows-update-agent-767600320

As you can see, the links are directly to the MS files as also given here:

http://support.microsoft.com/kb/2887535

You will need the Win7SP1 one that corresponds to the x86/x64 that you have. (note: this is v320)

From the Wincert link, you'll see the last comment that indicates the specific EXE within this combo package.

Extract the MS Download and you will find the long-awaited v256 Standalone Package "WUA-Downlevel.exe".

I've compared the contents to a (corrected) Build Script and they are identical except for:

- The 3 WUClient cabs are different (just becaase of compression headers) but the contents are identical

- The WUSETUP.INF is nearly identical to the Built (difference is insignificant aand applies to x64)

- The WUSETUP.EXE (and the MUI's in the Lang sub-folders) are as follows :
::    7.6.7600.243 (winmain_wtr_wsus3sp2(oobla).110811-1411) <-From the original v243/built
::    7.6.7600.311 (winmain_wtr_wsus3sp2(oobla).140312-1810) <-From the Downlevel package

I've yet to load Raw XP-SP3 and install/test, but it *seems* to make the Build Script obsolete.

http://www.msfn.org/board/topic/157027-windows-update-agent-which-version-do-you-have/

(Will remove the attachments at first chance.)

I therefore recommend that the MS package be tested/used.

 

***EDIT!*** Also see this:

http://www.msfn.org/board/statuses/user/72994-submix8c/?status_id=3393

(sigh... initially "clean install" using MUWEB v256 may/may-not *cure* the problem involving WU...)

 

edit2:

ONO's!!! I'm sensing a pattern here. No matter the version WUWEB, if you start in WU and "Step up to MU" you *do* get MUv257, so it almost looks as if MS is standing by its word of supporting *only* XP on XP. :unsure:

Of course, I haven't done a "clean" install yet. :(

Edited by submix8c
Link to comment
Share on other sites

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

<ExpiryDate>2014-11-17T17:27:43.5251853-08:00</ExpiryDate>

 

to solve the problem temporarily, please downgrade muweb.dll to -> 7.6.7600.256

Hello -- 

 

I can't find the file MicrosoftUpdateCatalogWebControl.dll on my system ... 

 

What folder / dir should I copy it too? The same as muweb.dll

Link to comment
Share on other sites


Hello -- I can't find the file 
 
MicrosoftUpdateCatalogWebControl.dll
 
on my xp system -- do I need it to in addition to the downgrade of 
 

muweb.dll
 
Thanks
I wonder :unsure: which was the difficult part in:

But we now know it isn't necessary to downgrade MicrosoftUpdateCatalogWebControl.dll at all.
So, you can totally forget about it and just replace muweb.dll, OK?

:whistle:

jaclaz

Edited by jaclaz
Link to comment
Share on other sites

Well! Looks like MS probably got an earful from their customers, more than likely those businesses still using Server2k3. You could see they were hot under the collar for horking their WSUS Servers and Client Workstations. $ talks. ;)

 

Just for funsies, first chance I get I'll retest a "clean install" and see what happens.

 

Note: haven't tried putting the v257 one back yet but I trust that all is well as reported. :unsure:

Link to comment
Share on other sites

[CUT]

 

Note: haven't tried putting the v257 one back yet but I trust that all is well as reported. :unsure:

 

now, the WU service ad registred as new flag {2}, please read your log file "%windir%\WindowsUpdate.log"

2014-11-27	01:51:02:812	2276	a1c	COMAPI	-----------  COMAPI: IUpdateServiceManager::AddService2  -----------2014-11-27	01:51:02:812	2276	a1c	COMAPI	  - Service ID = {7971f918-a847-4430-9279-4a52d1efe18d}2014-11-27	01:51:02:812	2276	a1c	COMAPI	  - Allow pending registration = Yes; Allow online registration = Yes; Register service with AU = Yes2014-11-27	01:51:02:812	2276	a1c	COMAPI	  - Authorization cab path = <NULL>

and read this -> http://msdn.microsoft.com/en-us/library/windows/desktop/bb394829%28v=vs.85%29.aspx

 

<cite>

AddService2

Registers a service with WUA without requiring an authorization cabinet file (.cab), and returns a pointer to an IUpdateServiceRegistration interface.

...

If you specify asfAllowPendingRegistration and asfAllowOnlineRegistration together, the update agent immediately attempts to go online to register the service. AddService2 returns S_OK if the registration succeeds. AddService2 returns a failure HRESULT value if the registration fails, but the update agent still attempts to register the service at a later time.

</cite>

 

and read into log file:

WU client internal API CClientCallRecorder::Register succeeds!!1!

 

before, when the service was down, the flag asfAllowPendingRegistration and asfAllowOnlineRegistration is not set

 

<cite>

If you specify neither asfAllowPendingRegistration nor asfAllowOnlineRegistration (in other words, if flags is either zero or asfRegisterServiceWithAU), you must specify a non-NULL path in the authorizationCabPath parameter. In this mode, AddService2 processes the cabinet file (.cab) and registers the service in the same way as IUpdateServiceManager::AddService.

</cite>

 

 

I think that: Microsoft update run fine until the COM server side subrutine have this flag value!!1! the problem was solved server side without releasing a new dll, (muweb.dll) which still contains the expired certificate, good rpc method, until the next release of dll!!1!

PS... you can delete the file muauth.cabyou do not need, and will not be created

 

bye ^^

Edited by b3270791
Link to comment
Share on other sites

i need some help, guys.. it might save me from having to do another clean install..

 

i forgot to backup a copy of the original "muweb.dll" file, build 7.6.7600.257.. can someone upload a copy of it and provide me with a link for downloading it?

 

maybe send me the link in a pm.. a lot of forums don't like people posting links for downloading files, so send it to me in a pm..

 

otherwise, i don't know how to restore the original muweb.dll file, not without doing a clean install of windows..

Edited by redwolfe_98
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...