GreenMachine

@shareef59: I do not have a mechanism for installing a package of that type: where there are files that are used by the install, but not executed. You have a few options. The simplest would be to just use the IE branding file: the latest IE versions (less the latest update/patch) are already included in SP1. Alternativly, repackage as you suggest, where you could either run from RunOnceEx (ROEXE) or SVCPACK.INF (HFTYPE0). HFTYPE0 would be prefered, as you can then run the updates after. Do you have a particular reason to want to run IE install, or were you unaware of the fact that it was already up to date?

@shareef59: You will need to create the directories and sub-directories that you use in the example, i.e. FILESCD\$OEM$\$1\IE6sp1, FILESCD\$OEM$\$1\applications\winrar, FILESCD\$OEM$\$1\msn, FILESCD\$OEM$\$1\DirectX9b, FILESCD\$OEM$\$1\powertoys, and place your install files in the corresponding directories. Note that everything inside of FILESCD will be copied to the root of the CD, preserving the directory structure. You are including MSI files. These are recommended by MS NOT to be run during setup itself, rather by the installed system either through RunOnce or RunOnceEx. You can place your CMD file(s) in the ROEXE directory, in which case a RunOnceEx entry will be created, and the programs will run during the first reboot. Alternativly, you can place the MAINBATCH.CMD file in the $OEM$\$$ directory, and include the call in the WINNT.SIF file in the GuiRunOnce section: [GuiRunOnce] Command0=MAINBATCH.CMDHope that gets you on your way. @Tbone2: Sorry for the delay answering your post ... the two hotfixes you mention are indeed treated as Type I hotfixes, but are run from the RunOnceEx point, i.e. after reboot, as opposed to the SVCPACK point, at the T-13 mark. I have not succeeded to run 817778 from SVCPACK.INF, though others have. The 822603 USB update had been running from RunOnceEx, but recent test show that it can be included with the rest of the Type I hotfixes. Note that this update will normally show as uninstalled in Windows Update inside of Virtual PC, due to VPCs USB handling.

If your .EXE is in the %systemdrive%\install\PRE_SP2\SECURITY\ directory (i.e. $OEM$\$1\install\PRE_SP2\SECURITY\), that would be correct. The repack works fine, it is actually running the patch that is in question, due to the generated 8.3 names (e.g. file01~1.ext), as opposed to the long file names. Do tell the final result, after install.

I realized it's only a recommended, but I've not come accross it. Perhaps because I normally disable CD burning, or perhaps it's new (high number, dead link in WU)

831240 ? What's up with that, AaronXP?

I hadn't seen your edit, so I thought you went over to "that other site" to post the results ... Glad to see it works better, but I am still surprised it is 5 minutes slower than techtype tool. Did you use the same set of hotfixes/updates? And nine minutes seems a little funky as well: I do it in 4, and my CPU and CD are slower, and I have less RAM. How fast was techtypes CD in the textbased part? Similar? What would really be interesting is an event log export from both setups ... Anyway, I think that may be as far as I take that bug for now. Note that one could always build the CD with the N option, and all this would become a mute point, but I do like the integrity added with updating the cabs themselves, even if the older file versions should never be used. Thanks again to the debuging and testing department!

