DarkShadows

GUIDE: Download Everything Microsoft (MSDBuild v5.5)

203 posts in this topic

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

Edited by eGo®Z
0

Share this post


Link to post
Share on other sites

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 :D

0

Share this post


Link to post
Share on other sites
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.

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

0

Share this post


Link to post
Share on other sites
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.

Edited by DarkShadows
0

Share this post


Link to post
Share on other sites
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.
:wacko: 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? :whistle:

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

0

Share this post


Link to post
Share on other sites

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

0

Share this post


Link to post
Share on other sites

What's the frequency Kenneth? :)

Merry Christmas to you all!

0

Share this post


Link to post
Share on other sites
@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? :whistle:

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

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 ?

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 ? :blink:

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 ? :w00t:

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 ? :o

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

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 : :angel

0

Share this post


Link to post
Share on other sites

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

)

0

Share this post


Link to post
Share on other sites

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

0

Share this post


Link to post
Share on other sites

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

0

Share this post


Link to post
Share on other sites
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 ?
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.

The provided SFX-MSD.cmd script has a bug

Hey nice catch! :thumbup 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.

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

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.

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.com/fwlink/?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.)

0

Share this post


Link to post
Share on other sites

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

-DS

0

Share this post


Link to post
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.