DarkShadows

Issue Log This is a list of technical issues I am currently working or have resolved. I could use some help with the open issues. If you have technical value to add, please post to the MSFN.org thread, rather than sending me private messages--I want to encourage other MSFN.org members to participate. The more eyes on an issue, the more air-tight the resolution. Thanks! 00.Meta Data (Look out for errors) I manually maintain a Sysinternals Suite.xls file that lists known meta-data for each Sysinternals Suite utility, such as: File name Proper name (when the utility is run). Current version (Modified Date Stamp on the file itself). Date last updated (Modified Date or as posted on TechNet). Type (Shell, Console, Help, File, NT4). TechNet web page URL .aspx TechNet web page URL .mspx Which Console utilities have help screens ("exe" or "-?"). Which Shell utilities have help files (.hlp/.chm file name). Which utilities have no help (Help column = "None"). Which utilities will run on a given Windows version (not yet added). Which utilities fall into each category as posted on TechNet: File And Disk Utilities Networking Utilities Process Utilities PsTools Security Utilities System Information Miscellaneous Utilities [*] Which utilities require elevated UAC privileges (not yet added). [*] Description of each file (used in Start Menu shortcut InfoTip). I execute an unpublished .cmd script that parses a text version of my Excel spreadsheet to programmatically create the InstSSI.inf file used by the installer. The meta-data constantly changes going forward, as Mark Russinovich constantly updates his utilities to better support newer Windows Versions (Mark recently added two new utilities). I try to keep this Excel spreadsheet accurate and up-to-date, so I encourage everyone to be watchful for any mistakes in the Start Menu shortcuts. NOTE: This issue will always remain open. 01. List of small known minor errors and omissions. I wanted some kind of version to display in Control Panel, so I'm using the Modified date of the most recent utility plus one day. DiskMNT.exe and DiskMNT.hlp are installed but no shortcuts are added. They are intentionally skipped. 02. You can have your installer pre-accept the EULA for each utility. The installer builder will allow you to pre-accept the EULA when you build your installer. However, this will only apply to the current user. Accepting the EULA for any Sysinternals utility is a per-user setting (HKCU). So if the suite is installed on a previously installed Windows PC, only the currently logged in user will benefit from this setting. But if the installer were run from Windows XP Setup at T-13, when the Default User profile is the current user, the setting will apply to all users who log into the PC afterward. 04:00 AM 11/21/2008 As of v1.5, I changed the EULA shortcut in the main Sysinternals Suite group, which now launches an HTML application that displays EULA.txt from Sysinternals and permits the currently logged in user to accept (or decline) the EULA for all Sysinternals Suite utilities at once. 03. Your installer can register the ShellRunAs shell context menu entries. The installer builder will allow you to register the ShellRunAs shell context menu entries. SFX-SSI.ini contains two parameters that govern the registration of the shell extensions. (The default action will not register either shell extension.) Uninstall.cmd will always unregister both shell extensions, since they are being uninstalled. Most Sysinternals utilities pop up a EULA dialog at first execution; the ShellRunas.exe /quiet parameter does not suppress this. While the ShellRunas.exe shell extensions are being registered, the EULA is temporarily accepted. After shell extension registration completes, the EULA registry setting is then set according to the AcceptEULA value in SFX-SSI.ini. 04. FYI, you may receive this Windows XP Process Monitor Warning: The version of Dbghelp.dll configured does not support the Microsoft Symbol Server. Please download and install the Microsoft Debugging Tools for Windows to get a version that does.The warning dialog has the following link: http://www.microsoft.com/whdc/devtools/deb...ng/default.mspx 05. Utilities with known issues on Windows Vista. PageDefrag - Program runs, but it doesn't work on Vista. I really hope Mark updates this utility for Vista. FileMon - Advises to use Process Monitor instead. RegMon - Advises to use Process Monitor instead. Some Sysinternals utilities utilize older 32-bit .hlp files, which require WinHlp32.exe. Microsoft deprecated this help program starting with Windows Vista. However, Microsoft published an update package to install the missing software. You can read more about it here: KB917607. 06. Windows Vista Physmem.exe Error: Physmem v1.0: physical memory viewer By Mark Russinovich Sysinternals - http://www.sysinternals.com Could not open \device\physicalmemory: Access is denied. I received this error message while running Windows Vista Ultimate with UAC disabled, and logged in as an Administrator. Q1: Can anyone else confirm this? Q2: Any ideas? 07. Phd.dll In the past, I encountered a more recent version of phd.dll on one PC, than the version included in the SysinternalsSuite.zip downloaded at that time. 08:46 PM 10/11/2008 I just scanned a virgin Vista install on VPC and found no phd.dll file. 06:58 AM 10/21/2008 I just scanned a virgin XP install on VPC and found no phd.dll file. 07:26 AM 10/22/2008 I just compared the Modified date and time stamp, file size, and file version of phd.dll in the last two version of the SysinternalsSuite.zip download. The phd.dll in the most recent SysinternalsSuite.zip version has a more recent Modified date and time stamp and a larger file size. Curiously, both files display the same file version (v5.0.2195.1600). Q1: Perhaps phd.dll is installed with some other Microsoft software? Q2: Has anyone else found another version of phd.dll? Q3: If so, do you know where you got the newer phd.dll from? Q4: I wonder if this issue can be closed or not? 08. Read unexpanded system %PATH% Using a Windows NT command script (.cmd), I need to read the system path into a environmental variable, without expanding any environmental variables used by folder paths that already exist in the system path. RESOLVED: See Issue 10. 09. Add folder to system %PATH% Using a Windows NT command script (.cmd), I Need to add Sysinternals Suite program folder path to the system path, (HKLM Path Environmental Variable registry value), in a way that: Uses a Windows NT command script (.cmd). Uses %ProgramFiles% in the Sysinternals Suite program folder path. Only adds the Sysinternals Suite program folder path to the system path, if it is not already part of the system path (either as a discrete folder path, or one that uses %ProgramFiles%). RESOLVED: See Issue 10. 10. Remove folder from system %PATH% Using a Windows NT command script (.cmd), I Need to remove Sysinternals Suite program folder path from the system path, (HKLM Path Environmental Variable registry value), in a way that: Uses a Windows NT command script (.cmd). Uses %ProgramFiles% in the Sysinternals Suite program folder path. Removes the Sysinternals Suite program folder path from the system path, if it has been added either as a discrete folder path, or one that uses %ProgramFiles%. RESOLVED: I developed :SysPath, a label function for NT command scripts that can add or remove a folder path to the system path. Currently, :SysPath supports Windows XP Pro and Windows Vista Ultimate, but it still needs to be tested on other Windows versions and possible modification. 11. Is the HKLM Environmental Variable: Path type REG_SZ or REG_EXPAND_SZ (when Windows 2000/XP/2003/2005/Vista/2008 is first installed)? I'm fairly certain they will all be Type REG_EXPAND_SZ, but I would like concrete confirmation. Operating System Data Type of HKLM %PATH% -------------------------------------------------------------- Windows 2000 ........................ ? Windows XP Pro ...................... REG_EXPAND_SZ Windows Server 2003 ................. ? Windows Media Center Edition 2005 ... ? Windows Server 2008 ................. ? Windows Vista Ultimate .............. REG_EXPAND_SZ 12. I need one beta tester for each Windows version or edition below: Windows 2000. Windows Server 2003 (32-bit only). Windows Media Center 2005. Windows Server 2008 (32-bit only). Windows XP Home Edition. Windows Vista Home Basic Edition (32-bit). Windows Vista Home Premium Edition (32-bit). To any interested Beta Tester: When you run your installer on an untested Windows version, the script will attempt to: Capture your Windows Version using the Ver command. Capture your Windows Product Name using Reg.exe. Capture your Windows Product Current Version using Reg.exe. Capture your %Path% environmental variable using Reg.exe. Open the text file with all the captured results in Notepad. IMPORTANT: It is imperative that you DO NOT modify the .txt file in any way. just save the file and post it to the MSFN.org thread as an attachment. What I'm after in these tests is the range of responses that each version and edition of Windows will yield. For example, Reg.exe under Windows XP pro returns Reg.exe output that requires my script to skip 4 lines, whereas the same command under Vista Ultimate returns Reg.exe output that requires my script to skip only 2 lines. Also, I want to ensure that Reg.exe is included in each version of Windows that the Sysinternals Suite Installer will support, since I will be using it to modify the System Path. I also want a verified collection of Ver output strings to use in my .cmd scripts (not just for this project). Before anyone starts making a boatload of suggestions, yes, I am aware that there are other ways to gather this information. However, I'm not at all interested in them. The Sysinternals Suite Installer script, and the uninstaller script will be using these techniques.

