[DarkShadows]

Guide updated to v4.5. Please read the Version History in the first post for more information.

-DS

[strel]

Have you considered taking muweb.dll 7.2.6001.788 directly from %SYSTEMROOT%\system32 instead of 7.2.6001.784 since there seemed to be no download link available?

[DarkShadows]

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

[strel]

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.

This post has been edited by strel: 10 December 2008 - 11:38 AM

[Nexus_06]

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.

[eGo®Z]

i've made MicrosoftUpdateAgent ver.7.2.6001.788
it uses the same setup engine like the original WindowsUpdateAgent30-x86.exe and, of course, supports the same setup switches:
MicrosoftUpdateAgent30-x86.exe /wuforce /quiet /norestart
supports 24 languages,
should be installed after Windows Update Agent ver.7.2.6001.788

Download it ~333KB

This post has been edited by eGo®Z: 08 December 2008 - 04:31 PM

[roadrunner64]

I was looking at this great guide and was wondering where the MSDBuild.exe file is to download?

I have looked thru-out this page.

Thanks in advance

[kgee]

strel, on Nov 27 2008, 02:31 PM, said:

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.

My computer strongly disagrees with you :
%windir%\System32\muweb.dll is version 7.2.6001.788.
%windir%\Downloaded Program Files\muweb.inf says FileVersion=7,2,6001,784

Microsoft Update site is working well AFAICT.

@ DarkShadows : the changelog seems interesting...

[DarkShadows]

roadrunner64, on Dec 13 2008, 08:41 AM, said:

I was looking at this great guide and was wondering where the MSDBuild.exe file is to download?

Follow the steps documented in the "Automate the Process" section. You use Windows Updates Downloader (WUD) to download everything required from Microsoft, plus my MSDBuild.exe.

Just so people are aware. I am forcing the issue for people to use WUD to acquire MSDBuild.exe. Why? Because many of the required Microsoft files change quite often. So any time you go to create your MSDownloads installer, I want you all to go (re)download everything in WUD. This way everyone should always be using the most recent files.

This post has been edited by DarkShadows: 16 December 2008 - 12:38 PM

[DarkShadows]

strel, on Nov 27 2008, 02:31 PM, said:

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.

kgee, on Dec 13 2008, 09:05 AM, said:

My computer strongly disagrees with you :
%windir%\System32\muweb.dll is version 7.2.6001.788.
%windir%\Downloaded Program Files\muweb.inf says FileVersion=7,2,6001,784

Microsoft Update site is working well AFAICT.

@ DarkShadows : the changelog seems interesting...

@kgee
Q: Did I make a mistake in the Version History, or are you just entertained by my stumbling around this project and quasi-ranting about it?

