DarkShadows

Thanks You!

First, a .ulz file already is a zip file (it is just named with a different three-letter file extension similar to a .jar file). So zipping this file would be the equivalent of zipping up a .zip file--a waste of time. Second, posting a .ulz file, as-is would allow MSFN users to import an update list straight from the download link in an MSFN forum thread into Windows Update Downloader, just by clicking on the download link. When Windows Updates Downloader is installed, it recognizes and is the default handler for .ulz files. When Windows Updates Downloader is not installed, it would be like just downloading any other .zip file, only it has the .ulz extension.

MSFN user JCarle has provided a really nice utility,Windows Updates Downloader (WUD), which has its own forum here on MSFN. The update lists for this program are usually provided as .zip files with a different file extension (.ulz). It is possible to create custom updates lists for WUD, which are great to share with other MSFN users. Is there any chance that an admin could allow us to post .ulz files directly in our thread posts here? Currently, this file type is not permitted. Thanks for your consideration.

Thanks, it's working here as expected now!

@ricktendo64 Except for their [strings] section, each of of my Inst*.inf files, are nearly identical. In the [strings] section of each file I already defined a CLSID string appropriate for each ActiveX control. So I just simply added the same line below to each .inf file's [Product.Reg] section: ; Remove Microsoft Update ActiveX Prompt for IE7 HKCU,"Software\Microsoft\Windows\CurrentVersion\Ext\Stats\%CLSID%\iexplore","Flags",0x10001,4 It was a simple thing to add, once I knew the registry setting. Two minutes to change code, two hours to: test, update the documentation, and host new files.

I just updated the guide to v3.1. All changes discussed in the previous four posts have been fully tested and added. Re-download MSDownloads.ulz and all MSDownloads files in Windows Updates Downloader and recreate MSDownloads.exe. -DS

Duh Nevermind, it's already in my .inf file. I need to wakeup.

@ricktendo64 Do you happen to know the CLSID of Windows Update Web Control? I know most people will install Microsoft Update ActiveX, but I would still like InstWUWC.inf to be complete.

@COKEDUDEUSF Bascially, the whole guide has been updated. Read the Version History section for specific changes added in v3.0. Also the download files are handled completely differently now. @ricktendo64 Awesome, thanks man! No, I do not have those registry settings. I couldn't find them with RegSnap for some reason. I will add these to my Inst*.inf files. I also saw you posted on Wincert Forums how to remove a shortcut from the Start Menu (i.e. directly under Start Menu). I will modify InstMUWC.inf so that it removes the Windows Update shortcut, since installing that Microsoft Update Web Control renders the Windows Update shortcut a poorly named shortcut to Microsoft Update. @everyone For now, just read the new guide. But I suggest waiting until I: add the contrbutions from ricktendo64, test them, and post updated versions of MSDownloads.ulz and MSDBuild.exe after testing completes successfully.

I have just updated the guide to version 3.0, which covers: Windows XP SP2 with IE6 Windows XP SP2 with IE7 Windows XP SP3 with IE6 Windows XP SP3 with IE7 Please re-read the first post, especially the version history. -DS If someone could test everything and post back, that would be helpful. B)

As a test, I selected one update in WUD to re-download. I opened the containing folder in Windows Explorer and observed while WUD re-downloaded the file. I could see when the old file was deleted. I could also see the new copy grow in size as it was being re-downloaded. Afterward, Version 2.30 Beta Build 939 still did not highlight the update as being downloaded. I have now tried the same test running Version 2.30 Beta Build 939 on two PCs and received the same results. The first PC was installed with Windows XP SP2 32-bit, but it has been fully patched. The second PC was recently installed with a fully integrated Windows XP SP3. Both PCs have the full compliment of .Net Frameworks, etc. On both PCs, Version 2.30 Beta Build 939 does not highlight any update or category as downloaded. Here are my WUD options: Download Folder=M:\Slipstream\WUD Product as subfolder = enabled Category as subfolder = enabled Show Published Date = enabled Show Description Tooltips = enabled NOTE: All other options are disabled I should note that I am using my own customized .ul file. Below is the header of that file. This same .ul file generates no errors at all in Version 2.25 Build 895. In fact, if I uninstall Version 2.30 Beta Build 939, re-install Version 2.25 Build 895, and reconfigure my options correctly, everything works as expected and all previously downloaded categories and updates appear highlighted in green as expected. <?xml version="1.0" encoding="ISO-8859-1"?> <updatelist product="Windows XP" platform="x86" language="ENU" lastupdate="2008-07-17" xmlns="http://wud.jcarle.com" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://wud.jcarle.com http://wud.jcarle.com/wud.xsd"> <categories> <category id="1">Service Packs</category> <category id="2">SP3 Security Updates Critical</category> <category id="3">SP3 Security Updates Important</category> <category id="4">SP3 Security Updates Moderate</category> <category id="5">SP3 Hotfixes</category> <category id="6">SP3 Updates</category> <category id="7">Internet Explorer 6</category> <category id="8">Internet Explorer 7</category> <category id="11">Windows Media Player 11</category> <category id="12">MSDownloads</category> <category id="18">.NET Framework 1.1</category> <category id="19">.NET Framework 2.0</category> <category id="20">.NET Framework 3.0</category> <category id="21">.NET Framework 3.5</category> <category id="23">Tools</category> <!-- <category id="24">Windows XP Power Toys</category> --> <category id="26">Security</category> <category id="1002">Other</category> </categories>