Version History: v2.7 - 2009-11-10 Current Version Updated InstSSI.inf, removed NewSID.exe installation. [*] v2.6 - 2009-09-16 Added support for Directory Opus running from USB. Updated InstSSI.inf, removed RegMon installation. Updated InstSSI.inf, removed FileMon installation. Audited the different utility categories. [*] v2.5 - 2009-08-23 Updated InstSSI.inf to install ProcDump. Updated InstSSI.inf, removed DiskMNT installation. Updated InstSSI.inf, removed Physmem installation. Updated InstSSI.inf, removed RegHide installation. [*] v2.3 - 2009-03-24 Updated InstSSI.inf script to install shortcut for VMMap help file. Updated SSIBuild.cmd to open .log file with focus, even on Vista+. SSIBuild now uses 7-Zip v4.65. [*] v2.2 - 2009-02-26 Updated InstSSI.inf script to install the newly-added VMMap utility. [*] v2.1 - 2009-02-20 Fixed a reported bug where SSIBuild no longer supported a download folder path containing spaces in name. The following characters are still not supported in folder names: "<, >, (, ), %, ^, |, *, \". [*] v2.0 - 2009-02-16 Updated: Online Guide and Readme.txt, and Sysinternals.ulz. Fixed a reported issue by recoding the Windows version check inside SFX-SSI.cmd to find strings: " 5.1", " 6.0", etc. (note preceding space), instead of strings like: "Version 5.1", "Version 6.0", etc. Apparently, Microsoft changes the word "Version" in some language variants of Windows XP, which was "Versi¢n 5.1" in Spanish. Hopefully, this resolves all issues with non-English languages. Hereafter, SSIBuild will always version the SysinsternalsSuite.exe installer by using an assumed Build Date for the Sysinternals Suite. SSIBuild will find the Date Modified stamp of the most recent file inside the SysinternalsSuite.zip download and assume the Build Date of the suite is one day later. I will now only update SSIBuild when new files are added to the suite, or when older files are deprecated and removed from the suite. Since the SysinternalsSuite.zip download URL is static, the WUD entry will no longer reflect a version (Build Date). NOTE: Always redownload SysinternalsSuite.zip and SSIBuild.exe, before creating your installer to ensure you have the most recent version of all the utilities! [*] v1.8 - 2008-12-23 Updated Sysinternals Suite Version to 2008-12-19. Updated: Online Guide and Readme.txt, and Sysinternals.ulz. [*] v1.7 - 2008-12-17 Updated Sysinternals Suite Version to 2008-12-10. Added detailed Version History. Updated: Online Guide and Readme.txt, and Sysinternals.ulz. [*] v1.6 - 2008-12-08 Fixed bug in SSIBuild.cmd where it was checking Windows version with a case-sensitive Find command; script would fall back to :BetaCode and report an unsupported Windows version. This affected French Windows XP Pro SKUs (and maybe others). NOTE: I'm still waiting for end-user to confirm the issue resolution. [*] v1.5 - 2008-11-21 Updated Sysinternals Suite version (build date) to 2008-11-19. Added HTML application (AcceptEULA.hta and AcceptEULA.inf), which allows the current user to read and accept EULA for all Sysinternals Suite utilities at once. Accepting the EULA can still be pre-set in the installer, but it only applies to the currently logged in user (unless installed from unattended Windows XP setup at T-12 or T-13). Fixed one minor bug in the uninstaller, where the user could get prompted for the EULA, when unregistering shell extensions. Updated: Online Guide and Readme.txt, and Sysinternals.ulz. [*] v1.4 - 2008-10-30 Updated Sysinternals Suite version (build date) to 2008-10-30. Online Guide, Readme.txt, and Sysinternals.ulz were not updated. [*] v1.3 - 2008-10-26 First version published on MSFN.org forums (at least I think it was). Added :BetaCode to SFX-SSI.cmd, which will hopefully inspire users to report any unsupported Windows versions or SKUs. Updated SFX-SSI.ini to register ShellRunAs and ShellRunAsNetOnly. [*] v1.2 - 2008-10-23 Updated SFX-SSI.ini to pre-accept EULA during installation. Updated InstSSI5.inf.ini to set accept EULA registry values during installation. However, since these are HKCU settings, they only affect the currently logged-in user. Recommend T-12, T-13 install. Settled on using the SysinternalsSuite.zip Build Date for version inside Control Panel - Add/Remove Programs listing. [*] v1.1 - 2008-10-21 Added SFX-SSI.ini, which allows users to customize program groups. [*] v1.0 - 2008-10-11 First version, had several unhandled known issues and a few bugs. Created unpublished CreateSSIBuild.cmd which automatically builds new versions of InstSSI5.inf on-the-fly and packages SSIBuild.exe.