As techtype suggests, once we could see past the end of our noses, we could see the problem. It was in the CAB file creation. Thanks Numinous for pointing me to the docs. Not "light" reading, but I think I got it. It took two major edits (2147483648 to 250000000, and /B to /B /O-E) and everything is OK. I timed the file copy part of setup, and the repacked cabs timed in at 4 Minutes 10 Seconds, where the non repacked cabs completed in 4 Minute 0 Seconds. Since the repacked cab was about 3% smaller, I decided not to pursue further optimization. In searching for documentation for cabinet files, I came across THIS DOCUMENT. It is an earlier version of the MakeCab document that is included in the CabSDK. The original version of MakeCab was "Diamond", and the name still carries over: the configuration file is still refered to as the DDF, Diamond Directive File. The documents themselves are nearly identical, with the exception of the mention of one file; DDUMP.EXE. This is a "Tool to dump internal format of a Diamond cabinet file". Has anybody ever seen this file, or used the original Diamond Cabinet Maker? I believe it came out in 1996. Any info or links are appreciated. In terms of hotfixes, I have found that the USB update, KB822603, which I had been running in RunOnceEx, can also be slipstreamed with the other type I hotfixes. Thus the only hotifxes / updates that are required to pass the "Windows Update = 0" test that cannot (should not?) be run from SVCPACK are 817778, and the MSI installers (DotNet, Journal Viewer, Windows Messenger). And I know there are some of you out there, DaveXP included, that manage to install 817778 from SVCPACK.INF. My next quest will be to track this down, and make it work for me. It is the Advanced Network Package, so I will start by looking in the Networking and Components sections of WINNT.SIF. If any one has any ideas on that, speak up. @mdes: I will look at your modifications, and possibly include them. I'm glad that you got into the code to make it work for you. (T'as bien fait. Si t'as des questions, PM moi.) @Tbone2: Here we go again ... This should work. If you try it and have good results, please post here. If the results are NOT good, please post HERE MAKECD.CMD

Tbone2: After much hair pulling, and relentless help from techtype, I think we have pinpointed the problem. In the pursuit of removing every outdated file on the CD, I update any CAB fils which contain files that have been updated. This was previously done be default, and is now optional in the later versions. In repacking the cabs, I have somehow rendered them more "complex", and it is when text based setup is copying files that are inside the cab files - you can see it stutter with modem.sys, usr*.* and more - that all the time is lost. I do not yet have the final solution, but it will be in how I repackage the cab files. Right now I am looking into: - using CABARC instead of MAKECAB - updating the cabs, as opposed to rebuilding them - trying different switches/compression ratios - reading the documentation (if someone has some - PM me please) I also wonder if there is some sort of index inside the cab that I could update. If someone out there has any ideas, and experienced similar problems when making cabs, give a holler. miso1391 ??? For now, the workaround is to simply select the N option (Full, No Cabs) from the menu. Tbone2, sorry to have made go through a 15 minute file copy. I understand why you question my timing methods! The CDs I compared where compiled using the N option. Note that not updating the cab should be safe, and is in fact the way that MS outlines in KB articles. The DOSNET.INF file HAS been updated, so older versions still in the DRIVERS.CAB and SP1.CAB should not be used. I'll post again when I get this sorted out.

@Tbone2: I think I have found the problem, somewhere in the cab files. I'll post when I know more. @DaveXP: Nope, I haven't gotten any further - this one here is bugging me too much. I'll keep ya posted.

Thanks, Tbone2. Unfortunatly, I am not that optimistic. The script you use, from the MSFN guide, uses the same program and switches to create the ISO as I do. I have played with some switches, and I have found fast combinations, but with unwanted side effects (UPPERCASE ...). Let us know ...

Thought I wouldn't see your edit, eh?! Yes, what techtype says makes me question the CDImage process. There are a lot of switches, and I am convinced there is something to be done there. This is obviously supported by the fact that WinISO extraction - addition has an effect. In addition, assuming that Tbone2 did not use XPCREATE to create the other CDs he benchmarked, that would also explain why my results were consistent with both timing methods: I used the same script to create each CD, the difference was in the actual files modified. Please tell, Tbone2. I appreciate the help of both of you in debuging this problem. I do not have much time over the next few days, but I will be testing a few things, and I will post if I discover anything interesting. In the mean time, there are two tests that could be run, should time, conditions and inclinations permit. 1) Create a CD using other ISO or burning software. The CDROOT directory contains all the files that are to be burned to the CD, and the BOOTIMG.BIN file can be found in the TEMP\NEWFILES directory. 2) Replace the contents of the CDROOT directory with the contents of the TTP1 / TTP2 CD, and use the "Create ISO" option to create this CD with CDImage. Again, thanks for your help, and post if you find something.

