DarkShadows

The Sysinternals Suite Installer installer built by my scripts does not delete any registry settings under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce. Those registry values get automatically deleted by the Windows operating system after they have been run once, thus the name of this registry key. You add a registry value there for an application that needs to be run only a single time, and after that application is run, Windows removes the registry value by-design.

I haven't worked on this project in some time now. And I tried to find a quick place to upload the last version. Try this link and let me know if you can download the file okay. https://docs.google.com/file/d/0B41zyr2PAmYmSWJzWjM1Q2VNY1E/edit

Please try the download link again. It should work correctly now.

If you folks notice, this is the exact same link I provide in my guide. It's a static link--it doesn't change between ActiveX control versions. You just have to wait until Microsoft updates the download behind the static link. B)

For a regular silent installation, just use the Slim build from the CCLeaner Builds Page like this: ccsetup225_slim.exe /S

I think I may have found the answer to why you had download trouble. Please try again.

A new version is out, go get it. B) Sysinternals Suite Installer Builder Version: 2.7 Sysinternals Suite Current Build Date: 2009-11-04 SysinternalsSuite.zip Changes: Executable Program Version Date ------------------------------------------------------ NewSID.exe New SID Retired Required End User Action: Read Version History in second post. Re-download SysinternalsSuite.ulz from first post. Re-download SysinternalsSuite.zip and SSIBuild.exe. Execute SSIBuild.exe to recreate SysinternalsSuite.exe. I've also provided Directory Opus users an early Christmas present, check out the first post for details.

No, it's not really required for this project, it's just a habit of mine. I've posted direct download links in this guide. Yes, it is still active I just updated to a new version. But even still, I could download the old version just fine. Can you try the download link in the first post and let me know if it works for you?

Microsoft Security Bulletin MS09-051 - Critical Vulnerabilities in Windows Media Runtime Could Allow Remote Code Execution (975682) Published: October 13, 2009 | Updated: October 14, 2009 This security bulletin above actually lists three (3) different update downloads for Windows XP SP3. DirectShow WMA Voice Codec Windows Media Audio Voice Decoder Audio Compression Manager Of the three updates above, only one (KB954154) is listed among the WMP11 updates list on the WMP Slipstreamer page. Q: Are the other two updates not really part of Windows Media Player 11 or is there something else going on here? Thanks for maintaining this most excellent tool! B)

Your English is fine. As strel mentioned (and I quote him below), follow the guide directions to edit a custom SFX-MSD.ini file (the file is documented internally). The MSDownloadsESN.ulz file, provided by Hippo Loco, should address all Spanish-related download urls. Hippo Loco also posted some notes earlier in this thread that you might want to read. This is all correct. Thanks for covering my thread strel! MSDBuild.cmd doesn't know about, or care about, Office Genuine Advantage Notifications, which is relatively new. This update is similar to KB905474 Windows Genuine Advantage Notifications. OGAN, like WGAN, is not really required to run your software or to run Microsoft Update. However, I'll bet it might contain a version of OGACheckControl.dll, just Like WGAN contains a version of legitcheckcontrol.dll. In any circumstance, Microsoft Update will list this update until you either hide it or install it.I'm not planning to update this guide for OGAN (at least not yet) since Office Update is now handled by Microsoft Update. I also view the Office Genuine Advantage Notifications more as part of Microsoft Office installation, rather than as part of Windows XP installation. I'm not sure if installing OGAN without MS Office already installed on the PC will work or not. Thanks for reporting your findings it will help in my research when I get around to it. I'm job hunting right now. I will be removing them from MSDBuild very shortly. The MSDBuild.cmd script really only cares about WinVer=XP. But still, it's a good catch and I'll fix it shortly. Thanks for reporting it. That is because you must still download everything (at least until I strip Office Update out of MSDBuild). For now, if you don't want Office shortcuts, all you need to do is customize SFX-MSD.ini, which is documented internally. In the next MSDBuild version, the Office Update shortcut will not be created, since the web site is now discontinued. I do not use nLite, nor do I support nLite or any other integration software. Therefore, you need to ask nLite-specific questions in the correct forum. However, by now I'm sure someone over there has read this guide and can tell you how to incorporate what is discussed here in a nlited way. WUD most certainly displays all the ActiveX plugins discussed in my guide, which includes MuCatalogWebControl.cab. However, you must import my MSDownloads.ulz list as instructed in my guide before it will list these. There is a WUD screen grab in the first post of this thread that lists the ActiveX controls, including Microsoft Update Catalog Web Control Class (ActiveX), which is what MuCatalogWebControl.cab is. If you actually had read my guide, then you will know what MuCatalogWebControl.cab is, what files are inside of it, and where to put it in order for MSDBuild to package it for you inside of MSDownloads.exe. But it sounds like you haven't even read my guide. I cannot speak to MicrosoftUpdateCatalog_Addon.cab. That doesn't sound like a file from Microsoft. Post a download URL for this file and I'll take a look when I get a chance. Try reading my guide again, and pay attention to Issue-02 since you are working in Dutch. Start as if you were going to builld for English but replace my English files with Dutch ones. MSDBuild should be able to handle it. At least it worked that way for Spanish.

