Martin H

I have found the answer myself: Source: http://www.msfn.org/board/-t19050.html&amp...st&p=129836 However, in that above-linked thread, then there's also this responce to the above quote: Source: http://www.msfn.org/board/-t19050.html&amp...st&p=129847 So, there's two different oppenions on this, but personally, then i'm confident in that '[bM]Crusher' is right in that the numerical order of the driver-folder names are irrelevant, since that can be seen by looking at setupapi.log... However, if GreenMachine has something to say about this, then i would love to hear it, and also since i'm very currious about the part about MS should have done tests on this issue and found that the numerical order did make a change ??? (i have read all i could possibly found from MS about OEM drivers and driver ranking calculations etc)

@FDV Would you say that fileset 8 is in it's final state now, or is it still a test release ? I'm asking since your site still states 'New fileset Tuesday May 27, 2008 (minor bugfix in IE.INF)'... Also, sorry for off-topic'ness, but could you please also tell me if the 'iexplore.exe' dummy-file and the 'Internet Explorer' folder it's located in, also is one of the things you've made in the fileset to help trick IE-dependant apps into thinking that IE is installed ? I'm asking because if the folder and dummy-file dosen't help fool IE-dependant apps, then i will delete the folder and dummy-file from RunOnceEx in my next ISO, as i don't need another shortcut for my browser... Thank you so much for your continued efforts, mate - It's very much appreciated Thank's in advance. CU, Martin.

@Roufneck Firstly, thank you so much for this wonderfull tool of yours, it's very much appreciated, mate Second, then i would like to make a feature-request to you about if you would maybe consider adding an option for not compressing the drivers, but just doing the other steps i.e. parsing the inf's and copying over only the referenced files... I think this would be a very nice addition, since i believe that there are lots of people(like me), which uses your tool for filtering out unneeded files and then afterwards uncabs the cabbed files, since they either install drivers uncompressed directly from disc, or using 7-Zip'ed drivers... Btw, in the documentation you state that cat files are not needed if you disable WFP, but i would suggest that you change that, since driver signing is seperate from WFP and since cat files also influences driver ratings... I myself remove cat files and also disable WFP, but it was just a thought, so as to make sure that newbies understand the impact of that option better...

In the MSFN 'Unattended Windows' guides driver section, there's stated to name the driver folders with numbers in the front, so as to force setup to install the drivers cronologically. This makes perfect sence to me, but however, the thing i'm wondering about then, is that if you after having installed Windows, goes into '%windir%\setupapi.log' and checks in which order the drivers did install, then i can see that the install order isn't matching the order of the folders... Instead, it looks to me like setup is detecting one PNP device at a time and then afterwards parses all the inf's in the folders listed in the devicepath reg-entry(%windir%\inf' etc.) for the specific hardware-id of that specific PNP device and then when the correct inf has been found, then it's used to install the driver... So am i right in this and does it then mean that it's useless to add numbers infront of the driver folders ? Btw, i'm installing my drivers uncompressed directly from CD by following the stickied guide from a06lp: 'Drivers from CD: Simple Method' (it's the method of using schalti's "CopyInf" idea and Pyron's SetupCopyOEMInf.exe etc.), but this shouldn't make any difference to what i described above... Thank's in advance.

Your post doesn't make any sence... Please rephrase it, while giving some more detailes about your issue and also attach or post your hfslip.log file(in codebox tags, please)...

You'll need to change each inf's '[sourceDisksNames]' section to point to driver.cab, update drvindex.inf, add non-inf driver files to driver.cab, add inf driver files to I386 and reference them to be copied to %windir%\inf in txtsetup.sif/dosnet.inf... Btw, HFSLIP supports doing most of this, except the small inf edits, but those can be automatically made with daddydave's Drivercab Helper.

I personally preffer the classic installer, as it's ~2mb smaller, installs faster and as i'm not really a big fan of msi installers in general(they're bloated and leaves a copy of the installer in '%windir%\Installer' etc...) Anyway, the classical installer is hidden on the Opera homepages download section, but can be found by selecting 'Show other versions > Windows' and then selecting the latest version on the top of the list... The classic installer is a Wise installer which accepts the '/s' command-line argument for silent installs and it will by default make the desktop, quicklaunch and start menu shortcuts, but you'll still need to add the reg-entries for making it the default browser on your system... These are the exact ones Opera sets: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.htm] @="Opera.HTML" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.html] @="Opera.HTML" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.mht] @="Opera.HTML" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.mhtml] @="Opera.HTML" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.xht] @="Opera.HTML" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.xhtm] @="Opera.HTML" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.xhtml] @="Opera.HTML" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\http] "EditFlags"=hex:02,00,00,00 [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\http\shell\open\command] @="\"C:\\Program Files\\Opera\\opera.exe\"" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\http\shell\open\ddeexec] @="\"%1\"" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\http\shell\open\ddeexec\Application] @="Opera" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\https] "EditFlags"=hex:02,00,00,00 [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\https\shell\open\command] @="\"C:\\Program Files\\Opera\\opera.exe\"" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\https\shell\open\ddeexec] @="\"%1\"" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\https\shell\open\ddeexec\Application] @="Opera" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Opera.HTML] @="HTML Document" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Opera.HTML\DefaultIcon] @="C:\\Program Files\\Opera\\opera.exe,1" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Opera.HTML\shell\open\command] @="\"C:\\Program Files\\Opera\\opera.exe\" \"%1\"" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Opera.Image] @="Image" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Opera.Image\shell\open\command] @="\"C:\\Program Files\\Opera\\opera.exe\" \"%1\"" [HKEY_LOCAL_MACHINE\SOFTWARE\Clients\StartMenuInternet] @="Opera.exe"