SSIBuild (Sysinternals Suite Installer Builder) Version: 2.7 Last Update: 05:00 PM 11/10/2009 (GMT-5 +1 during DST) Copyright © 2009 Kenneth R. Alcock, all rights reserved. The Sysinternals Suite Installer Builder (SSIBuild) includes: All Sysinternals Suite Installer files (listed below) The .cmd file: SSIBuild.cmd The .txt file: ReadMe.txt The .ouc file: USBProgram.ouc The .dcf file: Sysinternals.dcf The Sysinternals Suite Installer includes: The .inf files: InstSSI.inf, AcceptEULA.inf The .hta file: AcceptEULA.hta The .cmd files: SFX-SSI.cmd, Uninstall.cmd The .ini files: SFX-SSI.ini The Sysinternals Suite of utilities was originally authored by Mark Russinovich and Bryce Cogswell of Sysinternals. The Sysinternals Suite is Copyright © 2000-2009 by Sysinternals, a wholly owned subsidiary of the Microsoft Corporation. Read the Eula.txt file included in the SysinternalsSuite.zip download from Microsoft TechNet for Sysinternals Suite licensing restrictions. A shortcut to this file is installed in the Windows Start Menu. Kenneth R. Alcock is not affiliated with or a representative of the Microsoft Corporation. Objective: To: build an installer package, named SysinternalsSuite.exe, for the popular Sysinternals Suite by Mark Russinovich and Bryce Cogswell. NOTE: Sysinternals is now subsidiary of the Microsoft Corporation. In a way that: Requires one to download the Sysinternals Suite directly from Microsoft. NOTE: WUD will download SysinternalsSuite.zip directly from Microsoft. Allows one to quickly create their own SysinternalsSuite.exe installer. NOTE: The Sysinternals Suite End User License Agreement (Eula.txt) expressly states that you may not: "publish the software for others to copy" or: "transfer the software or this agreement to any third party". Thus, redistributing the Microsoft SysinternalsSuite.zip download, or the SysinternalsSuite.exe installer created by using this guide, are both violations of the Sysinternals Suite EULA. This is why I am publishing tools to create your own installer. Automates as much of the process as is practical. Does not require an installation software suite--one only need download the free tools listed in this guide to create the installation package. Uses open-source-like techniques to create the installer and install all of the Sysinternals Suite utilities, which allows anyone with technical knowledge to see, report, and help trouble-shoot any issues. Ensures the resulting installer does the following: Installs all Sysinternals Suite utilities to this folder: %ProgramFiles%\Sysinternals Suite NOTE: The program folder may be changed in SFX-SSI.ini. Adds the program folder listed above to the system %PATH% variable. NOTE: A reboot is required before the new path will take effect. Creates shortcuts under the following Start Menu program groups: Start Menu\Programs\Sysinternals Suite Start Menu\Programs\Sysinternals Suite\File And Disk Utilities Start Menu\Programs\Sysinternals Suite\Networking Utilities Start Menu\Programs\Sysinternals Suite\Process Utilities Start Menu\Programs\Sysinternals Suite\PsTools Start Menu\Programs\Sysinternals Suite\Security Utilities Start Menu\Programs\Sysinternals Suite\System Information Start Menu\Programs\Sysinternals Suite\Miscellaneous Utilities NOTE: The group names may be changed in SFX-SSI.ini. [*] Creates an uninstaller entry in Control Panel - Add/Remove Programs . [*] Supports Windows 2000/XP/2003/Vista/2008/7 (32-bit versions only). NOTE: I have only tested the installer on Windows XP and Vista. However, this should also work on Windows 7. [*] Supports unattended installation. NOTE: So far, only Windows XP CD integration has been tested. So that: It becomes quick and easy to install the Sysinternals Suite. It becomes quick and easy to cleanly uninstall the Sysinternals Suite. Providing an installer and uninstaller for the Sysinternals Suite is legal, since you still download the Sysinternals Suite files directly from Microsoft and you create the installer package yourself. The installer is simple to integrate into an XPCD building process. The Automated Process: Here's how to create your own SysinternalsSuite.exe installer. Download SysinternalsSuite.zip from Sysinternals (Microsoft) to the Sysinternals Suite download folder. SysinternalsSuite.zip Download SSIBuild.exe from me to the Sysinternals Suite download folder. SSIBuild.exe Open the Sysinternals Suite download folder , and double-click on SSIBuild.exe (Sysinternals Suite Installer Builder), which will extract itself and run SSIBuild.cmd. NOTE: SSIBuild.exe and SSIBuild.cmd are discussed in detail later on. SSIBuild.cmd will prompt to delete the WORK files. Enter "N", if you wish to customize your installer. NOTE: When the SSIBuild.cmd script completes, SysinternalsSuite.exe will exist in the Sysinternals Suite download folder . OPTIONAL: OPTIONAL: You can customize certain aspects of your installer, including Start Menu Folder and Program Folder names. To customize your installer: Copy SFX-SSI.ini from: the WorkSSIB subfolder to: the Sysinternals Suite download folder . Edit your own customized SFX-SSI.ini and save it to: the Sysinternals Suite download folder . Re-execute either SSIBuild.cmd or SSIBuild.exe. SSIBuild.cmd will recreate SysinternalsSuite.exe, this time using your version of SFX-SSI.ini from the Sysinternals Suite download folder , which it will copy to the WorkSSIB subfolder (overwriting it). NOTE: SSIBuild.cmd never deletes your version of SFX-SSI.ini from the Sysinternals Suite download folder . NOTE: To reset SFX-SSI.ini back to the default values, simply delete your version from the Sysinternals Suite download folder and restart the process from step 3 . NOTE: You are done at this point. The remaining sections below are just the technical details of the entire process, and the issue log. Using Windows Update Downloader Windows Update Downloader (WUD) by Jean-Sebastien Carle (JCarle on MSFN.org) is a great tool for keeping up-to-date with all of your Windows Updates and Microsoft Technologies used to build a stable Windows system. I provide a WUD update list for this project named SysinternalsSuite-x86-ENU.ulz, which allows you to (re) download everything within WUD. After installing WUD on your engineering system, just click the download link in the MSFN.org guide to download and import the update list directly into WUD. SysinternalsSuite_x86_ENU.ulz Check for Updates Often Mark Russinovich tends to update the Sysinternals Suite regularly; however, the download link for the suite is static and does not change. Whenever a new version is released, you should re-download the SysinternalsSuite.zip and re-execute SSIBuild.exe. (In WUD, just select the Sysinternals Suite and re-download it.) For the most part, the process to create your own installer should remain the same from version-to-version. However, Mark occassionally adds new utilities or retires old and obsolete ones. SSIBuild only supports the most current version of Sysinternals Suite. Subscribe to the MSFN.org discussion thread to be notified of any new releases of SSIBuild. Whenever I update this guide and release a new SSIBuild version, always do the following: Read the Version History, along with the related detailed sections for any changes I have made to the process. Re-download both SysinteralsSuite.zip and SSIBuild.exe. If you are using WUD, click on the SysinternalsSuite-x86-ENU.ulz from. the MSFN.org guide. The update list will automatically import itself into WUD (overwriting the old list). Then open WUD and select the entire Sysinternals Suite category and re-download all related files at once. NOTE: I have changed the list file name from SysinternalsSuite.ulz to to SysinternalsSuite-x86-ENU.ulz, which is consistent with the meta data internal to the WUD list. If you happen to see two lists in WUD, just delete the older list. Recreate SysinternalsSuite.exe by double-clicking on SSIBuild.exe. SSIBuild.exe (Sysinternals Suite Installer Builder) SSIBuild.exe (Sysinternals Suite Installer Builder) is a WinRar SFX I developed to automate building SysinternalsSuite.exe (see next section) from the SysinternalsSuite.zip downloaded from the www.sysinternals.com (Microsoft TechNet). SSIBuild.exe will do the following: Unpack the following files directly to the download folder: SSIBuild.cmd - Sysinternals Suite Installer Builder script. Readme.txt - This content you are reading now in printable format. Sysinternals.dcf - Sysinternals menu for Directory Opus running from USB. USBProgram.ouc - USBProgram user command for Directory Opus. [*] Unpack all 7-Zip command line files to the 7za465 subfolder . 7za.exe 7-Zip.chm 7-Zip Command Line License.txt 7-Zip Command Line ReadMe.txt 7-Zip Extra History.txt 7-Zip Extra License.txt 7-Zip Extra ReadMe.txt 7-Zip For Installers ReadMe.txt 7zS.sfx Copying.txt NOTE: SSIBuild.cmd also writes temporary VBScript (.vbs) files here. [*] Unpack all SSIBuild.exe installation files to the WorkSSIB subfolder . AcceptEULA.hta - HTML app that lets user read and accept EULA globally. AcceptEULA.inf - The .inf file called by AcceptEULA.hta. hidec.exe - Tiny executable that hides the command prompt. InstSSI.inf - Installer .inf file (this does most of the work). SFX-SSI.cmd - Sets system path and launches InstSSI.inf. SFX-SSI.ini - Governs a few installer parameters. Uninstall.cmd - Unsets system path and launches Uninstall.inf. Urls\*.url - Several shortcuts to the Microsoft TechNet web page for each Sysinternals utility or utility category. [*] If SFX-SSI.ini exists in the download folder, copy it to WorkSSIB , overwriting any existing destination copy. NOTE: This would be your own customized SFX-SSI.ini file. [*] Extract SysinternalsSuite.zip to WorkSSIB\SysinternalsSuite . [*] Version the SysinsternalsSuite.exe installer by using an assumed Build Date for the Sysinternals Suite. SSIBuild will find the Date Modified stamp of the most recent file extracted from the SysinternalsSuite.zip download and assume the Build Date of the suite is one day later. NOTE: SSIBuild updates InstSSI.inf, which will not work correctly, until the Version string assignment is appended to the end of the file. [*] Create SysinternalsSuite.exe in the download folder. [*] Prompt to delete from the Syinternals Suite download folder : 7za465 subfolder . WorkSSIB subfolder . Readme.txt SSIBuild.cmd [*] Open the SSIBuild.log file in Notepad. SysinternalsSuite.exe (Sysinternals Suite Installer) SysinternalsSuite.exe (Sysinternals Suite Installer) is a 7-Zip SFX that I developed to properly install the Sysinternals Suite. (By proper, I mean with a Start Menu group, shortcuts, and a Control Panel uninstaller entry.) SysinternalsSuite.exe is the final output of running SSIBuild.exe (see previous section above). SysinternalsSuite.exe does the following: Extracts all its files to a subfolder under %TEMP% . Executes SFX-SSI.cmd, via a hidden command console, which: Adds the %ProgramFiles%\Sysinternals Suite folder to the system %PATH%. NOTE: A reboot is required before the new path will take effect. Determines which version of Windows is running. Modifies the installation files based on you SFX-SSI.ini settings. Launches the InstSSI*.inf file for the Windows version, which: Copies all Sysinternals Suite files to the program folder: %ProgramFiles%\Sysinternals Suite NOTE: The program folder can be changed in SFX-SSI.ini. Copies the InstSSI.inf to the program folder as Uninstall.inf. Copies the Uninstall.cmd script to the program folder. Creates a Sysinternals Suite uninstall entry in Control Panel. Creates the following program group and subgroups: | +--File And Disk Utilities | +--Networking Utilities | +--Process Utilities | +--PsTools | +--Security Utilities | +--System Information | \--Miscellaneous Utilities Start Menu\Programs\Sysinternals Suite The Sysinternals web site divides the utilities into the above categories; some utilities fit into more than one category. The Start Menu\Programs group contains a subgroup for each utility category. Category subgroups each contain the following items: A shortcut for each utility in that category. NOTE: Command line utilities are run via Cmd.exe /K . If the command has a help screen, the shortcut will display it rather than just running the command itself. A shortcut to each Shell utility's help file (if one exists). A Microsoft TechNet Reference subgroup with: A shortcut to the utility category's TechNet web page. A Shortcut to each utility's individual TechNet web page. Deletes its subfolder under %TEMP% after installation completes. Directory Opus USB Files: In my quite-biased opinion, Directory Opus by GPSoftware is simply the best file manager available for the Windows operating system. Directory Opus is not freeware, but compared against the time it saves me every day, it's well worth the price of my license. When purchased with a USB license, Directory Opus runs from any ordinary USB flash drive or U3 drive. GPSoftware offers a free, fully-functioning, 60-day trial license, so check out Directory Opus at the links below. GPSoftware Homepage Download the software installer and PDF Manual from this web site. Be sure to complete the online form to receive a free, 60-day license certificate by email. Otherwise, the stock software certificate may expire. Introduction To Directory Opus Here's a link to an excellent Directory Opus online introductory tutorial. Directory Opus Resource Center The Directory Opus Resource Center is a very active user-to-user forum with: FAQs; tutorials; plug-ins; themes; as well as customized toolbars, buttons, menus, and user commands. (I'm user KenAlcock on that forum.) Personally, I use an ordinary USB flash drive running the PortableApps.com menu and Directory Opus. I like the PortableApps.com menu, but it's tedious to manually add all the Sysinternals programs to it. On the other hand, Directory Opus is the most customizable software package to be found. So my solution was to create an Opus user command that correctly launches programs from a USB flash drive and a Sysinternals menu for Directory Opus. SSIBuild now includes both of these as exported files for use with Directory Opus v9.x and later. Sysinternals.dcf - Sysinternals Menu for Directory Opus (running from USB) In Directory Opus, menus are just a type of button containing other buttons. And all buttons can be exported as Directory Opus Command files (.dcf). Sysinternals.dcf contains an exported Sysinternals Suite menu that contains all the same submenus and shortcuts (buttons) installed by the Sysinternals Suite Installer (SysinternalsSuite.exe). Buttons that run each Sysinternals Suite command use the Directory Opus USBProgram user command (below) to run the programs correctly from a USB flash drive. USBProgram.ouc - USBProgram User Command for Directory Opus Directory Opus user commands are reusable commands that can accept a command parameter template and can be invoked from command lines stored in: a menu item, a toolbar button, a hotkey sequence, or a File Type context menu item within Directory Opus. The Directory Opus user commands themselves can be comprised of: internal Directory Opus commands, external commands (3rd-party or operating system programs), or even scripts. The USBProgram.ouc file is an exported Directory Opus user command I developed named USBProgram. It's designed to correctly launch USB programs from within Directory Opus running on a USB flash drive, where the USB drive could have any drive letter. USBProgram can launch command-line utilities inside a new Cmd.exe console (which remains open after execution), after appending the program's folder path to the %Path% environmental variable for the Cmd.exe console. This allows the user to type regular syntax for the command-line utility, without having to specify a completely qualified file path for it. NOTE: I provide support for these Directory Opus related files, and document them more extensively, in the Directory Opus Resource Center under the Buttons and Toolbars forum. Please direct all related questions there.

In the order listed in svcpack.inf (which as we have pointed out is not the order in which you integrate them).

This is my understanding: Blank Cube Individal Downloads - Downloading the listed entry has never been attempted (in a category that has never been attempted). Category Level - Downloading all entries listed in the category has never been attempted (or the category contains no entries). [*] Green Cube Individal Downloads - A file exists with the same name listed for its entry in the folder WUD expects it to be in. Category Level - All files exist with the same names as listed for their entries in the folder(s) WUD expects them to be in. [*] Yellow Cube Individal Downloads - A file does not exist with the same name as listed for its entry in the folder WUD expects it to be in. Category Level - Some files do not exist with the same names as listed for their entries in the folder(s) WUD expects them to be in. I have never seen a red cube yet.

When you use the /INTEGRATE switch to integrate an update, the svcpack.inf resulting entries will most always look like: "KBnnnnnn.exe /q /n /z". However, there are many other switches available to such updates (we call these Type I updates). A few times, using the /INTEGRATE switch will add some of these. Personally, I just use the /INTEGRATE switch, and the resulting switches for nearly all svcpack.inf entries. I have noticed that the order listed in svcpack.inf is usually the reverse order in which the updates were integrated. Generally, it does not matter to each update in which order they are installed. However, sometimes it does matter from a system-state perspective. See this thread for more information. Although most updates now include its logic, adding QChain.exe to your SVCPACK folder and an entry to svcpack.inf is still a good idea. Not at all The guide provides links to two repackaged, silent, switchless, installers. Someone created those packages. My understanding is that the .cat files are digitally signed by Microsoft and provide Windows with new knowledge of authorized system (and device driver) files. Basically, they tell Windows: "these new files are safe and authorized to use as part of the operating system".

@Tomcat76 When you next update SNM.cmd, please consider making the following changes. When deleting any temp or working folder, either pre-check for the folder's existence with "IF EXIST" (which in most cases you do just that), or prepend all RD commands with ">Nul 2>&1 ". (There is also no harm in doing both approaches together.) As I discussed in earlier posts, one such line gives a little cause for concern (until one understands what the error message actually pertains to). I believe strel is using a modified copy of the SNM.cmd script, because it is actually line 438 in the unmodified copy of SNM.cmd I used. Change Line 438 From This: RD/Q/S "!DNF3DIR!DNF30\XPS\amd64" Change Line 438 To This: >NUL 2>&1 RD/Q/S "!DNF3DIR!DNF30\XPS\amd64" The modified line will redirect all regular command output from the console to the Nul (black hole) device using "> Nul". It will also redirect any error output (handle 2) to the same location as regular output (handle 1) using "2>&1". This modification allows the line to execute if the script does find the folder to remove, and it allows the script to work without displaying errors if the folder is not found. Ensure all installations launched from inside any DNF*.exe package forcefully suppress rebooting. As I discussed in my earlier post, using the current (unmodified) version of SNM.cmd along with the .Net Framework v3.5 SP1 Full Redistributable download, I successfully created and installed the resulting DNF*.exe packages. I installed the packages on both Virtual PC 2007 and on a physical PC. I just recently updated the XPCD for my physical PC, but I made no changes to my RunOnceEx.cmd script, and I used the same DNF*.exe packages tested earlier. This time, when the XPCD installation completed, I noticed that Microsoft .Net Framework 3.0 Service Pack 2 had not been installed. So I rebuilt my XPCD from the ground up again by-the-numbers, reset my PC, and closely monitored the XPCD installation. I noticed the dialogs below during RunOnceEx. Above, we see the Software Update Installation Wizard for one update belonging to the DNF30.exe package. (It is either WIC or XPS.) As this update's install completes, it prompts the user to prevent a system reboot. If one does not check the Do not restart option before the countdown completes, Windows will reboot in the middle of installating the DNF30.exe package. This ultimately results in Microsoft .Net Framework 3.0 Service Pack 2 not being installed. (Interesting sidebar: Microsoft does not post any information whatsoever on 954550 or KB954550, much less KB954550-V5. Even a Google search will find no information about this update number.) As seen above, after checking the Do not restart option before the update forces the system to reboot, will allow the DNF30.exe package installation to proceed as expected. This ultimately results in Microsoft .Net Framework 3.0 Service Pack 2 being installed correctly, although not in an unattended manner. Just to be thorough, I installed the XPCD for my physcial PC on VirtualPC 2007 and I closely monitored its progress. I saw the same dialog flash for about a half a second, but I noticed that the Do not restart option was checked. I'm using exactly the same bits to install, so it is beyond me what is so different about my physical Test PC. Perhaps one my hardware drivers is installing something that DNF30.exe needs to overwrite? To get to the bottom of this issue, I used 7-Zip to extract DNF30.exe, and inspected the INSTALL.CMD script, which in-turn pointed me to the lines of code below from SNM.cmd that do not use the /norestart parameter. Change Line 430 From This: ECHO>>INSTALL3.CMD START/WAIT DNF30\WIC\update\update.exe /passive Change Line 430 To This: ECHO>>INSTALL3.CMD START/WAIT DNF30\WIC\update\update.exe /passive /norestart Change Line 439 From This: ECHO>>INSTALL3.CMD START/WAIT DNF30\XPS\update\update.exe /passive Change Line 439 To This: ECHO>>INSTALL3.CMD START/WAIT DNF30\XPS\update\update.exe /passive /norestart I edited my own copy of SNM.cmd thusly, recreated all four DNF*.exe packages, re-integrated my XPCD, and re-installed Windows on my physical PC. Everthing installed as expected. I also recommend the change below, though I did not test this one. Change Line 72 From This: ECHO>>INSTALL1.CMD START/WAIT MSISTUB DNF11\langpack.msi /passive Change Line 72 To This: ECHO>>INSTALL1.CMD START/WAIT MSISTUB DNF11\langpack.msi /passive /norestart So hopefully, you will add these changes in the next version. -DS

I have updated the Guide and downloads to v4.1. Read the Version History section in the first post and the related sections for details! B)