You should have posted your question in my Guide thread. You must download WUD install it it, import my MSdownloads.ulz list into WUD and then you get all the download links. Use the earlier version of WUD. v2.30 b988 or the latest version WUD. v2.50 b988. See the screen grab in my guide (link in my signature below) for how to select a category.

strel I re-integrated an XPCD for Windows XP Home (OEM) and Windows XP Pro (Volume), both installing .Net Framework packages built with the latest SNM Syth build. Both install the .Net Framework packages from svcpack.inf in this order: DNF20.exe DNF30.exe DNF35.exe DNF11.exe I installed the Windows XP Home to the actual PC, and Windows XP Pro to Virtual PC, and in both cases Windows Setup never hangs. It is still puzzling about why RunOnceEX would just hang, but it looks like the issue is safely worked around when installing from svcpack.inf (which I would rather install from anyway). Now in both installations, the .NET Framework Setup Verification Tool still shows several errors of files missing. However, I can see now that they are files for languages other than English (all are named with 4-digit language codes and 1033, which is English is not reported as missing). Since everyone I support speaks only English, I do not install any language packs. So I'm guessing that the errors reported by this tool are not as big of a deal as I first thought. Again, thanks for your help. -DS

Since my last post, I attempted installing my XP Home OEM XPCD again, this time with the new .Net packages generated by the most recent version of SNM Synth (again using all .NET Framework updates actually listed in Microsoft Update). This time, not only did the installation hang, but the .NET Framework Setup Verification Tool report shows errors. FYI, the older SNM Synth .Net installation packages that worked (after resetting the PC in the middle of RunOnceEx) were built by 20090514_SNMsynth.zip. The only other difference between those packages and newer ones is the new ones contain NDP35SP1-KB963707-x86.exe. Here's a download link to the requested logs: SNM-Synth-Logs.zip. I've also included the log file generated by .NET Framework Setup Verification Tool as well as the temp files generated by your INSTALL.cmd. Thanks for the help.

