Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically.

Recommended Posts

@atolica

Hey, thanks for trying things out and reporting back, good job

@Everyone

The overall issue really seems to be that Microsoft has opted not to update their .cab file downloads located at the server end all of the static URLs I listed in the guide. Instead, MS has become increasingly more reliant on using Windows Updates to install these.

I can't work on it today (), but trust me, I will be taking a good look at all the notes everyone has posted since the last Guide version and I will update MSDBuild.exe to handle as many things as I can. Remember, Microsoft tends to keep changing things around so it's always a moving target.

Share on other sites

Not for you Master ObiWan, but for the rest of us.

One update keeps failing in staying hidden: Microsoft Silverlight 1.0 (KB951213). I tried different approaches, but it still shows up after hiding it and packing Datastore.edb.

Edited by atolica

Share on other sites

I'd prefer the script you used. And what those registry entries are for?

Share on other sites

I used the default scripts LCC_FIX.cmd and MSDBuild.cmd, nothing more and nothing less. I ran MSDBuild.cmd after I replaced wuweb.dll inside the cab file.

The first registry entry is to have activex stop prompting for installation. The other two keys are created after running Microsoft update (they are constant entries). Without these it does not work. Tested.

Share on other sites

There is also a new 7.2.6001.788 version of muweb.dll not embedded in WUA. I could not find wuweb_site.cab nor muweb_site.cab links for the new versions.

I used the default scripts LCC_FIX.cmd and MSDBuild.cmd, nothing more and nothing less...
When I use LCC_FIX.CMD without post #87 modifications. In the process of Extracting WGA 905474 package..., I get a WgaNotify_Iexpress.exe box saying Command line option syntax error... Edited by strel

Share on other sites

WindowsUpdateAgent30-x86.exe contains wuweb.dll version 7.2.6001.788. The wupdate agent from the msdn link you gave is version 2.

Share on other sites
There is also a new 7.2.6001.788 version of muweb.dll not embedded in WUA. I could not find wuweb_site.cab nor muweb_site.cab links for the new versions.
I used the default scripts LCC_FIX.cmd and MSDBuild.cmd, nothing more and nothing less...
When I use LCC_FIX.CMD without post #87 modifications. In the process of Extracting WGA 905474 package..., I get a WgaNotify_Iexpress.exe box saying Command line option syntax error...

When I use LCC_FIX.CMD without post #87 modifications. In the process of Extracting WGA 905474 package..., I get a WgaNotify_Iexpress.exe box saying Command line option syntax error...

Probably because you or LCC script already extracted WindowsXP-KB905474-ENU-x86-Standalone.exe. Inside that is the real ms cab file with exactly the same name. After Lcc script runs it extracts and then deletes the previous KB905474-ENU-x86-Standalone.exe. Of course you can modify LegitCheckControl.cab file using cabarc. You can get it from here: Microsoft Cabinet Software Development Kit

LegitCheckControl.cab

Edited by atolica

Share on other sites
... Tested and working... but it covers only LegitCheckControl.dll.

The extraction proccess is not working. I substitute this:

ECHO.ECHO Extracting WGA 905474 package...START "" /I /WAIT /LOW %KB905474% /Q /X:%WGA%

with this:

ECHO.ECHO Extracting WGA 905474 package...FOR /F %%I IN ('CD') DO START "" /I /WAIT /LOW %KB905474% /T:%%I\%WGA% /CSTART "" /I /WAIT /LOW .\%WGA%\WgaNotifyPackageStandalone.exe /X:.\%WGA%% /Q

That issue is impossible to fix for me, but I will try... DarkShadows made his script to extract the Type 1 package (taking /Q /T: /C: switches), take the extracted executable (which takes /Q /X: switches) and moves it over the Type 1 package.

When LCC_FIX.CMD is launched, it has no way at all to guess what switches to use.

But the way you "fixed" that is ugly. the /C: switch is meant to embed a custom "install" command, which in our precise case should be an extraction command. You have the %CD% env. var. to replace your FOR loop.

The following code works in both cases (Type 1 or Type 2 file), and with the help of the /Q switch displays no warning popup AFAICT :

ECHO Extracting WGA 905474 package...START "" /I /WAIT /LOW %KB905474% /Q /T:%CD%\%WGA% /C:"WgaNotifyPackageStandalone.exe /Q /X:%CD%\%WGA%"IF NOT EXIST %WGA%\legitcheckcontrol.dll START "" /I /WAIT /LOW %KB905474% /Q /X:%CD%\%WGA%

There is a more elegant way to do, by first guessing the type. But this needs an external tool.

LCC_FIX2.CMD

Probably because you or LCC script already extracted WindowsXP-KB905474-ENU-x86-Standalone.exe. Inside that is the real ms cab file with exactly the same name. After Lcc script runs it extracts and then deletes the previous KB905474-ENU-x86-Standalone.exe. Of course you can modify LegitCheckControl.cab file using cabarc. You can get it from here: Microsoft Cabinet Software Development Kit

My two scripts (LCC_FIX.CMD and LCC_FIX2.CMD) aren't deleting/renaming/moving ANY exe file. They are extracting the contents to a temp folder then delete that temp folder.

Edited by kgee

Share on other sites

