Jump to content

Windows Update Agent - Which version do you have?


Guest

Recommended Posts

Bzzzzzz Bzzzzz - Busy bee...

-X- more than likely has also looked it over in his "spare time" (not yet implemented in his script). As far as 7-Zip instead, if you look at -X-'s UDC script, it does the same thing, so let's just say it's for the sake of consistency. ;) Also, please note that -X-'s package includes 7-Zip to preclude the need to download and "un-Zip a ZIP file" (it's freeware) as is WGET. Other files need to be downloaded due to EULA's (keeping everything legal) - the exception is blah-blah (which could probably also be "built). The "target audience" was initially -X-, so again, consistency. :yes:

Also note that "my script" needs a lot of cleanup of trash stuff. As far as "split" (see post#95), that seemed to be the only "free" program that fit the bill (PARTCOPY seemed to randomly fail download - also see post#69 and surrounding posts in addition to those surrounding post#95). Therefore, SPLIT could be also included in the "package" (note the source of the program - that link is dead but another exists for the complete set of utilities). If you can find another one, please let us know.

Answered? :D

Edited by submix8c
Link to comment
Share on other sites


A command line version of this, perhaps custom made by the author, if he can be located or by one of us, might be a worthwhile addition, too. As for split, while that repository does not have it anymore, it does contain the full package, which I downloaded. However, at least for the split in the full package, two .dlls (also contained it the full package) are also required, besides split.exe, for correct functioning. Was the original split you tested stand alone?

Link to comment
Share on other sites

Full package containing "SPLIT" is a newer version. The Older version is the one I use from here (11-11-1999) which doesn't require the two DLL's ("UnxUtils.zip" folder="usr\local\wbin"). Looking at the SourceForge Project, you can see where the changes were made. AFAIK, the change had something to do with Unicode. unsure.gif "UnxUpdates" (link) also has it (the ZIP is 859k vs 3287k) and is smaller (dated 06-20-2003). Haven't tested it yet...

I had stumbled onto the "remote zip" thingy before. Useful maybe to get the "SPLIT" program, not so much for anything else in this particular project (or the -X- package). Not sure, but I THINK I might have had this kind of thing on either a 98SE or ME OS some years (10?) ago.

Link to comment
Share on other sites

I give major props to ricktendo64 and others for making unofficial standalone WUA 7.6.7600.256(7) installers for Windows as they can save some users some headaches when updating/installing WUA fails using the normal methods (aka. install WUA 7.6.7600.256 via Automatic Updates or through visiting Windows Update site with IE, etc.) and getting error messages mentioned in these forum threads:

(Windows Update Agent 7.6.7600.256 Failing on Multiple Systems)

(Windows update agent 7.6.7600.256 fails to install. Error 8007041B. WSUS server running KB2720211)

and Microsoft is still reluctant to release standalone EXE installers for WUA v7.6.7600.256 as of today.

Link to comment
Share on other sites

  • 2 weeks later...

looks like ricktendo64 reverted his WUA packages back to 7.6.7600.256 about a week ago.

a recent Wincert forum user named RicaNeaga is having problems with WUA v7.6.7600.256 on his XP computer.

I don't have the problems he's having on my XP machine and WUA 7.6.7600.256(7) installed. the BITS service is working fine here and I've just installed some XP updates through Windows Update.

can anyone else reproduce the problem that person was experiencing?

Edited by erpdude8
Link to comment
Share on other sites

YOINKS!!! I just recently used the WU-MU package (Ricktendo64's) with "wuforce" manually (via a CMD) installed to a fresh WinXP and it works fine. The solution is to (IF you want v257) is to ADD it after (rather than Direct Slipstream) by actually running it. Otherwise, just use the v2.56 package, and for JUST WU use the EXE program from MS ( link also found on -X-'s website/inside the UDC BAT).

Seriously, I see no problem with it. The ONLY thing that happened was IE8 asked if I wanted to run an ActiveX (say "yes").

Link to comment
Share on other sites

  • 8 months later...

@-X-

Not sure if this would "fix" it...

1 - Download this instead (it's GNU Unix Port to Windows of "split.exe" so it's distributable). Put in the folder.

2 - Remove these PARTCOPY references

:: KEEP THIS ZIP FILE!!! MAY BE HARD TO GET AGAIN!!!
:: if exist pcopy02.zip del pcopy02.zip
if exist partcopy.exe del partcopy.exe

if exist pcopy02.zip goto GOTSPLIT
ECHO Downloading PARTCOPY from Web Archive...
:: --- UNDEPENDABLE!
:: wget -nc "http://web.archive.org/web/20010116021600/http://users.erols.com/johnfine/pcopy02.zip"
:: --- Use this instead...
wget -nc "http://www.brokenthorn.com/Resources/Programs/pcopy02.zip"
:: --- OR this instead...
:: wget -nc "http://geezer.osdevbrasil.net/johnfine/pcopy02.zip"
:GOTSPLIT
7za.exe e "%~dp0pcopy02.zip" -o"%~dp0" partcopy.exe -y

3 - Replace PARTCOPY code

::  NOTE! This MUST use 8.3... I DID NOT prefix filenames with "%~dp0"...
partcopy WUAEXE.EXE 0 8A00 WUSFX.SFX
:: The Install is no longer needed...
del "%~dp0WUAEXE.EXE"

with SPLIT code

:: Original Hex-8A00=Dec-35328
split -b 35328 wuaexe.exe wuaexe
:: output: wuaexeaa wuaexeab etc...
ren wuaexeaa wusfx.sfx
del wuaexe*.*

"SPLIT -HELP" displays syntax.

edit - and BETTING that using the "%~dp0" code would work...

I'm not 100% sure but it seems that PARTCOPY doesn't work at all when PAE is enabled (at least in Windows 2000). Nothing happens when it's executed. No errors, just nothing. I used it in my script to create MSCF.SFX before but because of this reason I've recently switched to the split.exe recommended by submix8c since it works fine.

Edited by tomasz86
Link to comment
Share on other sites

  • 1 year later...

Do not - repeat... DO NOT use the scripts for Building a "hyrid" v256/v257, i.e. using WUWEB.DLL v257. It causes a problem with Microsoft Update (NOT Windows Update!).

 

Use the 2K3/XP one directly from MS.

http://www.msfn.org/board/topic/173049-windowsmicrosoft-update-not-working-on-windows-2000xp2003/#entry1089544

And do read the whole thread to understand what the symptoms are.

 

The UDC scripts will also need to be changed as it currently inserts v257. Until such time as -X- changes the script to obtain the MS one (ref above link) I recommend changing the following lines in the BAT script *before* running it!

Old:

wget -nc http://www.update.microsoft.com/microsoftupdate/v6/v5controls/en/x86/client/wuweb_site.cab?1340383010227
Remove:

ren "%~dp0wuweb_site.cab@1340383010227" wuweb.cab
New:

wget -nc http://download.windowsupdate.com/v9/1/windowsupdate/b/selfupdate/WSUS3/x86/Other/wuweb.cab
Please note that this file is *not* the real problem (as far as is currently known) but the *real* problem *seems* to be the MUWEB.DLL (among other potential problem files).

http://www.msfn.org/board/topic/173049-windowsmicrosoft-update-not-working-on-windows-2000xp2003/#entry1089455

Further testing of MU and WU will be forthcoming. Meantime, the work-around replacement file (MUWEB) is here:

http://www.msfn.org/board/topic/173049-windowsmicrosoft-update-not-working-on-windows-2000xp2003/#entry1089383

 

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

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

Link to comment
Share on other sites

OK. I haven't had time to read those threads but the 257 file was required for MU when it was overkill for WU as the WindowsUpdate.log showed it looking for 256 but would say OK. I'll take 257 if that's what you have and not complain at all when you used MU. MS changed something?

 

EDIT: Just FYI, I just switched to MU using 257 and it worked flawlessly so will have to read the backstory on this.

Edited by -X-
Link to comment
Share on other sites

This may help with the "partial" explanation of what's going on:

http://web.archive.org/web/20120705003313/http://support.microsoft.com/kb/949104

 

http://answers.microsoft.com/en-us/windows/forum/windows_xp-windows_update/why-doesnt-my-windows-update-agent-update-to/283f4edf-aab6-4348-907d-984a1661e2a7?page=2
"If you expand the "File Information" section of MS KB article 949104:
 there are two versions of the wuweb.dll file listed.
  one is v7.6.7600.256 and the other is v7.6.7600.257.
  build 257 is indicated with a "+" sign and a "*" symbol
  + This file may only be installed if the machine is opted to receive updates
    for other Microsoft products from the Windows Update website.
  * Not Applicable on Vista and above"

 

The KB article has been updated to "toss" that info, hence the WebArchive.

 

It "seems" that when you opt into MU (from Windows Update) the v256 gets updated to v257, along with an installation of "MUWEB.DLL" v257. This is what "breaks" MU, so regressing MUWEB works around it. Looking back through this thread, you'll see how v257 was "automagically" updated.

 

As I've stated, I suspect (a conspiracy theory?) MS has held to their statement of not updating XP (maybe even 2K) non-OS-related software (e.g. Office). Worse, in the process, have totally "broken" MU. At one point, fiddling around (swapping the two), it actaully gave me a message (paraphrase), "So sorry, we don't support this OS". Heck, even the Catalog link has to use the direct URL or it says the same thing. Go figure...

 

Addendum: I'm re-testing a Clean Install (XPsp3 "raw") as we speak.

 

"I *heart* Microsoft"

Link to comment
Share on other sites

@submix8c:  Now we may be getting nearer to understanding why it happened! Thanks for the intersting info. :yes:

 

@all: However, just to keep all fundamental info in just one post, the current situation is, to the best of our knowledge:

 

I) Downgrading MUWEB.DLL to v. 256 is mandatory to get the MU site working again but, up to today, there's no need to also downgrade WUWEB.DLL to v. 256: WUWEB.DLL to v. 257 can be kept and is creating no problems that we know of.

 

II) Moreover, there's no need whatsoever to either upgrade or downgrade either authcab.cab or muauth.cab, despite much talk about that both here and elsewhere.

 

III) Nor anyone should either delete or rename the SoftwareDistribution sub-folder, which destroys the update history for sure, but does not really solve the MU site issue.

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...