@strel Hey there. I wonder if you can help me trouble shoot this one. It's a head scratcher... I downloaded your latest build of SNM Synth and created default packages (no .ini file changes) for each .Net Framework using all related updates currently listed in Microsoft Update (including the Firefox related one), but no language packs. I integrate them into my WinXP Pro SP3 XPCD as follows: DNF20.exe - installed from svcpack.inf DNF30.exe - installed from RunOnceEx DNF35.exe - installed from RunOnceEx DNF11.exe - installed from RunOnceEx NOTE: All packages are fully updated with all their perspective SP and KB updates, I just rename them to shorter generic names. On VirtualPC, Windows XP Pro volume installs correctly, which it has every time I have ever used your script or the original SNM by Tomcat76. Today, I was rebuilding a PC with Win XP Home Edition OEM. And RunOnceEx fired off after the first user logged in and it started working as normal. However, when RunOnceEx got down to the .Net Framework 3.5 entry the installer unpacked and installed but the RunOnceEx process just halted afterward. There was no HDD activity, the mouse just sat there and RunOnceEx didn't progress to the next entry. After 30 minutes I pressed the PC reset button and rebooted it. After logging in as the same user again RunOnceEx continued on the next item after the .Net Framework 3.5 entry, which is .Net Framework 1.1. but the .Net Framework 3.5 entry was still listed. Then RunOnceEx completed as did the first user log in. So I checked Control Panel - Add/Remove Programs and all four .Net Framework installations were listed as expected, despite the process hanging and the forced PC reset. So at this point, I rolled back to my XPCD to the previous .Net packages I created using an earlier SNM Synth build and started over (no other changes to the XPCD). I got exactly the same results. This time I also downloaded and ran the .NET Framework Setup Verification Tool from Aaron Stebner's WebLog and all four .Net Framework installations checked out okay. So I looked in the %TEMP% folder and I see the unpacked 7zip temp folder with the .Net Framework 3.5 files still inside. I've zipped up all the files your script created in the root of that folder and attached them here. But I have no clue what is happening or why it would work with Win XP Pro on VPC and not XP Home on a real PC. Any ideas? DNF35_SetupFiles.zip

There is no need to post the parts, the file download is working now.

@Windows XP 64-bit users. Folks, here's the situation (as I see it): Windows XP 64-bit works differently than Windows XP 32-bit. Software manufacturers (like Microsoft) release different copies of their programs for Windows XP 64-bit than they do for Windows XP 32-bit. This is likely to impact the tools and scripts I use in this project, as well as the files that should be installed to your Windows XP 64-bit system and where those files should be installed. I have a 100% completely-working, and scripted process. However, it is currently only supports Windows XP 32-bit. While I can at least develop enough to manage this project, I do not have access to Windows XP 64-bit—at all. Thus, Windows XP 64-bit is a huge, unknown blackbox to me. I'm an Atheist and a Scientist—This means I take nothing on faith and I rely solely on repeatable test results. And until somebody is willing to get me some, I cannot and will not help you folks. Most people who ask me for Windows XP 64-bit support are not developers. But even worse, they are seemingly completely unwilling to actually help me do any of the leg work required to help answer some very specific questions. This is really a shame, since what I'm asking for is not development skills, but simply trying some things out, looking up some information, and reporting back to me with the results. If you want something fixed, be part of the solution not part of the problem. To summarize, I need a lot more answers from you Windows XP 64-bit folks than questions right now. So some of you need to step up and be my hands and eyes, otherwise we are not going to get very far with a working Windows XP 64-bit version of MSDBuild. Q1: Not to pick on you, but what exactly are you you saying? The MSDBuild.exe does not even run on 64-bit Windows? The MSDBuild.exe runs on 64-bit Windows, but the something produces an error? The MSDBuild.exe runs on 64-bit Windows, but the resulting output does not work for you (due to things you have mentioned later)? All the above? Something else? You must understand that at this point, I do not even know if the version of 7-Zip I use to create the MSDownloads.exe package even works correctly on Windows XP 64-bit. I also don't know if MSDBuild.exe will unpack itself and even run on Windows XP 64-bit. And nobody seems willing to answer these very simple questions. This is first useful piece of information anyone using Windows XP 64-bit windows has provided me (but I still need a lot more information). This tells me I at least need to make a version of the .inf file that registers muweb.dll so it installs it to a different folder for 64-bit Windows. Plus it even tells me the folder. (However, I'm certain this is not the only thing that will need to be changed before everything works correctly.) Since you are not a developer (and since I'm an Atheist Scientist) this is not enough information for me. Having the same version does not necessarily mean it is the same file, or that the file was downloaded from the same URL. So please answer the following questions. Q:2 What is the Code Base URL? Open %WinDir%\Downloaded Program Files. Right click on MUWebControl Class and click Properties. Copy the Code Base URL and paste it in your reply. NOTE: It scrolls off the dialog so be sure you get all of it. Q:3 What is the MD5 Checksum for the file? (You can Google for free tools that provide this.) Q:4 What is the File Size in KB? Q:5 What is the Modified Date/Time Stamp? Q:6 What is the File Version? So you are clear what I'm looking for, I've pasted the information for the 32-bit version of muweb.dll below. I want the same pieces of information for an up-to-date 64-bit version of muweb.dll. Code Base: http://update.microsoft.com/microsoftupdate/v6/V5Controls/en/x86/client/muweb_site.cab?1139406804265 MD5: d2e6f0a06391fe5556e8a1d6d5041a5e Size: 204KB Modified Date/Time: 2008-10-16 03:06:48 PM File Version: 7.2.6001.788 NOTICE: Do you folks see that URL I posted just above? do you see the "x86" string in it? That usually means 32-bit. So I need to know if the Code Base URLs for the ActiveX control files installed on Windows XP 64-bit have a different download URL. It is possible that there are different files for each architecture, even though they may be versioned the same. Q:7 Also, please export the follow registry key to a .reg file and post it as an attachment. [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Code Store Database] You need me to make the Windows XP 64-bit version for you. But I need you (or someone) to do the things I ask for on Windows XP 64-bit and answer the questions I've asked. Without the answers to my questions, nothing is going to get done. The more answers I get, the more that will get done.

