DarkShadows

@JCarle I just downloaded v2.40 and thought I'd take a look. (Boy, am I late to the party huh?) First, I'm always a huge WUD fan, so your continued efforts are most appreciated. Things I really like in WUD v2.40: The window can finally be resized! The update list can finally be sorted ascending or descending! Second, I'd like to raise some issues I hope you will consider addressing. Things I believe are missing in WUD v2.40: The update list cannot be sorted by any field other than Date. It would also be nice if the ID field (<update id> tags) was displayed and if the update list could also be sorted by ID. This would be useful since most updates use KB number for their ID. This makes it easy to find an update in a long list and click the link to read the article. Things in WUD v2.40 that I believe are a step backward from WUD v2.30: In Tabs vs. Trees, the Trees always win with long lists. I maintain my own WUD download lists, which are much more comprehensive and more in-depth than those offered on the WUD website. I break apart Microsoft updates into the various categories Microsoft uses. I also add Product-related downloads that are not updates (Like Windows Powertoys and such). Below are the categories I use for Vista (and XP where applicable). <categories> <category id="1">Service Packs</category> <category id="2">Security Updates Critical</category> <category id="3">Security Updates Important</category> <category id="4">Security Updates Moderate</category> <category id="5">Hotfixes</category> <category id="6">Updates</category> <category id="7">Internet Explorer 7</category> <category id="8">Internet Explorer 8</category> <!-- category id="9"=Internet Explorer 9 (when it is RTM)--> <category id="10">.NET Framework</category> <category id="11">Windows Media Player 11</category> <!-- category id="12"=Windows Media Player 12 (when it is RTM)--> <category id="13">MSDownloads</category> <category id="14">Windows Defender</category> <category id="15">Tools</category> <category id="16">Power Toys and Extras</category> <category id="17">Media Center</category> <category id="18">Ultimate Extras</category> <category id="30">Windows Live</category> <category id="99">Other</category> </categories>I have thought about sharing my lists with the MFSN community, but I'm still working on a few things. But after seeing WUD v2.40 I don't think it is such a good idea to share my lists. In WUD v2.30 having as many categories I use isn't much of an issue, since the categories could be expanded and collapsed vertically similar to a folder tree. With all the categories collapsed, once could easily see most (if not all) of the categories at-a-glance or with very little scrolling (a re-sizable windows added to v2.30 would be awesome). And with the v2.30 color-coded boxes on the categories themselves, one could quickly see which categories needed attention. The WUD v2.40 Category Tab motif looks like a great idea at first. However, it is really only user-friendly when an update list uses just a few categories. The Tab motif quickly becomes unwieldy when using more categories (or even a few categories with long names); things start scrolling off the screen, and there is no way to see all the categories at once. And WUD v2.40 offers no visual feedback as to which categories are up-to-date or not. No Color Feedback, In-fact No Accurate Feedback At All I think this has been reported already, but for me, WUD v2.40 does not accurately report when an update is downloaded. Everything gets a check mark. I really liked the WUD v2.30 colored feedback NOTE: In the two images above, I deleted the IE8 download. Notice that WUD v2.30 communicates this correctly and WUD v2.40 does not. InfoTips are now a disaster The update lists I maintain also contain copious notes in the InfoTips (<Description> tags) for many updates (very useful for hotfixes, which are not required for all system configurations). Most of my InfoTips are between 4 and 6 lines long, but many are even longer. The WUD v2.30 InfoTips were much nicer both in their color and in their presentation of information--they are able to display several lines of text. The WUD v2.40 InfoTips are a step backward, all of InfoTips are all truncated after about a line and half of text. It would be nice to have the WUD v2.30 InfoTips in WUD v2.40. Also if there is some way to lengthen the delay before the InfoTip disappears that would be helpful. (Ideally, if the mouse is still hovering, the InfoTip would still be displayed). I hope you will keep hosting WUD v2.30 b988 up on your web site.