@kgee, strel, and Everyone
As I mentioned in an earlier post, wuweb.dll and muweb.dll have always been in lock-step as far as version numbers go (at least as long as I've been maintaining this project). However, in my last round of updating MSDBuild and testing the hell out of it, I was never able to find muweb.dll v7.2.6001.788. And this was after re-installing my unattended XPCD (with the newest version of MSDownloads.exe integrated); and, it was after running all three Microsoft update websites: Microsoft Update, Microsoft Update Catalog, and Office Update. (After all that, I always search the hard drive looking for more up-to-date versions of any .dll included in MSDownloads.exe.) I could only find muweb.dll v7.2.6001.784.

But today I just checked on an XP PC that I installed about a week or so ago; this time, I finally found muweb.dll v7.2.6001.788 inside %WinDir%\System32\. I just have no idea how or when it got there.

So as far as I am aware, we still have no place to reliably download this file from Microsoft (yet). But faced with this confirmed evidence (that strel first reported), I will update the next MSDBuild package to look for muweb.dll inside the %WinDir%\System32\ folder and compare its version to that of muweb.dll inside of muweb_site.cab. MSDBuild.cmd will always use the most recent version of the two inside of your MSDownloads.exe installer.

However, let me point out to you folks that you will only be able to obtain muweb.dll from inside %WinDir%\System32\ on the PC on which you are building MSDownloads.exe. I just checked and this file does not exist on a Windows Vista system. So this means, that to get the newest muweb.dll file, that you must build MSDownloads.exe on a Windows XP PC, and then after whatever unknown events conspire to download (or install) the most recent version of muweb.dll to your PC.

Challenge
I do not have high speed Internet access where I am currently staying, so I'm issuing a challenge to all of you good people who like to look over things and point out hidden details. After installing the current version of MSDownloads.exe, try to identify the precise point or trigger events when muweb.dll v7.2.6001.788 is downloaded to your PC. If you can find that out, I can tell you how to get the download URL, and then I can update MSDownloads.ulz so that we can download this file in advance, instead of waiting for it to show up on our PCs.

[DarkShadows]

@Everyone
Okay folks. You can forget about my challenge. I now know where my PC obtained muweb.dll v7.2.6001.788 from--from Microsoft on 12/07/2008 when I last ran Microsoft Update. This means that someone at Microsoft finally updated the .cab files on their download server (where the direct download links I posted in the guide point to). And in fact I just downloaded muweb_site.cab and verified that it now contains muweb.dll v7.2.6001.788. Most likely, just running Microsoft Update updates the ActiveX control from the Code Base url (since my .inf files ensure the update functionality actually works). And since, I now tell windows to suppress prompting the user to authorize this ActiveX control, I didn't get notified of the change.

So all you really need to do right now, is re-download all of the files using WUD and you will get the latest version of muweb.dll and wuweb.dll directly from the Microsoft direct download links.

I will still update the MSDBuild.cmd script...eventually. But there is really no urgency to do so right now and I have other things I need to complete. So for the time being, there will be one tiny inconsistency, which kgee reported above: the .inf file will say the previous version, but the downloaded (and installed) .dll file will be the current version. But as I have stated many times, this is of little to no consequence.

[Nexus_06]

I and many other still just want the scripts...

PLEASE =]

[atolica]

What's the frequency Kenneth?

Merry Christmas to you all!

[kgee]

DarkShadows, on Dec 16 2008, 08:23 PM, said:

@kgee
Q: Did I make a mistake in the Version History, or are you just entertained by my stumbling around this project and quasi-ranting about it?

About the changelog... hell... my windows is not needing a reinstallation for now

My point was that even MS developers were unable to track correctly the minor build number between the DLL and its INF.
Or maybe what you are labeling "one tiny inconsistency" is a feature and not a bug ?

Spoiler

I am, maybe, entertained by this whole topic... not by "[your] stumbling around this project" (if I understand correctly), but by all this WGA and Legit*.dll stuff. Their answer to Software Piracy is to annoy users who paid them... and users who like MS software should pay MS for that, don't you find that amazing ?
Hey, just take a look at that Vista feature, the User Account Control. Don't you remember that "UAC" was the name of one of the organizations involved in the game Doom, more than 10 years ago, and that "UAC" was printed on half of the doors in that game ? Don't you find that amazing ?
At last, isn't ID Software owning a copyright on that game ? And a "door in a game (leading to a room full of monsters to kill)" is something very close to "a user prompt in an OS (leading to possible security leaks)", isn't it ?
Who is the theft and who is the lawyer ?
Who is entertained and who entertains ?
Think about that while reading again my remark about "scriptware piracy" some days ago...
Many questions to answer yours...

DarkShadows, on Dec 16 2008, 10:32 PM, said:

So for the time being, there will be one tiny inconsistency, which kgee reported above: the .inf file will say the previous version, but the downloaded (and installed) .dll file will be the current version. But as I have stated many times, this is of little to no consequence.

Today, I've seen an updated muweb_site.cab file, embedding the correct INF...

Merry Xmas !

PS @atolica :

[mtlroom2]

The provided SFX-MSD.cmd script has a bug, I put wrong letters in bold (they have to be swapped)

If Exist InstWGAV.inf If Exist InstWUWC.inf If Exist InstMUWC.inf (
Attrib -R -S -H InstMUWC.inf
>> InstMUWC.inf Echo.System32Key = "%System32Key%"
Start /Wait "Microsoft Update Web Control" %InstallINF% .\InstMCWC.inf
)
If Exist InstWGAV.inf If Exist InstMCWC.inf (
Attrib -R -S -H InstMCWC.inf
>> InstMCWC.inf Echo.System32Key = "%System32Key%"
Start /Wait "Microsoft Update Catalog Web Control" %InstallINF% .\InstMUWC.inf
)