I vote for a burn problem. I created 5 CDs for these tests, and they all seemed to require comparable times for DOS copy. My original timings were from the point where I selected the partition, to the time when the system was ready to log on after last reboot. My values were this (again, two tests for MSFN and RHSM, one for the rest): RHSM - 35 Minutes MSFN - 37 Minutes TTP1 - 46 Minutes TTP2 - 43 Minutes RUNO - 46 Minutes While the TTP1/TTP2/RUNO has slight variation with the posted results, I find MSFN and RHSM values to be consistant with these findings. I did set the timer start at a point AFTER DOS copy, but at the same point for all tests. This was chosen, as my first timings relied on me looking at the PC, pressing buttons, and noting times. The final timing system relies totaly on PC compiled data. I have noticed that some CDs copy faster than others, all created with the XPCREATE scripts. Specifically, it seems that on some CDs there are some points that the CD stops spinning. This includes the 71% point of file copying. The only reason I have come up with to explain this, is perhaps the validation of slipstreamed files requires longer, as the correct .CAT file must be found. Unfortunatly, that does not explain why some CDs are so much faster than others. I'm a little tired of installing XP for the moment. If I can devise an accuraqte timing system, that does not rely on my noting times, and does include more of the whole installation process, I may rerun the tests. Perhaps I will simply time the first part of the installation. I will also mention that the RHSM CD I used did NOT seem to display this "hiccup" when copying files. Why would I think YOU are bashing me: you are one of the handful of people that has taken the time to test this, and provide me your feedback. For that you have my thanks!

Thanks, Przemek. The reason I doubt that I will update the chart to include a method such as MSTest's, is that it is simply too complicated for me. I am dead against editing any files by hand, and following the excellent and simple guides of Aaron exhausted my ability to follow directions. If you, or someone else, provides me with the type of files I included with the comparison chart, I could probably produce a CD to complete the chart in terms of speed and CD size. In terms of a guide for the RHSM, I will work on that ... However, bear in mind that it is basically a "turn-key" script, so the only user intervention required is dropping the right files in the proper directories. I have a page on the site, Current Hotfixes, where the patches and corresponding directories are listed. The only user specific file required, and then only to allow for unattended installation, is WINNT.SIF. All other files are available for download, and most linked off the Current Hotfixes page.

Thanks, baliktad. I gotta give credit to you, for tipping the scales in my favour with the /O thing. Who ever would'a thought! I agree with you about staying as kosher (or orthadox) as possible. The slipstream only option I propose is simply an automated version of the process outlined by MS HERE and HERE. I consider that to be safe, even in a corporate environment.

The RoyalBox HotFix SlipStreaming Method has come a ways since I first started this thread, so I thought I would give a brief progress report. Firstly, I've added the GuiRunOnce section to the CD creation process. Five types of files can be run from here: - Type I Hotfixes - Type II Hotfixes - Switchless installers - MSI installers - MS Packaged MSI installers (in .EXE format) This, combined with the OPK or MSFN repackaged versions of MDAC, WMP9 and DirectX allow the script to produce a CD that has zero recommended or critical updates showing at Windows Update, without the need to manually edit one single file (WINNT.SIF is generated by Setup Manager) Secondly, the Type I hotfixes are now run using the /O /U /N /Z switches. The newly adopted /O switch decreases installation time dramatically. This switch has the side effect of disabling the OEM driver search that causes Type I hotfixes to take a considerable amount of time per hotfix if run from the SVCPACK.INF / CMDLINES.TXT portions of setup. Lastly, for ease of use, I have integrated a primitive TUI menu, allowing the user to select different options or sections of the entire process. The basis for this whole project is to be able to produce the most up to date XP CD possible, with as many outdated files as possible removed from the CD, and replaced with the updated file versions. Neither speed, nor disk space were major concerns. There has been much debate about which Hotfix Slipstreaming Method is best, or truest, or biggest, or fastest. For this reason I have compiled a comparison chart of a few of the different methods presented on MSFN. If statistics, numbers and hard facts are your concern, check out the results HERE! Happy Slippin'!