I'm revisiting this old thread, with a new idea for others. As I described earlier in this thread, one very effective utilization of a template is to pre-create a file (of whatever file type) containing contents that you are likely to re-use often. This is what a template is intended for. Take for example, a .cmd script. File Extension: .cmd Vista File Type Name: Windows Command Script XP File Type Name: Windows NT Command Script When I create a new .cmd script, I usually want to re-use at least some portion of another .cmd script I coded earlier. And as time goes by, and my various scripting techniques become more air-tight and tested, I will develop many re-usable script portions, or code examples. These are what can be added to a template file for later re-use. You don't need to add a whole script (but you could), just the parts that are heavily re-used, or those that are sometimes re-used and difficult to wrap your head around (hopefully with copious comments). Now earlier, this thread discussed adding a template to the Shell Context Menu - New submenu. However, there is more than one way to skin a cat. Giving every user at the same PC access to the same template file may not always be advisable. What I want in my template and what another user wants in their template could be different. This might even depend on the template used. For example, I don't want my family members to have an item titled: "New -> Windows Command Script.cmd" in the their Windows Explorer context menu. They don't know how to write scripts, and they could get themselves (and the system) into trouble, if I left a .cmd file accessible for them to create and later double-click on. (This is why Microsoft didn't create a template for this file type.) But I certainly want a .cmd template for myself, since I write one about once a week. Well fortunately, Windows can handle this scenario. This .reg file suggested above was: Windows Registry Editor Version 5.00 [HKEY_CLASSES_ROOT\.cmd\ShellNew] "FileName"="Template.cmd" Using this file, the Template.cmd file must reside in the current user's profile, under the Templates subfolder, or one must exist in the All Users/Public profile under the Templates folder. The system must also be rebooted before the template will be available from Shell Context Menu - New Submenu. The .reg file below also produces exactly the same results, because HKEY_CLASSES_ROOT is just a short registry address to HKEY_LOCAL_MACHINE\SOFTWARE\Classes. Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.cmd\ShellNew] "FileName"="Template.cmd" Settings under the HKEY_LOCAL_MACHINE hive affect all users. That is, unless a similar setting exists under the HKEY_CURRENT_USER hive and the software in question is designed to make use of the per-user setting. Well guess what? We can do this with templates. The registry file below also works, however, it will only check the current user's profile under the Templates subfolder. Windows Registry Editor Version 5.00 [HKEY_CURRENT_USER\Software\Classes\.cmd] [HKEY_CURRENT_USER\Software\Classes\.cmd\ShellNew] "FileName"="Template.cmd" The .reg file above will set the same context menu item, but only for the current user. This means I can have my .cmd script template, but not share the template with members of my family (which could be dangerous in this case). Other users on the same PC will not see template listed under Shell Context Menu - New Submenu. In the case of per-user registry settings, you do not need to reboot the PC, you only need logoff and then logon. NOTE: If you add HKEY_CURRENT_USER registry settings during unattended Windows installation, then all users get them. What I have discussed here is more for after Windows is installed. Both Vista and XP share the same behavior.

@Rich_Weiss Thanks for taking the initiative and for reporting your results. I'll include your findings in the next version of the guide and add the required registry settings to the setup Information (.inf) files. Thanks for saving me some research time. Hey guess what? You're one of the giants now, nice job!

CmdLines.txt is discussed in-detail in the MFSN Unattended Guide, the link to which is located at the very top of this web page, just below the MSFN logo.

First, I don't use nLite. But all nLite really does is create a working Windows unattended installation image. You must still answer all the questions that go into all the Windows Setup blanks during an attended installation. In unattended installation, the Computer name is specified in the winnt.sif file, so this would require a different image for each unique PC—not very effective or re-usable. Generating several hundred unique PC names is beyond nLite's scope, but even more troubling is how to generate those computer names, and keeping track of them while keeping them mutually exclusive. I believe something like assigning unique Computer names is better accomplished outside of unattended installation, either by a Script (VBScript or other) that perhaps pulls the names from a shared list on a server (marking each name as used as the script assigns it), or manually entered by a human during installation. Or, it may be possible for a script to acquire a unique hardware serial number (BIOS DMI information, motherboard serial number, NIC MAC address, etc.) and use that as the basis for unique PC name. There are most likely utilities for this that you could Google for. Or, after creating a working Windows installation image (one for each PC model and OS), you could just edit the Winnt.sif file inside the image (before burning it to media) and remove the ComputerName = parameter. This will cause Windows Setup to prompt for a Computer name during installation (but all other questions would still be pre-answered). Then it is a human decision what to name each PC.