"The System could not find the file specified." Since the line in question is only removing a folder, it can be safely changed to this: >Nul 2>&1 RD /Q /S "!DNF3DIR!DNF30\XPS\amd64" The modified line will redirect all regular command output from the console to the Nul (black hole) device using "> Nul". It will also redirect any error output (handle 2) to the same location as regular output (handle 1) using "2>&1". This modification allows the line to execute if the script does find the folder to remove, and it allows the script to work without displaying errors if the folder is not found. B)

MSDownloads.exe should be installed from svcpack.inf or from cmdlines.txt. I have never used nLite, so I do not know anything about how it adds things to the XPCD source. I'm not sure if nLite uses direct slipstreaming (which this guide does not use), or integration (which this guide does use). The svcpack.inf method is an integration method and part of the Windows setup process provided by Microsoft. I believe most direct slipstreaming tools still end up adding some files to the XPCD\I386\SVCPACK folder and corresponding entries to svcpack.inf file anyway (usually .cat files for slipstreamed windows updates). I know for certain that you can install some things by direct slipstreaming and others by integration. I actually use WMP 11 Slipstreamer on my XPCD source. But it is usually best to do all of your slipstreaming first, then add your SVCPACK items afterward. Just make sure that you do not Slipstream and Integrate the same item--If you have already slipstreamed an item, there should be no need to Integrate it. I would guess (but I do not know) that nLite can handle most of the prerequisite items covered in this guide, since most support the /INTEGRATE switch. My guess would be that you would only need to add MSDownloads.exe (and perhaps Windows Update Agent) to SVCPack. Can someone else who uses my guide an nLite chime in here with confirmation?