The easy fix is to slipstream the hotfixes. You do not need to run them manually once per machine, and the files you mention will be up to date. Though I do not use RIS, the script I use does have an option to just slipstream the hotfixes. The script is based upon the document that you quote, and all the steps in that document have been automated. For good measure, I also update the CAB files, and the ntdll.dll in the systems32 subdirectory. Though you may need some minor modifications for RIS, this is a valid solution to the problem you describe. Again, if I can help you specifically with this script, PM me.

Due to a MSFN change, and un-updated links. Sorry. http://greenmachine.msfnhosting.com/ It you have any specific questions, please feel free to PM me.

There must be a tweak somewhere: I have not been offered a "Windows Tour" in a long time. I forgot all about it. [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Applets\Tour] "RunCount"=dword:00000000... could be this ...

What is wrong with simply setting your IE start page to blank?

I would certainly not accuse you of lying. You were simply misinformed, and spreading your mis-information. Is that useful? If you do not know what you are talking about, please, for the sake of all of us, have the decency to refrain from posting your ignorance. You claim in no uncertain terms that something cannot be done, even after a fellow member has said that he did it. What's the point? Is DPR lying? Do you honestly find such behaiviour constructive?

Perhaps if you knew what the hell you were talking about you COULD give a reason. Once again, you're spreading untruths. Please do your research before posting such (false) claims. It does not help any of us.

@baliktad: I like the prudent approach: CYA. I'm sure it will work great for me. I don't get it about JavaVM. I liked your post about combining the versions. (Being the way I am, I won't try it 'til I write a script to do it for me.) Is this the result of that write-up? Not hex-modified, but repackaged? I looked at the WinPE post: looks like you just boot WinPE and call WINNT.EXE. Just the same as you could do from DOS (in about 10X the time...). Did I understand correctly that you use Bart's version? Glad to have you aboard. My tip for you: Click on the word Posted: just above, in this post's header!

@baliktad: you're gonna make us all feel blind with this -o thing. Do you think this will create problems for those including OEM drivers in the installation? I'll certainly use it if it works for me. Also, after reading your post I added all the optional components to my installation, and the 811114 update was the only one that showed up. (You knew that: I just learned it.) Is the msjavwu.exe that you install with the javatrig.exe command line the stock msjavwu.exe, or has it been modified? Lastly, there are a ton of people here, myself included, that would like to know more about your WinPE based installation method. Thanks for the tips!

I think miso1391's way is way cool: point me towards some documentation for writing the SED files, would you please? The problem I have run into is how to package directory structures for the install files. IExpress from the GUI will not do it, but I would think it could from here.

@viseversa: Sorry to make you do all that work: I only really wanted any files of your own that you added, like *.reg or *.cmd... I looked over your directory listing and see a few problems. You are German, na? Did they stop the phrase "Deutsche Reinheit und Ordentlichkeit"? You have much too much junk in there. You have both MDAC 2.8 and MDAC 2.7 update, Journal Viewer run twice. If you are willing to help me, what I would like to do is this: Have you re-run the (latest) script with only the files listed on THIS page, and your WINNT.SIF. Send me your WINNT.SIF, and I will try exactly the same. You have to be a little carefull of which files are present, as I will just loop through a directory and run them all. Download THIS version, run the MAKEDIRS.CMD file, add your WINNT.SIF (overwrite the existing one), add the fixes listed on THIS page. Also, you CANNOT rerun this script: I do not have a version of DOSNET.INF included, instead I modify the existing version, by adding lines to the end. If this is done a second time, unpredictable results WILL occour. On the other hand, you expressed concern that you needed to delete files before running, to assure "starting clean". I leave all the temp files for inspection, but delete them all as the first step in creation. For your troubles, I did include your requests, and I will PM you with a custom (non-supported) menu. Also, some of the directory names have changed, and some have been added, so please take the time to re-read the documentation HERE. With this release, there are only 3 files that are not readily downloadable from the web: DirectX OPK, WMP9 & MM2, and a repackaged MDAC, and I believe you have those already. Please give it a go, and post your results. On another note, my PC is scheduled to self destruct in an hour - my 180 MS trial of Windows 2003 has come to an end. I will have either a little down time, or have to convert (eiiiiks) to my XP box...