Bah, Humbug! The command syntax looks like MS-DOS, acts like MS-DOS, even has some of the same bugs as MS-DOS. (Although, it does have some newer and more inventive bugs than MS-DOS did.) I'll bet they kept 90% or more of the code exactly the same as it was for MS-DOS, when they tucked it up inside Windows. However, it is true that it is no longer a Disk Operating System, and in that regard, it truly is not DOS. Just ruffling your feathers Yzöwl

The /INTEGRATE function works with KB960680-v2 in that: the entries I noted above are correctly added to svcpack.inf and the .cat and .exe files are correctly copied to the XPCD\I386\SVCPACK folder. And while I did not test installing the KB960680-v2 update after installing Windows XP first, the integrated KB960680-v2 update installs just fine during Windows Setup—installation is not the issue. The issue is that after the integrated update is installed, the Default User's registry hive is somehow fubared and will not get copied to each new user local account, during that account's first login. In fact, installing the KB960680-v2 update after Windows XP is already installed and running will have no bearing on the issue at all; because at that point, a local user account (not the Default User) is logged in. And there will never be an occasion where Windows XP will copy a local user account's HKEY_CURRENT_USER hive (ntuser.dat file) to another local user account. If you read my post above, I clearly am not talking about the HKEY_Users\.Default registry key. This should have been quite evident since I provided step-by-step documentation on how to correctly load the Default User's HKCU registry hive.

Update, I tried integrating and installing everything as discussed in my post above, but also with deleting the registry value discussed in the KB article. No success, the issue persists.

I am still working on integrating SP3, Internet Explorer 8, and all post-SP3 windows updates and hotfixes into a Windows XP source myself. And all of that must pass my testing on-its-own, before I attempt to apply the concepts discussed in this guide to Windows XP SP3 and IE8. I just spent over 64 hours of integrating and installing Windows XP in Virtual PC, once every 45 minutes, removing different windows updates and software packages until I finally narrowed down that a critical issue I was encountering was not even related to IE8 but is an Integration Issue with KB960680-v2. So long-story-short, it will be a while longer before I can update and certify this guide for use with IE8; but, yes, there are plans to do so.