I get the same results here, and was going to report it myself.

Microsoft usually does not list when a hotfix supersedes another hotfix. (They do this for security updates, but not for hotfixes, especially those that are not core Windows components, like WMP.) So when it comes to hotfixes, you must extract the packages, look at the payloads, and then compare the file versions of all the modules the collective group of hotfixes replaces. If you do that for all of the hotfixes on the current list, plus the two that you have inquired about, you will note the following modules and file versions: Update File Name Version -------------------------------------------- KB942264 wmp.dll 11.0.5721.5237 KB945381 wmp.dll 11.0.5721.5246 KB944110 wmnetmgr.dll 11.0.5721.5239 KB950478 wmnetmgr.dll 11.0.5721.5246 So KB945381 rendered KB942264 obsolete, and KB950478 rendered KB944110 obsolete. NOTE: Some hotfixes replace two or more files, and another, more recent hotfix may only replace one of those two files. In such a scenario, you would still require both hotfixes.

ITE Tech Software Download Page

I'm creating my own .ul file for managing Microsoft downloads with WUD. In my .ul file, I title each update with its KB article number first, in the hopes that WUD would list them by category from lowest KB number to the highest. This did not work. I also tried arranging the XML entries in the order I wanted them sorted, this did not work. Q: How does WUD determine the sort order for the updates in each category? EDIT: Just to clarify, WUD appears to sort updates by the publishdate, but I'm talking about when several updates were released on the same date, they do not seem to sort within date, by anything.

There isn't one, thus the guide I took the time to write. You end up creating your own .exe

Follow GUIDE: Download Everything Microsoft, WGA, WGA Notify, Windows/Microsoft/Office Update ActiveX, et. al. written by yours truly.

@orestes Your last post is really starting to get off topic for this thread. You should repost that as a general question to this forum. Please keep this thread on-topic, which is limited to the items discussed in my first post.

