Djé

Well I'm not 100% sure but I guess that firefox just use the stuff in the location you mentionned to create the default profile when a new user open it for the 1st time, or when the -createprofile switch is used. So basically, I think that what you're trying to do would just work using the switch, at least at the beginning. Then any new version of Firefox you install may destroy your custom default profile. That's why, in my opinion, this is a bad way to do it: don't mix you custom stuff with things that can be changed by Mozilla at any time, or you may loose control. If you want to be a professional dictator with your users (as you said, your iron hand has also a foot in the users' extensions & themes ), I would just advice to have your custom default profile ready in the Default User's %appdata% folder (You can copy it there @T12 or later). As a profile will be existing, Fx won't show the Import IE wizard. That way you can impose your will to any new user without fearing Firefox' Blue Helmet messing in your private business . The other solution, of course, would be to go the 'free' way, allowing the users to customize Fx their own way and so on. But do people want to be free, nowadays?? BTW, bugzilla is still unreacheable (maybe it has been the victim of a DoS attack, the very problem v1.5.0.3 was released to solve ) but here's the link to the override.ini article.

Tried it: You were true , I have to use the full thing.

Can you be more specific, please? What do you mean by 'no luck'??? It's very possible that you don't need any luck to use this method, you know... What fails? Where? When? When you talk about cd & dvd, are you mentionning the disc or the drive? Finally, a rather important question regarding this method: how many drivers do you have? Do you use a dvd because you've got so many of them? Help us to help you.

Yes. I've seen it used that way and suspected it worked (although I can't confirm it). i f you can infirm it, please do. At least, in the same way '/d' work fine in lieu of '/delete'. Well, never better served than by oneself , so here it is: * An AddOn to be used by English-Systems users. Others cannot use it if their hive files are in Unicode and not in ANSI: the current version of the RVM Integrator supports Unicode only for a limited set of files but not these. - I don't know if it works with nLite, I don't use it and don't know how it handle this. * So for the others, I've put together an AutoIt script to do the job AFTER using the Integrator (it has to be in the same folder): It will look for the location of the file in the integrator.ini and patch it (converting it to ANSI before). - I recommand to compile it using one of the last AutoIt beta version. Q314543.au3 ADDON_NET_USE_T12.CAB

Can't the fix be done as an addon, or even better from the update pack ?

Either have a profile already existing in %APPDATA%/Mozilla/Firefox. You can copy back one you had previously backed up, or create a brand new one using (silent): firefox.exe -CreateProfile defaultYou can use whatever profile name you want instead of 'default' Or have a file named 'override.ini' in Firefox program folder and containing the following: [XRE] EnableProfileMigrator=falseThat feature was introduced with v1.5.0.2. Bugzilla does not seems to work right now so I can't provide the link to the KB article. I'm a bit worried tho, because there used to be a link to that bugzilla page on the v1.5.0.2's official release notes page but it's not there anymore...