BACKGROUND: Most Windows XP updates that are post-service pack 2 support integration into a Windows XP source, via the /INTEGRATE command-line switch. Usually, Integration unpacks the Windows update to a temporary folder, copies its Security Catalog (.cat) file to the I386\SVCPACK folder of the Windows XP source, and add the correct entries to the I386\svcpack.inf file that are required for installing the update unattended during Windows XP Setup. During Windows XP Setup, all integrated Windows updates are installed at the T-13 phase, when svcpack.inf is processed. Immediately afterward, all entries inside of cmdlines.txt are executed at the T-12 phase. During both the T-13 and T-12 phases of Windows XP Setup, there is no user logged into Windows; instead, Windows Setup uses the Default User's profile as the current user. Any registry settings applied to the HKCU hive during these two Windows Setup phases actually get applied to the Default User's NTUSER.dat file which stores its HKCU hive. However, these settings should get copied to the each local user account profile, as that user first logs into Windows XP. At a local user account's first login, Windows copies the Default User's entire profile folder to the new local user account's user profile folder, which includes the ntuser.dat file, which stores the HKCU hive for the local user account. KB960680-v2 is an update that apparently supports the /INTEGRATE switch; and, as such, should install correctly during T-13, from svcpack.inf. The svckpack.inf entries added for this Windows update after using /INTEGRATE on a Windows XP Service Pack 3 source are shown below. [Version] BuildNumber=2600 MinorVersion=1 MajorVersion=5 Signature="$WINDOWS NT$" [SetupData] CatalogSubDir="\I386\svcpack" [ProductCatalogsToInstall] KB960680-v2.cat [SetupHotfixesToRun] KB960680-v2.exe /q /n /z /b:SP3QFE [CatalogHeader] When Windows XP is installed and running, the Default User account's HKCU registry hive can be loaded within RegEdit.exe by doing the following: Execute RegEdit.exe from Start Menu - Run. Select the HKEY_USERS hive. From the File menu, select Load Hive. Enter the path C:\Documents And Settings\Default Users\ntuser.dat, and Click the OK button. When prompted, for a Key Name, type DefUser and click the OK button. You should now be able to now inspect (or change) registry settings under HKEY_USERS\DefUser key, which is the Default User's HKCU hive. NOTE: The hive must always be manually unloaded by doing the following: Execute RegEdit.exe from Start Menu - Run. Select the HKEY_USERS\DefUser Key. From the File menu, select Unload Hive. ISSUE: After installing Windows XP with KB960680-v2 integrated into svcpack.inf, when a local user account first logs in, none of the registry settings that that were imported into the Default User's HKCU hive from cmdlines.txt will take effect in the logged-in user's profile. Furthermore, you will be unable to load the Default User's registry hive (ntuser.dat file) in RegEdit.exe. The key will be created (as described above), but no subkeys or values will appear under it. It seems like the NTUser.dat file is locked or corrupt. STEPS TO RECREATE THE ISSUE: Integrate a factory Windows XP CD with Service Pack 3 and the KB960680-v2 windows update, and no other software installations of any kind. As the only other customization, from cmdlines.txt add a script or entry that will import a .reg file that customizes a simple application, such as changing the Font used in Notepad from the default of Lucida Console to Courier New. The required .reg files entries are shown below. [HKEY_CURRENT_USER\Software\Microsoft\Notepad] "lfFaceName"="Courier New"Windows Registry Editor Version 5.00 Install the integrated Windows CD. Let Windows Setup complete and login as the local Administrative user. Run Notepad.exe from Start Menu - Run. Inspect the Font used in Notepad.exe. ISSUE: The Notepad font should be the same as set inside the .reg file imported during Windows Setup from cmdlines.txt. It is not. Attempt to load the Default User HKCU hive in RegEdit.exe. ISSUE: The HKEY_USERS\DefUser subkey appears, but with no subkeys or registry settings listed under it. I should note I'm installing Windows XP using English-us locale. Also, I have not yet attempted to delete the registry key discussed in the Known issue for this update section of the KB article (link below) from the Default User profile during T-12. KB960680: An update is available to update the Slovak koruna currency symbol (Sk) to the Euro currency symbol (€) and to update the Turkish currency symbol from Yeni Türk Lirası (YTL) to Türk Lirası (TL) Q: Has anyone else even seen this issue? I'm thinking if deleting the key doesn't work, just to skip installing the update and hiding it in Microsoft Update. Execute RegEdit.exe from Start Menu - Run. Select the HKEY_USERS hive. From the File menu, select Load Hive. Enter the path C:\Documents And Settings\Default Users\ntuser.dat, and Click the OK button. When prompted, for a Key Name, type DefUser and click the OK button. You should now be able to now inspect (or change) registry settings under HKEY_USERS\DefUser key, which is the Default User's HKCU hive.

@Minkus Great article! This really sheds light on an issue that many of us have struggled with for a long time. I'll bet that there are other Microsoft installation packages, which are similarly affected by the absence of certain key profile folders at T-13. Thanks for taking the time to share your experience and results with everyone. -DS

Also, added to first post

@hipo_loco Thanks for your contribution! I updated the MSDBuild.exe version and release date and added it to the Guide in the 1st post. @Everyone Guide and MSDBuild updated to v5.3 Please read the Version History in the first post for more information. B) -DS [RANT]It figures that Microsoft would radically change how a key Windows Update is packaged and then release it almost immediately after I published the last version of MSDBuild up here on MFSN.org. [/RANT]

A new SSIBuild version (and SysinternalsSuite.zip) is out, go get it. B) Sysinternals Suite Installer Builder Version: 2.3 Sysinternals Suite Current Build Date: 2009-03-17 SysinternalsSuite.zip Changes: New VMMap.chm Help File Added! Executable Program Version Date ------------------------------------------------------ ProcMon.exe Process Monitor v2.4 2009-03-16 TCPVCon.exe TCPVCon v2.54 2009-03-16 TCPView.exe TCPView v2.54 2009-03-16 VMMap.exe VMMap v1.2 2009-03-16 VMMap.chm VMMap Help NA 2009-03-01 Required End User Action: Read Version History in second post. Re-download SysinternalsSuite.ulz from first post. Using WUD, re-download SysinternalsSuite.zip and SSIBuild.exe. Execute SSIBuild.exe to recreate SysinternalsSuite.exe.

Read GUIDE: Download Everything Microsoft, which stickied at the top of this forum (link is also in my signature below). Pay close attention to "Datastore.edb" section. -DS B)

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