The last WindowsXP-KB905474-ENU-x86-Standalone.exe size 1,536,552 bytes is actually an archive that contains WgaNotifyPackageStandalone.exe size 1,487,400 bytes or the real KB905474. After WindowsXP-KB905474-ENU-x86-Standalone.exe is extracted using your first script LCC_FIX.CMD, that file is gone.Check your script.

kgee you migh as well create another script for replacing wuweb.dll inside wuweb_site.cab.

Edited by atolica

Share on other sites
The last WindowsXP-KB905474-ENU-x86-Standalone.exe size 1,536,552 bytes is actually an archive that contains WgaNotifyPackageStandalone.exe size 1,487,400 bytes or the real KB905474. After WindowsXP-KB905474-ENU-x86-Standalone.exe is extracted using your first script LCC_FIX.CMD, that file is gone.

Hmmm... When I said « aren't deleting/renaming/moving ANY exe file », I were obviously (at least for me) talking about files present on disk before execution of the script.

If the downloaded package is found (WindowsXP-KB905474-ENU-x86-Standalone.exe size 1,536,552 bytes, as you said), the command line used :

START %KB905474% /Q /T:Z:\TEMP /C:"WgaNotifyPackageStandalone.exe /Q /X:Z:\TEMP"

will delete WgaNotifyPackageStandalone.exe as soon as it extracted its own contents.

And that's Microsoft way of doing, not mine...

You might want to run this command line to integrate the package in an install source :

START %KB905474% /Q /T:Z:\TEMP /C:"WgaNotifyPackageStandalone.exe /passive /integrate:X:\path\to\winxp\cd"

This will correctly integrate the package (found in X:\path\to\winxp\cd\I386\SVCPACK\WgaNotify.exe), but the temporary file WgaNotifyPackageStandalone.exe (which is in fact the same as X:\path\to\winxp\cd\I386\SVCPACK\WgaNotify.exe) will be deleted from Z:\TEMP by the first package (WindowsXP-KB905474-ENU-x86-Standalone.exe size 1,536,552 bytes) as soon as the integration ended.

In other words, the package that takes /T: /C: switches understand /T as a specification for a temporary folder (other than the default), and /C as a command to run with/on the extracted contents. If /C is used and specifies a valid command, the temporary folder is cleaned up after that command as finished.

LCC_FIX2.CMD is directly using that "auto-clean-up" feature (noticed how Z:\TEMP appears twice ?)

Finally, as opposed to /T, which specifies a temporary folder ; the /X switch on the other package specifies a folder to extract contents to. That's not the same logic (hence "Type 1 hotfix" and "Type 2 hotfix"), thus one should use each package differently.

Are you OK or KO with my explanation ? Do you see why its pointless to keep the WgaNotifyPackageStandalone.exe by its own ?

(like having a CD and a CD case... no need to keep the CD somewhere and the case elsewhere, unless you like scratched CDs)

Which one should I check ? LCC_FIX.CMD or LCC_FIX2.CMD ?

LCC_FIX(2) is directly calling DarkShadows' script (MSDBuild.exe), which is (by design) overwriting the first package with the second. (hence the bug you found : when i wrote LCC_FIX, it was after having used MSDBuild.exe once, thus the first package was gone).

kgee you migh as well create another script for replacing wuweb.dll inside wuweb_site.cab.

OMG ! I might as well re-write the full MSDBuild.exe, but it would be scriptware piracy of DarkShadows' genuine idea...... hey ! look, there's Melinda Gates knocking at your door !

-DS

Share on other sites

I actually Googled, looking for "muweb.dll 7.2.6001.788" (without the quotes) earlier Wednesday. At the time, Google only returned three web pages, this thread being one of them with those search terms (I think there may be five web pages now). But only this thread (specifically your earlier post) mentions these two terms together in one sentence. In my testing on Virtual PC, I only have muweb.dll version 7.2.6001.784, and this is after successfully running all three updates sites: Microsoft Update, Microsoft Update Catalog, and Office Update. Now in the past, muweb.dll and wuweb.dll have always been in lock step as far as versions go. So I am surprised there is no place for us to acquire the new version. But at the moment I have no way of reliably locating muweb.dll, other than the .cab download URL I posted, and that .cab only contains version 7.2.6001.784, which as-tested works just fine.

So to answer your question, no, I will not consider copying a Microsoft file from my PC and posting it online. One, I believe that is in violation of the EULA. Two, I think it would undermine my user confidence. Other people have made installers for these ActiveX controls. But you'll notice that I am not sharing my installer with you (i.e. MSDownloads.exe). Instead, I am sharing my Installer builder with you, so you can build your own installer. Now, without modification, we will both surely end up with exactly the same installer. But the builder and it's process is transparent (it's all in script and .inf files). So any system admin can review exactly what "my installer" does to their PCs. All of the operating system files come directly from Microsoft (as they should).

Share on other sites

Well, putting it online would violate point 13 of XP pro EULA about software transfers, but I rather meant making the script use the latest version it founds after comparing the .cab file version and the one in each user's system folder. I don't think this would violate EULA.

The software would come from MS through the update system and the installers would be updated as possible, depending on the update condition. But yes, not all OS files would come from a direct download to the builder folder and maybe not all the installers would be exactly equal, depending on the update condition.

Anyway, I made my own installer based on your script. Forgot to say it. Great work.

Edited by strel

Share on other sites

Yeah I was gonna say, I made my own installer too. Can you just make a pack with the .inf's (they don't change much). I'd rather not have to use this download tool and whatnot.

Create an account

Register a new account