Anyone knows how to connect to network during install? @T39, I think it's not possible as network drivers are not loaded yet. @RunOnceEX, I have no problem to do that, but I'd like to do it at T12. So far, when I use 'net use' at T12, computer says that workstation service is not loaded, while 'net start' says it is . 'ping' does ping my server, but that's the maximum I could squeeze out of the network at this time of the install . What am I missing to make it run properly so I could download progs at this time? To whom it may help to help me, the 'network' I'm talking about is so far one of the simplest implementation of this concept: Two XP home PCs linked by a crossed cable. Intel pro/100 adapters or so, no specific Network settings nor services loaded, drivers loaded correctly, Files 'server' getting its address by dhcp (and so the 'client' as it is the default setting for a newly installing windows). Net Use does not work, even after waiting for the computer to get its address from dhcp. ???? ?? ???? ??, ???'? ???? ??! [Edit] found the solution just a few threads above thanks to forum member std73 bumping it up. [Edit 2] It does work, but then I bumped into another error: My usual NET USE command, working very fine in other situations would not work, NET issuing a 1312 system error: NET USE Z: \\Dje\install /user:monica mmlmlm /persistent:nowhile using 'NET USE Z: \\Dje\install /user:monica' from a CMD prompt @T12 would just ask for the pwd and work perfectly . Googling did not bring too much relevant things, except for a Win2K sp2 related KB article showing the same symptoms with a different error #. Hopefully, the proposed solution worked too: Use a dummy Domain Name together with the user name NET USE Z: \\Dje\install /user:whitehouse\monica mmlmlm /persistent:no Testing was done with 2 XP home boxes. I'm not sure if this last problem exists also in XP pro. [Edit 3] repaired the 'persistent' switch, thanks to Sonic (post #3)

I confirm the new T39-tested final version to be: DetachedProgram = cmd.exe Arguments = "/Q /C FOR /F %? IN ('FINDSTR/B dospath= %SYSTEMROOT%\SYSTEM32\$WINNT$.INF') DO (SET %?\&& CALL START /MIN %dospath:\\=\%Detached.cmd)"@copy-pasters: please note that my Detached.cmd is no more in $OEM$, just at the root.

Yzöwl, you were right Attached is a proof and an "application". multivar.cmd

@Yzöwl, I'm pretty sure you've got it (although my brain is too narrow right now to figure out how it works exactly) but the FOR loop is not a very good demonstration: you could acheive the same displayed result with a single line %VAR%: ::make VAR a slightly different way FOR /F "DELIMS=" %%? IN (SIXLINE.TXT) DO SET VAR=!VAR!"%%~?"<SPACE here> ::confirm VAR is monoline ECHO %VAR% ::still display it multiline FOR %%? IN (%VAR%) DO ECHO %%~?-please note the <SPACE> at the end of 'DO SET VAR=!VAR!"%%~?" ' -to be integrated in the previous example Also 'DO SET VAR=!VAR!"%%~?"^' followed by 2 empty lines does the trick without %LF%'s. And as in your example, it may be multiline as it can't be displayed properly by ECHO. Do you know of any other way to dump those variables so we can confirm their 'multitude' ?

LOL: the 'FINDSTR/I DOSPATH= %SYSTEMROOT%\SYSTEM32\$WINNT$.INF' command is finding ... itself! ... because the 'Arguments' line remains in $WINNT$.INF which is a cleaned-up copy of the answer file. --> So we really have to specify to search at the beginning of the lines. In facts, we have to double-escape the caret: ^^^^DOSPATH=Jupiter knows why... Luckily, while in $WINNT$.INF all other lines are written (in text mode setup) with spaces surrounding the '=' sign and all values (double-)quoted, the very 'dospath' line is added (in GUI mode setup) with no space nor quote: dospath=C:\$WIN_NT$.~LSIf it were not like this, FOR would only return 'dospath' and not the value. (Note that there is NEVER any space in the value itself, as the only possible values for dospath are 'X:\' or 'Y:\$WIN_NT$.~LS', X & Y being drive letters, since only a 'temp drive' can be specified for winnt.exe or winnt32.exe). As you adviced, Yzöwl, I also removed the 'IF ERRORLEVEL 0' as I'm pretty sure the 'dospath' line is ALWAYS added (by Setup?). And anyway, who cares? If it's not, FOR will NOT DO anything (as FINDSTR is searching the start of the lines for 'dospath=') So the (temporary?) final version is: DetachedProgram = cmd.exe Arguments = "/Q /C FOR /F %? IN ('FINDSTR/I ^^^^DOSPATH= %SYSTEMROOT%\SYSTEM32\$WINNT$.INF') DO (SET %?\&& CALL START /MIN %dospath:\\=\%$OEM$\Detached.cmd)"*TESTED* @T39, on a local source installation. Thanks again Yzöwl for the great simplification. [EDIT]I guess 'FINDSTR/B dospath=' should work as well and is better looking. I'll test it.

In Choice.cmd, in order to get rid of the quotes in the displayed strings we can use: :SETVALUES SET %TYPE%%I%=%~1 GOTO :EOF[only added a tilde (~) inside %1] No solution yet for the question marks... @Yzöwl: I feel better today and got it. Yesterday, I though you had somehow managed to make a multi-lines variable , because of: ECHO/.%PICK% |FINDSTR/C:".%ONE%."but now I understand it's use. Good thing for validating choices.

Got it! [EDIT] this is not yet working properly @T39, see post below for the solution[/EDIT]: DetachedProgram = cmd.exe Arguments = "/Q /C FOR /F %? IN ('FINDSTR/I DOSPATH= ^<%SYSTEMROOT%\SYSTEM32\$WINNT$.INF') DO (IF ERRORLEVEL 0 (SET %?\&& CALL START %dospath:\\=\%$OEM$\Detached.cmd))"No more delayed expansion thanks to Yzöwl. I'm gonna test the CALL START in real T39 situation soon. @Yzöwl, why would we need the input redirection to FINDSTR (<)? why not just feed it directly with the file name? : FINDSTR/I DOSPATH= %SYSTEMROOT%\SYSTEM32\$WINNT$.INF We may also want to specify the start of the line: ^^DOSPATH=

use FINDSTR, SET %? and CALL Sorry if I was not clear about that, but dospath is not always just a drive path like 'E:\': When installing using winnt.exe (or winnt32), you may have to make a local source and $OEM$ would be transfered by winnt.exe to that local source. The location of the local source FOLDER would then be in the 'dospath' directive (something like 'c:\$WIN_NT$.~LS'). So we need to retreive the full line (and add a trailing '\' to the local source folder name to have the same pattern as with a Cd based install). This slash thing is why we need the '(IF NOT !dospath:~-1!==\ SET dospath=!dospath!\)' (and so delayed expansion). I'll try to shorten this as well using CALL. Also, I am not sure that CALLing a .cmd file works @T39. I've read about and painfully experimented troubles when not using START. Do you know better? [EDIT] this is not yet working properly @T39, see post below for the solution[/EDIT]: DetachedProgram = cmd.exe Arguments = "/Q /V:ON /C FOR /F %? IN ('FINDSTR/I DOSPATH ^<%SYSTEMROOT%\SYSTEM32\$WINNT$.INF') DO (IF ERRORLEVEL 0 (SET %?&& (IF NOT !dospath:~-1!==\ SET dospath=!dospath!\) && START !dospath!$OEM$\Detached.cmd))"

Thanks dudes. Yzöwl, I'm too tired for tonight and really could not grab the entire mechanism yet. But I'm suspecting you acheived something great... I'll have to investigate tomorrow morning with a good coffee...

In that post, I suggested to have a much simpler Arguments line in Winnt.sif: DetachedProgram = cmd.exe Arguments = "/Q /C START /MIN %SYSTEMDRIVE%\Drivers.cmd" and to do the dospath scan comfortably from the Drivers.cmd that would have been copied to %SYSTEMDRIVE% through '$OEM$\$1'. The only problem with that method is when OemPreinstall has to be set to 'No'. Because Drivers.cmd could not be copied over. It's always possible to have it copied by another method during text mode setup but this involves even more integration. So I managed an Arguments line for the DetachedProgram in Winnt.sif that may be more universal: - It do a better scan of $WINNT$.INF, really looking for the dospath line. - It does not require to copy anything from the $OEM$ folder. - Moreover, it adresses the problem of the missing trailing "\" for installations using a local source (from dos, network, etc.). Here it is: DetachedProgram = cmd.exe Arguments = "/Q /V:ON /E:ON /C FOR /F %I IN (%SystemRoot%\SYSTEM32\$WINNT$.INF) DO (SET LINE=%I&& SET DEB=!LINE:~0,7!&& IF dospath==!DEB! (SET dosP=!LINE:~8!&& (IF NOT !dosP:~-1!==\ SET dosP=!dosP!\) && START /MIN !dosP!$OEM$\Detached.cmd))"Besides being unreadable , the 'Arguments' is one single line, which has no other quotes than the surrounding one (as required by winnt.sif syntax) and where every space in it is important! I'm using it here (for another purpose than drivers installation) and it works very fine.

I think you did not get me: I'm not saying that it's better to replace HKCU by HKU/.DEFAULT (because they map to the same hive anyway). I'm just saying that by mistaking HKCU with the Default User hive at T12, you will leave some dirt in the HKU/.DEFAULT hive, making this a not-very-clean way of doing thing. As for myself, I just import my reg files (broken down into bits, a bit like yours) only to my account, at RunOnceEx time (when HKCU maps only to it). I have absolutely no will nor need to impose any settings to the other users. And if I had, I would just load the Default User hive, import the settings in it, and unload it. Clean & straight. And as for "Quit over thinking things" ... you'll have to give me a goog reason for that !

@Nois3, I must agree with 99% of your sayings, and i loved the clear way you explained it. The only peanut remaining is about the Default User being the Current User during install. From what I experimented and found in the registry itself (you may have a look at HKLM\SYSTEM\CurrentControlSet\Control\hivelist), during install the Current User hive (HKCU) is not mapped to the NTUSER.DAT located in the Default User's profile dir. It is rather mapped to a default system hive, used by windows when No User is logged in. This hive is better known by the name of HKU/.DEFAULT in the registry, and it is mapped to a file simply called 'default', located in %systemroot%\system32\config\ (see the above key). At the end of windows setup (EDIT: this happens right after T12*), a copy of this hive is transfered (the right way, obviously !) to make the Default User one, in its profile dir. That's why setting applied to HKCU or to HKU/.DEFAULT at T12 are indeed also found in the Default User's hive later. But those settings still remain in the No User hive (HKU/.DEFAULT) where they have nothing to do, especially as they are intended for when a user is logged in. A first concern is that it is just plain not-very-clean. Maybe InTheWayBoy would also want to consider this. A second one is about security, as you pointed out, with the mixing of setting made for one situation (a user logged in) with those made for another situation (no user logged in). But for this I have no clue**. Now, a simple experiment to confirm what I said, is to open a CMD window during install in order to have some control ('cmd.exe /K', called from cmdlines.txt at T12, or even better from DetachedPrograms at T39 so you have plenty of time), to import a test key to HKCU (reg add ...), and to look in regedit.exe where is your test key. BTW, feel free to try to load the NTUSER.DAT hive from the Default User's profile dir during setup, in order to check what's in it . * I launched the following command from a batch called by cmdlines.txt and no NTUSER.DAT in the result: DIR /A:H "C:\Documents and Settings\Default User" 1>c:\dir.txtThen I manually ran the same DIR command from a CMD prompt launched @T39. I did it a few successive times from a bit before T12, and the hive appeared right after T12. **For example, I'm just wondering about those settings I have to import to HKCU at T12 in order to lower security for allowing unsigned programs to be installed unattendedly.

Attached is a demonstration of how to use SET to dynamically assign variables when their names are made from other variables' values. It makes use of the CALL command and of the righ number of %s. The demonstration is a simple menu application, displaying labels, asking for the user's choice and returning a custom data associated with the label. For any use it could have. Choice.cmd

[rant style=ironic]Which is the least you can expect from a company found guilty of dishonest business practices.[/rant]

He must have done it...

[humor]How to you want us to beleive you: nobody has a a script called "script.cmd" in folder called "Folder" That would be too simple! [/humor] [serious]What does it mean ??? From which directive in winnt.sif ? DetachedProgram ? GuiRunOnce ? SetupParams ? They all have different syntax and for example the 1st one cannot accept cmd files directly. Why don't you post better explanations so we can help further? [/serious] [humor grade=half-serious]If you do, please post a picture here afterward! [/humor]

Is it possible to run WIHUlite & WIHUnetcfg unattended with an .ini file? I've seen wihunetcfg.ini but there is nothing related in it to IP adress, DHCP or workgroup... If it is, then translation would not be necessary ... since it is for unattended use! If not and if it's not planned for the future, would you know about other progs which could do the same tasks unattended? Sorry if this is not directly related with WIHU (except for the name) and thanks for all the work. BTW, I've made an Excel program that can store & maintain program lists and then export them to different post-installer formats like WIHU. If you want to have a look...

I just found why in some situations I couln't get peshuteject to work properly (it could eject but not reboot): In those situations I was launching it by dble-clicking a .cmd file in the A43 file browser. But if I just call the .cmd file from a CMD window, it works ok. So it seems that to have peshuteject running properly, A43 should be closed. This may also be necesary with some other progs, beware.

You can't modify theme regs: they are set/overwritten automatically by the theme manager when your account is created (1st logon). As oioldman said, you have to prepare a custom theme (ControlPanel/display properties/save as) and then either install your theme through winnt.sif, or from T12 or RunOnceEx using this. winnt.sif will apply the same theme for all users (default setting). With my method, you can choose to only install the theme for the 1st user login in.