Currently, I'm not at a PC with all of the downloads at the moment to check the version. However, the download URL I provided for Windows Update Agent, both in the Guide and in MSDownload.ulz, is static and will always download the most recent version of WUA for you. Just re-download it to get the current version.

It's nice to hear that folks still find this project useful. I'm not sure why your ActiveX controls were listed as damaged (you are the only person to have ever reported such an issue). My recommendation would be to just slipstream SP3 into an XPCD, then integrate only the updates listed in my guide, and MSDownloads.exe. Then install on your PC and see the results. I'm assuming the line of the MSDBuild.cmd script I've isolated above is the one you believe is in-error. This line is not in-error and it is as it should be (i.e. as I designed it to be). At this point, the MSDBuild.cmd script executes a subroutine to extract WGAN; the subroutine is named: Extract KB905474 WGA Notifications in the log file. And this subroutine has determined that the user did not download WGAN (bad user!), so there is no further work to do to extract WGAN (since the WGAN file does not exist). Now since there is no further work for it to do, the subroutine "completes" (as opposed to the subroutine aborting due to some critical error). In the case where the user does not download WGAN, the Extract KB905474 WGA Notifications subroutine "completes", by logging a warning to the user in the log file (and by sending a beep to the PC speaker), this is handled by the line above which ends in "skipping...". But the MSDBuild.cmd script keeps marching on (not downloading WGAN is not a show-stopper). That line does not communicate if the WGAN file was actually extracted or not, rather it communicates that MSDBuild.cmd has progressed to the end of the Extract KB905474 WGA Notifications subroutine. This is what the Goto :EOF line afterward does--goes to the end of the subroutine. If you read the .log file you will see I give each subroutine a header and a complete line at the end. Warnings will never stop the script from continuing, only errors do.

A new SSIBuild version (and SysinternalsSuite.zip) is out, go get it. B) Sysinternals Suite Installer Builder Version: 2.2 Sysinternals Suite Current Build Date: 2009-02-26 SysinternalsSuite.zip Changes: New Utility Added! Executable Program Version Date ------------------------------------------------------ VMMap.exe VMMap v1.0 2009-02-19 Required End User Action: Read Version History in second post. Re-download SysinternalsSuite.ulz from first post. Using WUD, re-download SysinternalsSuite.zip and SSIBuild.exe. Execute SSIBuild.exe to recreate SysinternalsSuite.exe.

Okay I released v2.1 yesterday, but I forgot to post a note so subscribers would get notified. (v2.1 is out, go get it) -DS

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

You are still re-inventing the wheel. I've already done all this and posted it as a guide in this forum. It's been up for well over a year now. Click the link in my signature.

Thanks for the issue report (and your patience). When I made changes to the script this last version, I did something which lost support for folder paths containing spaces. This issue has already affected another project I maintain in the same way, since they both share the same 7-Zip build code. For now, just download (or move) everything to a folder path without spaces and you should be fine. When you see SSIBuild v2.1 posted, it will allow folder paths with spaces once again. Somebody didn't test enough I guess... -DS

Apologies - i did miss that, have been working on some stuff for 36 hours straight... the old grey matter is getting tied. One suggestion for stopping the prompt is to use 7zip to extract the files you want to use... example Start /Wait "Extract KB905474 Download" .\7za457\7za.exe /e "%%W" -o"%%~dpnW" legitcheckcontrol.dll I get that operating on little sleep thing! There are two reasons I extract WGAN. To acquire LegitCheckControl.dll for comparision. To extract the payload file (which supports integration and slipstreaming) from the external shrinkwrap wrapper (which does not) and discard the external shrinkwrap wrapper. As you noted earlier it is only on a second (or later) MSDBuild execution that you see the dialog. But I think I have an idea how to get around this now. When MSDBuild first extracts the WGAN Payload, I'll have it set a variable inside SFX-MSD.ini (that did not exist there on the first execution), then on subsequent executions that variable will tell MSDBuild not to skip extracting WGAN.

Another Note. Say WUD is installed, and you previously downloaded my old update list (v4.5). And say you download the new update list (v5.0) while WUD is running. Then you must either refresh or restart WUD before you can actually use the updated list. Just click the green arrow refresh button after downloading the new list.