HFSLIP v2.0 pre-alpha allready supports slipstreaming IE8: http://www.msfn.org/board/HFSLIP-20-in-the...ks-t116421.html If you're adding IE8, then skip the IE7 step...

Sorry if you know allready, but the Foxit Reader executable supports a switch for silently doing exactly that... "%programfiles%\Foxit Reader\Foxit Reader.exe" -Register @All I had recently switched from Foxit Reader to SumatraPDF, since it was smaller in filesize and as i assumed it would be lighter also, but after having read this thread, then i did a quick test with the latest versions of Foxit Reader(v2.3.3201) and SumatraPDF(v0.9.1)... Without a PDF loaded: Foxit Reader: ~7.3mb SumatraPDF: ~7.0mb With a PDF loaded: Foxit Reader: ~13mb SumatraPDF: ~17mb So as i also was having some issues with SumatraPDF that really bothered me, then i have now changed back to Foxit Reader again Sorry that i didn't included Adobe Reader into my little test here... Edit: I have now changed to Foxit Reader v2.0.1606(the last version of the 2.0 series - javascript support first appeared in v2.0), as that only uses ~9mb RAM for that same pdf i tested with above and it's also a couple of megs smaller in filesize...

Come on, guys... As you can read by doing a single 2 secs. google/forum search, then SP3, as well as all previous SP's are cumulative for slipstreaming(SP3 isn't cumulative for regular installs however, and needs SP1+), which then obviously means that the diffs aren't relevant, as else it wouldn't be cumulative anymore...

Read the MSFN Unattended Windows guide and come back if you have specific questions to something you have read and don't understand... Other than that, then welcome to MSFN

Yes. '\I386\svcpack.inf' is parsed.

The thinking about (ab)using the 'ping' command for pausing purposses, is that 'ping' allready is available on all systems, and no third-party tools need to be added to the install-source... It will work no matter if there's network support available or not, as it dosen't matter if the pinging requests are answered or not... It's a sorta hackish solution, but nonetheless then it works great and avoids the need for extra third-party tools, so i always use it myself...

Regfind.exe from the Win2k resource kit features general search and replace support on the registry/hive files... regfind /? usage: REGFIND [-h hivefile hiveroot | -w Win95 Directory | -m \\machinename] [-i n] [-o outputWidth] [-p RegistryKeyPath] [-z | -t DataType] [-b | -B] [-y] [-n] [searchString [-r ReplacementString]] Maybe usefull to you... http://www.petri.co.il/download_free_reskit_tools.htm