[leass_lp]

How can I adapt this to anopther language version of Windows? What do you advise me to do?

[andrewcrawford]

the MSDBUILD download file is corrupt, i have tried to download it 5 times on 3 different computers, ever time it downloads it only 2kb and 7zip says the archive is corrupt any way to get this other than the downloader

[eGo®Z]

legitcheckcontrol.dll is updated to 1.9.0009.0
download it

[DarkShadows]

kgee, on Dec 25 2008, 10:25 AM, said:

My point was that even MS developers were unable to track correctly the minor build number between the DLL and its INF. Or maybe what you are labeling "one tiny inconsistency" is a feature and not a bug ?

DarkShadows, on Dec 16 2008, 10:32 PM, said:

So for the time being, there will be one tiny inconsistency, which kgee reported above: the .inf file will say the previous version, but the downloaded (and installed) .dll file will be the current version. But as I have stated many times, this is of little to no consequence.

I believe it is me and not MS. The version inconsistency is a bug of sorts created by the original process I chose. Historically, I manually updated my Inst*.inf files for each ActiveX control with the .dll version. As time goes by, Microsoft releases a new ActiveX control .dll version, so my hard-coded Inst*.inf file version becomes outdated. (You still use the current version .dll file, but the .inf file sets the registry to an older version.) I'm thinking about how to fix this in the next version of MSDBuild so as to address .dll versions programmatically across all the ActiveX control .dll files. In fact, I am already doing this for two of them.

mtlroom2, on Dec 26 2008, 11:13 PM, said:

The provided SFX-MSD.cmd script has a bug

Hey nice catch! That bug has only been there since like v1.0. You are the only person who caught it! I will fix in the next version of MSDBuild.

leass_lp, on Jan 24 2009, 10:09 PM, said:

How can I adapt this to another language version of Windows? What do you advise me to do?

I will be updating MSDBuild (and the guide) in the coming days, so this will change a little. But for now, download everything using WUD then run MSDBuild.exe. Do not delete the work files! Read the Issue in the guide (or Readme.txt file) regarding non-English language usage. Edit the lines noted inside of each of Inst*.inf files noted. NOTE: If an Inst*.in_ file exists, edit it instead of the Inst*.inf file of the same name, since MSDBuild will always copies the Inst*.in_ file to create the Inst*.inf file with each execution (appending some information to it and overwriting the Inst*.inf file in the process).

andrewcrawford, on Jan 27 2009, 01:17 PM, said:

The MSDBUILD download file is corrupt, I have tried to download it 5 times on 3 different computers, ever time it downloads it only 2kb and 7zip says the archive is corrupt any way to get this other than the downloader

The file on the sever is not corrupt, since I just downloaded it (over dial-up no less) and tested it.

I don't publish the direct download links to any of my files since they are hosted on free file-hosting sites (the download links may change frequently). Also, I encourage using WUD because when you download everything with it, you will always have the most up-to-date files, since all of the download links are reusable now (even MS finally got their act together).

Is it only that file that gets corrupted? If not, make sure you have .Net framework 2.0 installed on the PC you run WUD on. And try re-installing WUD.

eGo®Z, on Jan 27 2009, 07:43 PM, said:

legitcheckcontrol.dll is updated to 1.9.0009.0
download it

Thanks for the version notice. However, the posting any of the .cab download links is not required (they are already in the guide). Microsoft uses a "static link" of http://go.microsoft....k/?linkid=39204 for LegitCheckControl.cab, which is reusable, and will always send you to the most current version (and to the same place as the longer URL that you posted). The only time these links (the static ones or the one you posted) fail us are when MS is a little slow with the housekeeping chores and they don't update the .cab file with same version of the .dll as is used inside of a related Microsoft knowledgebase/Windows Update download. (This is why MSDBuild checks the .cab and the KB downloads and uses the newest version.)

[DarkShadows]

Guide and MSDBuild updated to v5.0 Please read the Version History in the first post for more information.

-DS