Q: How could I accomplish that within an .inf file (one icon if IE7/IE8 is installed and another if not)? One of my goals was to have it such that the user could use whatever IE version whenever. So for example, the IE8 registry settings for ActiveX control per-user and per-domain authorization are present before you ever install IE8. But once you install IE8, the update web sites should still work without manual authorization, since they have been pre-authorized. This means that MSDownloads.exe contains the same .inf files, no matter which IE version the user has installed. Luckily, there has been no issues thus far. The extra registry settings required to silence per-domain ActiveX control authorization in IE8 do not adversely impact IE7 or IE6. And the per-user settings you pointed me, which are required for both IE8 and IE7, do not adversely impact IE6. So the same .inf file is used for all three scenarios, and it creates the same shortcut for Microsoft Update Catalog, using the same icon, no matter which IE version is installed. Q1: Is there a way conditionally install a shortcut within an .inf file? Q2: Is there a way ascertain the IE version within an .inf file? My guess to both is most likely not. But I'm no expert here (I still read your handy WinCert guides). So to me, the simplest solution is to simply rip the Globe icon from urlmon.dll from IE8 and include it as an .ico file. (I'm already doing this with the Office icon.) Then I can point to the same file no matter which IE version is installed and find the icon. But if there is another way, I'm always open to learning a new technique!

Hey Rick, that's a nice find. I think I'll just rip that icon out and save it as a .ico file, that way the same shortcut will still work for people who are adamant about using IE6. Now I just need something else to change to justify working on this again. Any other ideas? Do you have Windows x64?, can you shed any light on the questions I just posted above?