cmdlines.txt is parsed from the install-source at T-12, so i personally take a snapshot just a little before that, and then when the install finishes, i remake the ISO with the needed changes and restart the VM from the snapshot

Source: http://www.msfn.org/board/index.php?s=&amp...st&p=710546

--- HKLM\SomeKey ----- SomeValue --------- Data1 --------- Data2 --------- Data3 --------- Data4 If we then want to delete 'Data4': @reg add HKLM\SomeKey /v SomeValue /t reg_multi_sz /d "Data1\0Data2\0Data3" /f >nul Btw, there's also a Win2k resource-kit tool named Regfind.exe, which features support for doing search and replace operations on the registry... http://www.petri.co.il/download_free_reskit_tools.htm

You're most welcome and i'm glad you've gotten it fixed now

No, it isn't related to you using the built-in admin account... Now if you're absolutely sure that the tweak actually works and that SHOW_OPERATING_FILES.REG is located in "\$OEM$\RunOnceEx\", then the tweak needs to be applied after the shell has fully loaded, so try with this RunOnceEx.cmd: @cmdow @ /hid set key=HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx reg add %key%\001 /v 1 /d "%~dpn0\7-Zip-v4.42.exe" /f reg add %key%\002 /v 1 /d "%~dpn0\WinRAR-v3.71.exe" /f reg add HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Runonce /v command0 /d "regedit /s %~dpn0\SHOW_OPERATING_FILES.REG" /f If that dosen't work, then try this: @cmdow @ /hid set key=HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx reg add %key%\001 /v 1 /d "%~dpn0\7-Zip-v4.42.exe" /f reg add %key%\002 /v 1 /d "%~dpn0\WinRAR-v3.71.exe" /f reg add HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Runonce /v command0 /d "cmd /c @cmdow @ /hid&ping -n 1 -w 10000 1.1.1.1&regedit /s %~dpn0\SHOW_OPERATING_FILES.REG" /f Also, remember to have cmdow.exe into '\$OEM$\$$\System32\'... The last one will pause 10 seconds after the shell(explorer) has finished loading, so if it still dosen't work, then i'm affraid that i cannot help you...

Some tweaks just don't apply from T-12, as they are overwritten later on by the shell... Try from first-logon instead...

The folder with the apps in the example i gave you where '\$OEM$\RunOnceEx\' and then the path to the apps in RunOnceEx.cmd is then '%~dpn0\' which expands to 'E:\$OEM$\RunOnceEx\' if the CD drive where E:... If the folder with the apps instead where e.g. '$OEM$\Apps\', then the path would be: '%~dp0\Apps\'... Check out jaclaz's links...

The article dosen't say that... It says that if you import current user keys from cmdlines.txt, then they will be applied to the default user hive and hence, all new created users will inherent those keys... At T-12(cmdlines.txt) then the built-in administrator account is the only account available. The built-in administrator account is solely meant as a setup and recovery account only, which means that you use it during setup and then afterwards you instead use another account with admin-rights enabled and then leave the built-in administrator account untouched, so that you always have a backdoor into the system if something ever goes wrong and you e.g. cannot log into your primary user account or some other problem with your main account...

Remove the REGEDT32.EXE part and since your test is finished then also remove 'SHOW_OPERATING_FILES.cmd'... I didn't say that, btw... The commands are right for SFX archives, since you don't need switches for those, but even if there was a need for switches(if the apps weren't SFX archives), then you would see an installer popping up anyway, which you didn't, so the problem lied in another place... The syntax is right if you're having the SFX archives in '\$OEM$\$1\COOL_STUFF\' and if you have 'OemPreinstall=Yes' under '[unattended]' in '\I386\WINNT.SIF' Since you have 'pause' commands before and after the app installs - for testing, then what where the cmd output ?

nLite related posts belongs to the nLite sub-forum... nLite should only be used to remove things you know for sure you don't need! Redo your ISO with that in mind...

you're not prompted for the computer name, but for the password of the built-in administrator-account... Make the following change to WINNT.SIF to fix it: [GuiUnattended] AdminPassword=*