I try to use only those techniques where I can review all the details about what is getting installed on the systems I'm building (since I'm the guy responsible for them). So, I try to stay away from "black box" solutions as much as possible. So I really appreciate Tomcat's work here, since it's easy to review the SNM.cmd script, and the resulting packages have always worked flawlessly for me. My questions above were more about using .Net Framework 3.5 SP1 full distributable as opposed to .Net Framework 3.5 full distributable (i.e. no SP) with SNM.cmd. I don't believe anyone had tested and verified that it would work. It's been so far, so good in my tests, but I wanted to see if others had similar experiences.

There is no need to trim SFX-MSD.cmd. As I documented in the 1st post, SFX-MSD.cmd will safely skip installing any missing Inst*.inf files. So if you don't want to install Office Update, simply delete the two files below from your WORK subfolder, then re-execute MSDBuild.cmd. InstOUIE.inf InstOGAV.inf

@Tomcat I don't know if you have tested this (or if you even recommend it), but I just tried the following steps below. Downloaded SNM.zip from 1st post in thread and extracted to my Work folder. For .Net Framework 1.1, downloaded the following to my Work folder: dotnetfx.exe NDP1.1sp1-KB867460-X86.exe NDP1.1sp1-KB928366-X86.exe [*] For all other .Net Frameworks, downloaded Microsoft .NET Framework 3.5 Service Pack 1 Full Redistributable Package to Work folder. [*] Skipped all language packs, since I speak English. [*] Left all SNM.ini settings at their default values. [*] Executed SNM.cmd. During SNM.cmd processing, I observed one item of concern. The Command Prompt displayed the error message: "The System could not find the file specified." [*] Installed DNF20.exe from svcpack.inf. [*] Installed DNF30.exe, DNF35.exe, and DNF11.exe from RunOnceEx (in that order). I observed no errors during or after the installation, and Microsoft Update finds no required updates for .Net Framework. EDIT: I should note that all items appear correctly installed in Control Panel. Q1: Has anyone else attempted something similar? If so, has it worked for you? Q2: Are the any concerns or issues with this approach?