I know from the referenced sources, that we could actually install the .dlls to either %WinDir% or %WinDir%\System32 (and most likely to any other folder). We just need to change the registered file path in the associated setup information file. In fact, one of the ActiveX control's .dll (Office Update if I remember correctly) currently resides under %WinDir%, while the rest reside under %WinDir%\System32. I used the same locations Microsoft used for each control on 32-bit Windows. So long as the registry keys and values are used to register the ActiveX controls are the same on 64-bit Windows as they are on 32-bit Windows, then the file locations should not matter. MSDBuild.exe's job is to package the most recent versions of all the related ActiveX controls into your MSDownloads.exe package at the time you build it. MSDownloads.exe's job is to install what was packaged on your PC, in a working state, during Windows unattended installation. From there Microsoft takes over, and auto-updates each of the various ActiveX controls, on their own schedule. As Ricktendo64 mentions, when any ActiveX control auto-updates, it should download, install, and re-register and the next version of its .dll where it really belongs. The only downside of might be that maybe the older .dll version might be orphaned and left behind on your system. That is to say I'm not sure that the ActiveX auto-update will remove a .dll file stored in a location different from the location it installs the new .dll version to. By contrast, when the ActiveX control installs its new .dll version to the same location that MSDownloads.exe installed the old .dll version to, then the old .dll is overwritten by the new and no obsolete files are left on your system. You've already have it! It's all just script files archived up inside a WinRar SFX. Just download everything using WUD and extract MSDBuild.exe to a folder without running it. The only thing that you do not have is the script I use to automatically package MSDBuild.exe. We can worry about that one later. Unfortunately, I only have 32-bit versions of Windows XP to test on, so I can only speculate. I cannot actually test and confirm where the files should go or if the registry keys and values are all the same on a 64-bit system. I also wonder if the datastore.edb file works the same on 64-bit Windows, and if a seperate version of datastore.ed_ should be maintained for 64-bit systems? The whole time I've maintained this guide, no one with a 64-bit system has informed me if any of this even works on a 64-bit system or not. And no one using 64-bit Windows has stepped forward to test and report back. So I have no confirmed knowledge if the .dlls are the same for 64-bit windows, or if the requisite Windows update downloads are the same. So instead of letting you change things, how about you help me find out what works first. For now, I'd ask you to not change anything, and please perform following test and reports the results. On a Windows 64-bit system, attempt to build a MSDownloads.exe package strictly as follows: Manually, launch all four Microsoft Update web sites and install their ActiveX controls, ensuring everything is working and authorized so that when close your browser and relaunch the web site, you are not prompted for anything. Install all Windows updates (related to my guide or not) using Windows/Microsoft Update. Your system should be up-to-date. Download and Install WUD (I think it requires .NET Framework, but check the WUD website). Download and install my MSDownloads.ulz from the first post here. Using WUD, you can click on any files in my list to open the KB article. Research which updates have 64-bit version. Q1: Which Updates from this guide have 64-bit versions? I know about Windows Update Agent v7.2.6001.788 Q2: Does WUD work on Windows 64-bit correctly? Manually download any your 64-bit versions to your WUD download folder, and delete the related 32-bit version of the same update. Double-click MSDBuild.exe. NOTE: For now, customize nothing. Q3: Does MSDBuild.exe (and thus MSDBuild.cmd, 7-zip, and my various VBScripts) work correctly on Windows 64-bit? Q4: Did they collectively create a MSDownload.exe package? Q5: Does the MSDBuild.log file show any errors or warnings? (Please provide me this file as an attachment.) On this updated 64-bit PC, navigate to the Download Program Files folder. Right-click on each Update ActiveX Control and select Properties. Inspect the Code Base urls for each ActiveX control. Q6: Are these the same as what I'm using in SFX-MSD.ini? Note that for some ActiveX controls, that I'm using the static Microsoft url, if I know it. I would expect these to be different for 64-bit windows. So could you paste the urls for me? Create a 64-bit XPCD, but only add those updates and MSDownloads.exe as documented in my guide (from svcpack.inf). Do not install any other windows update or .Net Frameworks, et cetera. (This will save you a lot testing time.) Keep it with IE6 too. On a test Windows 64-bit system, test strictly as follows: Test install your 64-bit XPCD. After Windows Setup completes, Look for the icons MSDownloads.exe creates. And try running all the different update sites (you do not need Office installed to run Office Update). Q7: Did the shortcuts I document in the guide get created? Q8: Do the Update web sites work? Q9: Do any of the Update web sites prompt you to install or authorize any ActiveX controls? Q10: Do any of the Update web sites prompt you to download and install any other Windows updates? If everything is working so far, then install IE7 manually on the VPC (and any updates it requires too) and test the update sites again. Q11: Did you see any IE7-related prompts to authorize or install ActiveX controls? If everything is working so far, then install IE8 manually on the VPC (and any updates it requires too) and test the update sites again. Q12: Did you see any IE8-related prompts to authorize or install ActiveX controls? If you can do the testing for me, I can help you get a working 64-bit version. I'm not always near a high-speed Internet connection, so this may take awhile. But we can get it done.

Can you publish this script as well? Thanks.

I am also richer, since I have never played with creating an IExpress package. Thanks for sharing your work Joe.

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

Follow the instructions to edit a custom SFX-MSD.ini, the file is documented internally. EDIT: Whoops, I quoted the wrong post!

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

It would be nice if the installer supported choosing a Program Group, as well as a command line option to do so.