@midiboy The current Guide is not intended for Vista at all. But I'm glad to see that someone tried anyway. It will be months before I start playing with unattended Vista. The ActiveX controls get updated periodically to new versions, but my documented process to obtain them should not have changed (hopefully). @Kilyin If you encountered an issue with WGA using my guide, and you have already resolved it, then please Post or PM me what you needed to do differently for the most recent WGA to work. I will update the guide accordingly. It should still be the same download process to acquire WGA, unless M$ changed it again. @orestes Theoretically, for SP3 you would follow my guide soup-to-nuts after slipstreaming SP3 into your XPCD source. However, I'm certain that several of the requirement KB updates listed in my guide are now included in SP3, so you no longer need to integrate those. I will be integrating SP3 this week and updating the guide afterward accordingly. I will maintain requirements for both SP2 and SP3. My own process is: Copy XPCD Source (SP0 or SP1a) Slipstream SP2 (which would now become SP3) Slipstream Windows Media Player 11 (I use Boooggy's WMP11 Slipstreamer) Integrate all other Windows Updates Add other selected Microsoft and Windows Software installations to SVCPack.inf <--- This is where my guide comes in Add things to Cmdlines.txt Add things to RunOnceEx Yes, you can use the same compression settings for creating MSDownloads.exe and WindowsUpdateAgent.exe. Scroll up a few posts, you will see I recommend saving a WinRar profile and re-using it for each SFX you create. (I use those same settings for all my SFX installs). The only difference between each SFX are: The source files selected The file executed for each SFX. The SFX description information. This is why I included my comment files in the guide, I've done the other work for you. You can use the same WinRar profile and just paste the correct comment in. Maybe I'll include this in the next Guide version since I've typed up most of it already. @Everyone I've been away for awhile, but I can now work a little on updating this guide. Here's the situation, v2.5 of the guide was written exclusively for Windows XP SP2 with IE6. I know there are some issues when you install IE7 (you get prompted to re-download many of the ActiveX controls). Nothing about this guide was ever intended for Windows Vista, however some things may be adaptable to Vista (Vista already has many of the XP requirements built-in). So for now, I'm not going to focus on Vista at all. But here is what I will focus on for the next version of the Guide: Windows XP SP2 with IE6 - Some ActiveX controls have changed. Windows XP SP2 with IE7 - Same as A, but some ActiveX controls are different for IE7 Windows XP SP3 with IE6 - Same as A, but some requirements are now built into SP3 Windows XP SP3 with IE7 - Same as C, but some ActiveX controls are different for IE7 If anyone has used my guide with IE7 (and presumably made some changes) with any success, please PM me. I haven't even started doing Vista unattended installs yet, so such guide is a long way off (from me at least).

I didn't see this thread and I just posted a suggestion here.

@JCarle First, a big thanks for the work you have already put into WUD--it's a very helpful tool! If you could work this suggestion into a future version, I believe it would be even more helpful. ISSUE Currently, the user can only specify one download folder and one set of program options which then applies to all Update Lists. For example, a user routinely downloads updates for both Windows Vista 32-bit and Windows XP 32-bit. It would certainly be reasonable for said user to want to download the updates to two different download folders, so as not to mix the Vista updates with the XP Updates. In one case the user is interested in removing unlisted updates, in the other case he is not. It would also be reasonable for said user to want to set the program options differently for each Update List, so as to organize them differently for each OS. SUGGESTION I believe it would be more useful to specify one download folder and a set of program options for each Update List. Perhaps the Update List file format could be expanded to accommodate the program options to be used with that Update List, as well as the download folder path to which the updates should be copied? Nothing would need to be changed in the currently published lists. Once the user downloads a list, they would then edit the program options and download path, once for each list. Afterward these options are saved in the Update List file itself and retrieved by WUD when the user switches to a different Update List. Thanks for your hard work and your consideration,

Yes, I do have plans to update the guide and the downloads. However, I'm in the middle of moving right now and I have no time to complete it. I should also point out to folks that the guide above was written when I was still building PCs with Windows XP and Internet Explorer 6. I have since started integrating IE7 and that is where I have also noticed new ActiveX controls. I believe if you are still using IE6 that not much has changed.

InstWUWC.inf does not actually add a Windows Update shortcut, which should already be in the Start Menu as a result of a default Windows XP installation. If you are installing InstMUWC.inf (which creates a Microsoft Update shortcut), then you no longer require the Windows Update shortcut anyway. This is because either shortcut will both end up taking you to the Microsoft Update web site anyway (this is result of registering the MUWeb ActiveX addon). Still to answer your queston, InstMCWC.inf has the answer to the path for shell32.dll. [Add.Shortcut] ;Add shortcut directly to Start Menu Name = "%Shortcut%", 8,22 CmdLine = 16422,"Internet Explorer",IEXPLORE.EXE "http://catalog.update.microsoft.com/v7/site/home.aspx" InfoTip = "%InfoTip%" IconPath = 11,,shell32.dll IconIndex = 13 You would just change the IconIndex value to the correct index of the Windows Update Icon. And change the URL above to the correct one for Windows Update.

I am not sure, but I believe that when a folder already exists when Windows XP is installed, it will treat it as a user folder from a previous Windows installation. If you install Windows XP over top of itself--and create a new user account with the same name as an old user account--then old user folder is usually renamed some how. I believe Windows does this because the SID of the users are very different an cannot be migrated from installation to installation.

@Tomcat76 Have you read through Microsoft .NET Framework 3.5 Administrator Deployment Guide (MSDN)? It has a lot of information in it. I haven't had time to play with it yet. It is seems aimed at an active directory environment, but I'm wondering if there isn't a way to leverage some of that into a self-extracting executable? Most notable to me is the example NT Command Script at the bottom of the page. In the very last section of code: REM ------------------------------------------------------------ REM create the NETFX30 SP1 x86 admin install point REM 3.0 SP1 files location Set fx30=%WORKFOLDER%\ext\wcu\dotNetFramework\dotNetFX30\ md %WORKFOLDER%\AIP\NETFX30_x86 call msiexec /a %fx30%netfx30a_x86.msi /update %fx30%WCF.msp;%fx30%WCS.msp;%fx30%WF.msp;%fx30%WPF1.msp;%fx30%WPF2.msp;%fx30%WPF_Other.msp;%fx30%XPS.msp;%fx30%WF_32.msp;%fx30%WPF2_32.msp;%fx30%WPF_Other_32.msp USING_EXUIH=1 REBOOT=ReallySuppress /l*v %WORKFOLDER%\logs\netfx30_x86.log TARGETDIR=%WORKFOLDER%\AIP\NETFX30_x64 REM create the NETFX30 SP1 x64 admin install point md %WORKFOLDER%\AIP\NETFX30_x64 call msiexec /a %fx30%netfx30a_x64.msi /update %fx30%WCF.msp;%fx30%WCS.msp;%fx30%WF.msp;%fx30%WPF1.msp;%fx30%WPF2.msp;%fx30%WPF_Other.msp;%fx30%XPS.msp;%fx30%WCF_64.msp;%fx30%WCS_64.msp;%fx30%WF_64.msp;%fx30%WPF1_64.msp;%fx30%WPF2_64.msp;%fx30%WPF_Other_64.msp USING_EXUIH=1 REBOOT=ReallySuppress /l*v %WORKFOLDER%\logs\netfx30_x64.log TARGETDIR=%WORKFOLDER%\AIP\NETFX30_x64 EDIT: Also see Microsoft .NET Framework 3.5 Deployment Guide for Application Developers