Yes and No It does not matter from the perspective of the update software logic. As far as each individual update is concerned, they can be installed in any order. I still add QChain.exe to the end of my svcpack.inf file, since I install some older updates that are not part of any service pack. However, from the perspective of the effects on the system, the order can matter significantly. For example, I integrate all of the IE6 cumulative updates and patches, before I install IE7. Then I install the IE7 versions of the same knowledgebase articles. That way if a user uninstalls IE7, IE6 will still be as up-to-date as possible. There have also been some issues with things being installed in certain order from svcpack.inf. See GreenMachine's Complete SP3 SVCPACK.INF for more information.

@everyone Here, let me kick it up another notch ... BAM! B) I have updated the Guide and downloads to v4.0. Things just got a little simpler. Read the Version History section in the first post and the related sections for details! @strel Thanks for the heads up. Read the updated Windows Genuine Advantage Notifications section in the first post. If you could test everything in my guide on your retail/OEM license and let me know if it works for you? On the volume license I'm using, WGAN installs but I can't see any feedback when windows runs.

Guide updated to v3.2. Please read the Version History in the first post for more information. -DS

@strel Thanks for the heads up! B) I'm working on an update right now. @TranceEnergy (and anyone else using Windows XP 64-bit) I don't have Windows XP 64-bit to test with. So take whatever I say next as pure speculation and rely on your own testing to prove things. As I documented in this guide's Version History, I updated InstWGAV.inf as of v3.0 so that it properly registers LegitCheckControl.dll without requiring Windows Genuine Advantage Notifications. Windows Genuine Advantage Notifications is no longer a requirement for Windows XP 32-bit. What does his mean for Windows XP 64-bit? I really have no idea. I don't even know if XP 64-bit downloads the same .cab files, or how the ActiveX controls get registered on XP 64-bit. On Windows XP 32-bit, the ActiveX .dll files usually end up in %WinDir%\System32 (one ends up in %WinDir%). But I suspect this may be different on 64-bit. I also suspect that some registry settings will be different. But without the software to test on and rip apart, I really can't help you 64-bit folks much. If you know how to read registry settings in an .inf file, it should be pretty clear to look my Inst*.inf files (inside my MSDBuild.exe WinRar SFX) and compare the 32-bit registry settings I'm settings to the ones on your 64-bit OS. Who knows, maybe my .infs will work on XP 64-bit without modification? (I doubt it, but might be worth a try on a test PC). If you can use what I have posted to figure out an air-tight proces for Windows XP 64-bit, I will be happy to post a 64-bit download. But you 64-bit folks are going to have to do some home work on this and report back here. No one has ever told me if my guide even works on Windows XP 64-bit or not!

I just wanted to add purely user perspective about the URL I was trying to use. It was always my intention and understanding, that I would first have to log into the forum web site (saving my login information inside of a cookie), before trying to use WUD to download a number of files from that forum. As I stated above, the same technique worked in Internet Download Manager (even after the browser window was closed). But, if handling such a thing is bigger than a breadbox, then don't bother with it.

Hmmm...okay, it is more than likely a web site login issue. (I get a small file that is really an .html doc for login screen.) The strange thing is, I can paste the same url (without changing the ampersands) in Internet Download Manager and download the file just fine. But if I use the same .url in WUD (after changing the ampersands), it does not work; I get the smaller html (renamed as my target download).

This Tech Republic Article discusses the difficulties with using the ampersand in an XML file. I tried using "&" in place of "&". The good news is that WUD will not crash with such a .ul file. Also, using "&" in place of "&" works in the article="" attribute of the <UPDATE></UPDATE> tags. The bad news is that using "&" in place of "&" does not work as part of the <URL></URL> tags--WUD will not download a file linked with such a URL correctly. It seems WUD does not translate "&" back to a "&" when it navigates to the download URL.

I suspect that there may be a workaround for this. But i do not know what it is. I created my own .ul and .ulz files, which I use WUD to manage a number of downloads I utilize in my Windows XP and Vista installations. The files I use come from various sources, not just from Microsoft.com. Many websites use urls like the one shown below (which points directly to JCarle's post in the WUD > Bugs sticky thread): See the end of this message for details on invoking just-in-time (JIT) debugging instead of this dialog box. ************** Exception Text ************** System.Xml.XmlException: An error occurred while parsing EntityName. Line 100, position 118. at System.Xml.XmlTextReaderImpl.Throw(Exception e) at System.Xml.XmlTextReaderImpl.Throw(String res, String arg) at System.Xml.XmlTextReaderImpl.ParseEntityName() at System.Xml.XmlTextReaderImpl.ParseAttributeValueSlow(Int32 curPos, Char quoteChar, NodeData attr) at System.Xml.XmlTextReaderImpl.ParseAttributes() at System.Xml.XmlTextReaderImpl.ParseElement() at System.Xml.XmlTextReaderImpl.ParseElementContent() at System.Xml.XmlTextReaderImpl.Read() at System.Xml.XmlTextReader.Read() at System.Xml.XmlLoader.LoadNode(Boolean skipOverWhitespace) at System.Xml.XmlLoader.ReadCurrentNode(XmlDocument doc, XmlReader reader) at System.Xml.XmlDocument.ReadNode(XmlReader reader) at System.Data.DataSet.ReadXml(XmlReader reader, Boolean denyResolving) at System.Data.DataSet.ReadXml(String fileName) at WUD.UpdateListManager..ctor(String path) at WUD.formMain.refreshULs() at WUD.formMain.buttonRefreshULs_Click(Object sender, EventArgs e) at System.Windows.Forms.Control.OnClick(EventArgs e) at System.Windows.Forms.Button.OnClick(EventArgs e) at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent) at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks) at System.Windows.Forms.Control.WndProc(Message& m) at System.Windows.Forms.ButtonBase.WndProc(Message& m) at System.Windows.Forms.Button.WndProc(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) ************** Loaded Assemblies ************** mscorlib Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.1433 (REDBITS.050727-1400) CodeBase: file:///C:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll ---------------------------------------- WUD Assembly Version: 2.30.980.0 Win32 Version: 2.30.980.0 CodeBase: file:///C:/Program%20Files/Windows%20Updates%20Downloader/WUD.exe ---------------------------------------- System.Windows.Forms Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.1433 (REDBITS.050727-1400) CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll ---------------------------------------- System Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.1433 (REDBITS.050727-1400) CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll ---------------------------------------- System.Drawing Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.1433 (REDBITS.050727-1400) CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll ---------------------------------------- System.Data Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.1433 (REDBITS.050727-1400) CodeBase: file:///C:/WINDOWS/assembly/GAC_32/System.Data/2.0.0.0__b77a5c561934e089/System.Data.dll ---------------------------------------- System.Xml Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.1433 (REDBITS.050727-1400) CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll ---------------------------------------- System.Web Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.1433 (REDBITS.050727-1400) CodeBase: file:///C:/WINDOWS/assembly/GAC_32/System.Web/2.0.0.0__b03f5f7f11d50a3a/System.Web.dll ---------------------------------------- System.Configuration Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.1433 (REDBITS.050727-1400) CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Configuration/2.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll ---------------------------------------- ************** JIT Debugging ************** To enable just-in-time (JIT) debugging, the .config file for this application or computer (machine.config) must have the jitDebugging value set in the system.windows.forms section. The application must also be compiled with debugging enabled. For example: <configuration> <system.windows.forms jitDebugging="true" /> </configuration> When JIT debugging is enabled, any unhandled exception will be sent to the JIT debugger registered on the computer rather than be handled by this dialog box. Q: Is there some alternate way to enter an ampersand "&", into a .ul file where the URL will still work?

This page of the MSFN Unattended Windows XP Guide has a download link for QChain.exe.

The guide has been successfully tested on: Windows XP Pro Volume Windows XP Pro OEM Windows XP Pro Retail Upgrade Windows XP Home OEM (plus Dell and HP Royalty OEM licenses) Windows XP Home Retail Windows XP Home Retail Upgrade The base CDs are usually Gold, integrated with SP3. You are doing something wrong, you just need to figure out what you are doing wrong. The fact you do not get any Start Menu shortcuts tells me you are not doing one or more of the following, or not doing them correctly: Building MSDownloads.exe according to my guide. Copying MSDownloads.exe file to your XPCD\i386\SVCPACK folder. Adding the MSDownloads.exe entry to svcpack.inf correctly. Try doing the following (nothing more and nothing less): Skip making and including MSDownloads.exe and ensure that you can successfully integrate KB942288.exe, and KB898461.exe into your XPCD. After you install Windows with your XPCD, check that these two updates no longer appear in Windows/Microsoft Update. Once the above is working correctly, go back to your XPCD and try adding WindowsUpdateAgent.exe. Remember, you need to unpack the Microsoft download and repack it in order for it to install silently. Follow the Guide section on how to do this. Once the above is working correctly, go back to your XPCD and try adding MSDownloads.exe. Just create this file thusly (nothing more and nothing less): Download WinRar and install it to: %ProgramFiles%\WinRAR\WinRAR.exe (This path is important.) Download Windows Updates Downloader (WUD) by Jean-Sebastien Carle (JCarle on MSFN.org) and install it. Download MSDownloads.ulz (link in first post). This is an update list that should automatically import itself into WUD. In Windows Updates Downloader, check the MSDownloads category to force all related files (including my MSDBuild.exe) to be re-downloaded to your MSDownloads folder. NOTE: For now, do not include your own DataStore.edb file, instead let MSDBuild.exe use my own file, which is named DataStore.ed_. Open the MSDownloads folder, and double-click on MSDBuild.exe to recreate MSDownloads.exe. Your resulting file should be: ----------------------------------------------------------------------------------------------- MSDownloads.exe b5b4e0513e141323194c78b98c1c2759 2008-07-19 3:30 PM (GMT -5 +1 for DST)File Name MD5 Hash Modified Date: With everything added, your svcpack.inf, should look something like this: KBnnnnnn.cat <------------represents other integrated Windows Updates KB942288.cat <------------Required, integrate with /INTEGRATE KB898461.cat <------------Required, integrate with /INTEGRATE ... <------------represents other integrated Windows Updates KBnnnnnn.cat <------------represents other integrated Windows Updates [SetupHotfixesToRun] KBnnnnnn.exe /q /n /z <--represents other integrated Windows Updates KB942288.exe /q /n /z <--Required, integrate with /INTEGRATE KB898461.exe /q /n /z <--Required, integrate with /INTEGRATE ... <--represents other integrated Windows Updates KBnnnnnn.exe /q /n /z <--represents other integrated Windows Updates QChain.exe <--Recommended, you add this to svcpack.inf. WindowsUpdateAgent.exe <--Required, you add this to svcpack.inf. MSDownloads.exe <--Required, you add this to svcpack.inf.[ProductCatalogsToInstall] You must also copy the following files to your XPCD\i386\SVCPACK folder: QChain.exe WindowsUpdateAgent.exe (after you follow my guide to repackage it) MSDownloads.exe Do it by the numbers, and report back.

Thanks and nice catch.MSDownloads.exe will actually install the latest version (since you actually download 12,0,5572,1000), but my .inf is setting the version and date registry information incorrectly, as if the files were from the previous version of the .cab. It looks like I forgot a little housekeeping here. This is of very minor consequence and nothing to worry about really. Still, I'll update MSDBuild.exe in a day or so. I'm currently looking into including 7-Zip command line executables with MSDBuild.exe so people don't have to download and install WinRar first. This should result in a slightly smaller MSDownloads.exe as well.

My Guide (linked above) now has newer .infs which address the authorization issue.