[New batch file install]

I don't believe everything I find on the internet, but THIS ARTICLE seemed to make sense (even to me...) I know it's a little old (NT4?), but I think it's still acurate.

[Possibly stupid hotfix question?]

Look Here

[Can someone help me with a simple guide to using]

I'd still go with export/import. The whole thing ain't that big, try it. If you feel the need for copying the whole thing, I'm sure that there is an "overwrite on next reboot" queue, and I would bet it is availible from within a simple .inf file. There are certainly people on board that can tell you about those: I cannot, but it sounds like it may be what you want.

Brave chap, using VNC. I would go nuts if I looked at what they did!

[Can someone help me with a simple guide to using]

pmcx9: I know what you mean: I, too, am very lazy.

I'd say you are well on your way. I think I have all the visual settings restored correctly on my box, though I have not gone over it with a fine toothed comb. I have not played with the power stuff, and there may be some sort of hardware dependecies, so you tell us. If I may be so bold ... a few things I would like to see in a "small time system builder":

Insurance, a la MS. You keep your install CD up to date, and send 'em one a month. For a certain fee ...

Safe system restore. Create a 2/3 partition system: [1 = Diagnostics], 2 = System, 3 = Data, all loaded onto a "clean" HDD from CD (ghost or such - there are even enough freewares). You can use the CD or Diagnostics partition to restore the system, and leave the data intact, in the case of chronic user "install everything I can download". You would need to make sure the partitions are active/non-hidden, etc, as well as defining user's directories (i.e. "My Documents") are stored on the D (Data) disk. None of this is too difficult, and once in place, fairly maintenance free.

My reasoning is that if you do not have a large customer base, you need to get more $$ per customer, while offering a quality service that they are satisfied with, and happy to pay for. You recover 2 years, or even two months of some one's data, and you are (rightfully so) their hero.

Just a thought. Let us know how you get on with the last steps.

[Can someone help me with a simple guide to using]

Hmmm. I know that I mentioned copying the NTUSER.DAT file earlier (never tried it) ... but I must have been drunk: It would discredit afore mentioned theories! I would think that there is no way you can copy over it as such: it is locked by the system. There may be a way to add it to a queue that is used by hotfixes and installs to be replaced on next boot, but that would be beyond my scope (though others here probably DO know how). However, if you load the default user's hive, you will see that there is not that much to it. You should be able to easily weed out what you don't need, and just export/import as usual. I would also suggest importing any settings from a (more or less) clean machine, to avoid importing unnecessary settings and other registry clutter. All the other files should not be a problem. I like to delete all shortcuts, All User's and Default User's, and then add them arranged as I like to the All User profile. This also has the advantage that only administrators can move/delete them, yet they are always availible for all the users. It depends on your users, and how "Hitlerian" approach you must take, but it sure does reduce maintenance.

Just looked at your last lines of code. First, let me congratulate you: this code is short enough that I actually read it to the end (you out did me above). I always use regedit instead of reg, but it looks like you are changing the users name. I have to look into that. For security reasons, one should (theoretically) rename the Administrator account and create a "dummy" "Adminstrator" account, disactivated with no rights. Couldn't find an easy way to do that, but why not: the registry is once again the answer. Thanks.

...Yes, the easiest way to do the HKCU stuff is here. You could always log on as the administrator, modify the default users account, delete all users profiles, log on to a new user with adminstrator rights, delete the administrator's profile, and the result would be nearly the same, but I digress...

The fade effect, small iscons, etc, can easily be exported into .reg files, and imported, avoiding the copying NTUSER.DAT.

[Can someone help me with a simple guide to using]

Thanks, pmcx9. I was begining to think that there hadn't been a reply because no one finished reading it - I realized after that perhaps "Simple Guide" was not the best description.

Fear not, I think that most of the work you put into the GuiRunOnce code and calls can be used here with little or no modification. I have edited the post above to include a list of available environment variables.

Perhaps I should not be the one to say which method is "better": I have never tried any calls from GuiRunOnce...

Last point: I just learned about the shift-f10 thing. Could have saved me hours...

un4given1: you can change your name to 4given1. Peace. (I was that obvious in my finger pointing...?)

[Can someone help me with a simple guide to using]

Using CMDLINES.TXT.

The CMDLINES.TXT file is parsed by Windows Setup after copying the $OEM$\$* directories and included files, and after running aditional inf files that may be listed in DOSNET.INF (SVCPACK.INF for example - the Slipstream Hotfix Inf file), at around the T-13 minutes mark. The syntax used is a subset of that used in normal .BAT and .CMD files, and for that reason it is easier to call a .CMD file from CMDLINES.TXT, where the syntax is richer and more familiar. The first line of CMDLINES.TXT should read [COMMANDS]. Additional lines could contain calls to various programs and setup files, wrapped in quotes. However, it seems to have become a de-facto standard to simply call one command script that contains all subsequent commands and program calls. The name of the called file listed in CMDLINES.TXT is user definable, but an 8.3 named file (FILENAME.EXT) listed in the same directory is the simplest and safest. For the sake of this example, I will name the .CMD file INSTALLS.CMD. My complete CMDLINES.TXT should now look like this:

[COMMANDS]
".\INSTALLS.CMD"

You could add multiple calls to the CMDLINES.TXT file, but is unnecessary, and complicates the debugging process.

INSTALLS.CMD

This is a standard command script file, using the normal command script syntax. You are not limited in script instructions nor program calls in this file itself, though certain programs/instructions may not work, due to the unfinished state of the windows setup. An example is the NET USE command, which you cannot use, as the Workstation service has not been started, and is required by the NET USE command. In terms of file manipulation, and program installation, INSTALLS.CMD will usually be sufficient for your installation needs. This file can often simply be the file that many use to install programs, called from the GuiRunOnce section of WINNT.SIF.

The advantages of this method are that the system is logged onto the Default User profile, and changes made there are subsequently copied over to each new user, including the administrator, as that user is created. At the point CMDLINES.TXT is parsed, the only user profile that exists is the Default User profile. Installations from the GuiRunOnce WINNT.SIF section will not necessarily be installed for all users.

The major disadvantage I have seen to this method is that is perhaps a little more complicated. I do not find this to be the case personally, but judging from comments here …

Following are some pointers, and an attempt to clear up some misconceptions of this process. This is based on my installations, as well as certain MS documents that I have read (though they are not always correct …). Let me note that I NEVER use a $1, $$, C, or such directory in $OEM$, thus I cannot be certain that what I mention here is the same for those of you using these $OEM$ sub-directories as the means to copy files to your hard disk.

1) When CMDLINES.TXT is parsed, thus the call to INSTALLS.CMD made, the working directory is <CDDRIVE>:\$OEM$.

2) The only files copied from $OEM$ to the hard disk are those included in reserved subdirectories ($$, $1, C, D, etc). Files in the root of $OEM$ and subsequent, non-reserved directories (i.e. <CDDRIVE>:\$OEM$\SETUPS\) are NOT copied to the HDD.

3) You do not need to place your setup programs in $OEM$\$1\Installs. This is only interesting to do if you wish to access these programs AFTER the GUI reboot, when you are no longer able to access files on the CD, as you cannot know the drive letter (USUALLY D:, but it is hardware dependent). You can access the files on the CD from CMDLINES.TXT using relative paths (i.e. “.\SETUPS\SETUP1.EXE"), and they do NOT need to be copied to the HDD first. The reason to copy the files to the HDD is that there is not an easy mechanism to know which drive letter the CD has been assigned during the post GUI Reboot portion of setup.

4) A list of available environment variable for CMDLINES.TXT calls follows:

D:\$OEM$>SET
ALLUSERSPROFILE=C:\Documents and Settings\All Users
CommonProgramFiles=C:\Program Files\Common Files
COMPUTERNAME=NEWXP
ComSpec=C:\WINDOWS\system32\cmd.exe
Path=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.JS;.WS
ProgramFiles=C:\Program Files
PROMPT=$P$G
SystemDrive=C:
SystemRoot=C:\WINDOWS
Upgrade=False
USERPROFILE=C:\Documents and Settings\Default User
windir=C:\WINDOWS
__PROCESS_HISTORY=C:\WINDOWS\system32\setup.exe

D:\$OEM$>

5) This is the ideal place to make changes to the HKCU settings that will not "stick" when made after this point, namely the Explorer and Internet Explorer default settings. This is because both these applications (so it appears to me...) save their settings when logging off. At the point the CMDLINES.TXT calls are made, contrary to the GuiRunOnce calls, the Explorer shell is not graphically "active", thus does not save settings that overwrite your own registry imports.

For the non-believers and pros who know better, please note that 1 above can be verified by adding the following line to INSTALLS.CMD

START "DOS BOX" /WAIT CMD

A DOS window will open during setup, and you will see the working directory. From a DOS window points 2 and 3 can be verified. If you do not want to open a DOS window from INSTALLS.CMD as shown above … just type SHIFT-F10 at this point, and a DOS window will open.

This is based on my installation method (NO $OEM$\$...), and the information I share here is based on classic reverse engineering techniques more than relying on (often incorrect or incomplete) official documentation. I do everything from the CMDLINES.TXT call, and it works for me. I do not use the GuiRunOnce for anything: I have completed all I need before this point. An example of what can be done at this point (my INSTALLS.CMD file):

@ECHO OFF

TITLE Post Install Setup

:: ---------- Update MS Components 

ECHO Starting DirectX 9 Install.
START "DirectX 9 Install" /WAIT ".\DIRECTX\DXSETUP.EXE" /opk

ECHO Starting Internet Explorer 6 Install.
START "Internet Explorer 6 Install" /WAIT ".\IE\ie6setup.exe" /C:"IE6WZD /S:""#e"" /Q:A /R:N"

ECHO Media Player and Movie Maker Install.
START "MP MM" /WAIT ".\SVCPACK\WMP9_MM2.exe"

ECHO Installing Dot Net.
START "Dot Net" /WAIT ".\SVCPACK\dotnetfx.exe" /Q:A /c:"install /q"

ECHO Installing MDAC 2.8.
START "MDAC" /WAIT ".\SVCPACK\MDAC_TYP.EXE" /Q:A /c:"dasetup.exe /q /n" 

ECHO Updating Microsoft JavaVM.
START "JAVA" /WAIT ".\SVCPACK\msjavwu.exe" /Q:A /R:N

ECHO Hotfixing.
START "HOTFIX" /WAIT ".\SVCPACK\KB819639.exe" /Q:A /R:N

:: ---------- Adjust the Registry

ECHO Importing Registry Files. 
START "" /WAIT REGEDIT /S ".\SVCPACK\HKLM.reg"
START "" /WAIT REGEDIT /S ".\SVCPACK\HKCR.reg"
START "" /WAIT REGEDIT /S ".\SVCPACK\HKCU.reg"

:: ---------- Remove files I do not like

ECHO Removing useless shortcuts.
RMDIR "%ALLUSERSPROFILE%\Start Menu" /S /Q
RMDIR "%USERPROFILE%\Start Menu" /S /Q

ECHO Removing useless folders.
RMDIR "%systemdrive%\Program Files\ComPlus Applications" /S /Q
RMDIR "%systemdrive%\Program Files\Online Services" /S /Q
RMDIR "%systemdrive%\Program Files\Uninstall Information" /S /Q

ECHO Removing HotFix Log Files.
DEL "%SYSTEMROOT%\*.log" /Q /F
DEL "%SYSTEMROOT%\*.txt" /Q /F
DEL "%SYSTEMROOT%\*.tmp" /Q /F
DEL "%SYSTEMROOT%\TEMP\*.*" /Q /F
DEL "%USERPROFILE%\*.log" /Q /F

:: ---------- Add files I do like

ECHO Installing Custom Windows Files.
XCOPY ".\PROFILES\All Users\*.*" "%ALLUSERSPROFILE%\" /E /C /Y /Q /H
XCOPY ".\PROFILES\Default User\*.*" "%USERPROFILE%\" /E /C /Y /Q /H
COPY ".\SVCPACK\HKCU.reg" "%systemroot%\System32\"

:: ---------- Fix up the User Accouints

ECHO Deleting Useless Accounts.
NET USER aspnet /DELETE
NET USER SUPPORT_388945a0 /DELETE

ECHO Setting up Users.
NET USER SysAdmin SysAdmin /ADD /COMMENT:"System Administrator Account" /PASSWORDREQ:YES
NET USER User User /ADD /COMMENT:"Local User Account" /PASSWORDREQ:YES
NET LOCALGROUP Administrators SysAdmin /ADD 
NET USER Administrator /ACTIVE:NO

EXIT

Bottom line ... whatever floats your boat. The better method is that with which you feel more comfortable, and that which best meets your requirements. I have multi-user systems, and insist that all my modifications are valid for all users. I have no need for the GuiRunOnce, you may.

[uncheck fade effect and always on power scheme]

If you already have a $OEM$\$1\ Directory, you could just place the .lnk file in "$OEM$\$1\Documents and Settings\Default User\Application Data\Microsoft\Internet Explorer\Quick Launch" (assuming you have not changed the PROFILESDIR setting in WINNT.SIF). Aternativly, you could copy it to "%USERPROFILE%\Application Data\Microsoft\Internet Explorer\Quick Launch" during install. I put a copy of "My Computer" there, which is defaulted to open in explorer view, and this way I have access to explorer, as well as the my computer right click options.

For the fade settings, I think you are doomed to do all the HKCU stuff. The current Registry Tweaks thread adresses this as well.

Power scheme should not be a problem, I believe that is a HKLM setting, but do not know which one.

[Add "Close Tray" to right-click menu on CD-drive]

Are you out of the registry yet?

HKEY_CLASSES_ROOT\Drive\shellex\ContextMenuHandlers\CloneCD. It adds a .dll file (ElbyVCDShell.dll) that handles both displaying the option (Close Tray), and performing the action. More than just a registry setting. You could perhaps get away with one DLL and a couple of registry settings, but if you go this far, might as well install the whole thing, no? I install it, and would even consider doing it for that option alone.

[Registry Tweaks, Part-1]

@Kenneth

Volatile Memory.

The registry is basically a simple database, with a programmers interface to add/remove/edit data inside. This uses a certain amount of resources. Some entries in the registry are in almost constant use (explorer settings for example, as explorer is more the "file manager" window you see: it is also the desktop itself). To alleviate the load of extracting the data from the database each time - thousands of times per second - all the settings are stored in a fixed place in memory, where explorer can directly access it. When logoff time comes, it simply dumps the settings from memory back into the database, overwriting any modifications you may have made via a .reg file. A simple example of this behavior can be done as such: place a few icons on your desktop, log off and back on, move the items, even align them so that you know explorer is aware of them. Pull the power cord out of the PC (assuming it is not a laptop ... do what ever you need to do to cause a hard stop or reboot. Reset for example). When you log back on (after replacing the cord ...) you will find your icons just as they were last time you logged on, and not where you moved them to and aligned them. Explorer did not have a chance to save your settings. Another way to see this is to take a registry setting you modify and you know works (from HKCU, an explorer setting) modify it in regedit, log off and on and you see it has reset itself. Use regedit to modify the same setting in another users HKCU (by “loading” their .DAT “hive” file), and you will find the tweak “stuck”. My biggest problem with this is locating certain registry entries. You change the explorer view to details, doing a .reg dump before and after, and you see nothing comparing them: the registry has not yet been updated. If you wait till next logon to compare, there are MANY more differences, so it’s hard to find that one little bit somewhere…

TweakUI gets around this by loading itself BEFORE the registry information is parsed, and it injects the tweaks that have been set through the users interface. Before explorer access its settings, TweakUI has insured that your modifications are taken into account.

Now, if you understand that, excellent! Unfortunately, I made it all up … well, not completely: it is based on the way System Tables were implemented in an OS I worked on in the 80s. What I mean is I have no proof that what I say is correct, just my evaluation of what is happening, and it suits my needs just fine. I make XP do it my way, based on theories such as these. Of course, your actual mileage may differ …

In response to your last lines: I would say it is a lot closer to 100% than 90% for explorer settings. I also think that every adjustable setting can be done in a reg file, barring those still using .ini files (rare in native MS windows applications, more frequent in third party software). Just gotta get it there at the right time.

Enough for the theory: Does this help with any of your tweaks? Creating a new user, clearing all “stubpath” entries you find, and logging in the new user should be a simple enough test. What are the values of the two tweaks you mentioned earlier in the new user registry, and the default user registry.

Another note on stubpath. Clearing this entry will cause certain programs not to perform their initialization routines for new users. That is the whole reason I do this. I do not have a need for these initializations, but you may. By not having a "stubpath" entry for IE, it no longer does it's spiel when a new user first logs on, and does not adds it's icon all over the place. Outlook Express icons are no longer put in the quick launch bar. I like it clean.

Last note: as I think about it, the stubpath is probably not your problem: don't others have those tweaks working? You need to find out what is in the default users .DAT file. I dd, however, think it is a likely suspect for RyanVM.

Keep us posted.

[Registry Tweaks, Part-1]

Thanks, Kenneth, for the compliment. In fact I do not really know the internals of Windows - I have not had a computer class in nearly 20 years - but I do now how to pragmatically debug. I have run into the same problems as many here, and am too stubborn not to make it work. I try to share my experience as to what has worked for me, what appears to me to be happening, and how I would proceed to locate certain problems. I will not attempt to post a process description, because I do not care to have to justify myself to those that know better. There are enough people here who concider themselves pro's that can do that...

That said and done, I will tell you what I think your problem might be, and steps you can take in finding the answer: I do not have the answer myself.

I implement both the tweaks you are talking about, as well as the small icons that RyanVM mentions, and they "stick": all users get them as defaults. I cannot say if my way will work for you, but it works for me...

Background: If you have the tweaks added to the registry from the CMDLINES.TXT file, as I assume you have (right Ryan ...), they will be added to the default users settings, normally found in C:\Documents and Settings\Default User\NTUSER.DAT. This .DAT file contaings the HOT_KEY_CURRENT_USER (HKCU) registry hive ("section"), and is used as a template for every user created, including the built-in "Administrator" account. For Explorer and IExplorer it is important that these settings be in the template, as you cannot add them with a .reg file to an existing Profile (User account). This is because windows will update Explorer and IExplorer settings on log-off with the current settings (behaviour by design). The tweaks both you and RyanVM are talking about fall into this category.

Debugging questions are: are these tweaks pressent when a new user first logs on? (It looks like no, but check the registry), and are these tweaks included in the default .DAT file mentioned above. For the first question, you can see the answer directly with regedit. For the second, you will need to use regedit, load the afore mentioned hive, and see if it is there. I hypothosize that this will show you that the tweaks are in the default user file (template), but are changed somewhere after the template is copied to a new user, and the new user can access regedit to verify.

If the above is indeed the case, my next question is why does it work for me, and not you. Again, I can only hypothosize, but I suspect it is due to an additional tweak I add to the registry, in a value named "Stubpath". Stubpath is a pointer to a program to execute. A stub is a standard, though perhaps less common, programming item. There are many places that can tell you better than I what exactly it means: google it if you are curious. In any event, there are about 10 of these I have found, and I believe that they are all used to initialize the environment of the specific program. Programs that use this in XP include IE, Explorer, Outlook Express, WMP, Netmeeting, and more. I cleared all these entries from the registry, as I do not want these programs initializing at regisrty settings, reverting back to WMP from winamp just because a new user has logged on.

Conclusion: I think that a program is re-initalizing your reg tweaks with default values AFTER the registry is copied from the "template" via one of these stubs, and that is why it is not working for you.

What you can do: Examine both the HKCU branch of the registry of a brand new user, and that of the C:\Documents and Settings\Default User\NTUSER.DAT, which you will need to load first. If they are different, clear out all the stubpath entries, and create a new user (or remove the users profile), and see if the settings "stick".

As I said, I get all the settings y'all do not, and this is the main difference I see in my setup. I also think that I am the only one who bothers with the stubpath stuff, so I doubt there is someone who could confirm this right now. You can do the tests on an existing system, so please do, and let me know.

Sorry for the lengthy post, but I am hoping that it can add some insight if you are truely interested, and weed out those who are not truely interested by simple long windedness.

Phew .....

[Registry Tweaks, Part-1]

You cannot import those tweaks: they are reset to current values at logoff. Look HERE for more.

[Some registry tweaks don't activate at all during]

I mean HERE. Just the way I do it, not an authoritive guide. You will need to know about CMDLINES.TXT and how to use it. I've posted alot around here about how I use it.

[cmdlines.cmd]

...Back on track RyanVM that was the answer I was hoping for. Nothing wrong with the UPDATE.CMD, it has to be a combination of WINNT (OEM settings) where the files are placed <ROOT>\I386\$OEM$\ or <ROOT>\$OEM$\, or perhaps something so silly as UPDATE.CMD.txt, or saving in an incorrect format. Did you still see the "1 file copied"?

[Some registry tweaks don't activate at all during]

That's a lot of reading: I thought you where going to make things easier!

The explorer settings you are trying to import are in the HOT_KEY_CURRENT_USER (HKCU) section. It is a chicken and egg thing, where you need to make those changes before you logon, as windows overwrites them with current settings on shutdown. You need to make the changes to the Default Users account. There was a long thread on it not too long ago with examples how to make it work. I don't remember the title, but I did post there if you do a search.

[cmdlines.cmd]

5 to go. I do have a script that does all the slipstreaming, hotfixes, etc, if you are really interested. I made it to use it, and I do, but don't post it because I would not look forward to "defending" it or any "mine's bigger than yours" contests.

[cmdlines.cmd]

Goodness, I'd hate to see if you DO mean to brag. I ask you to try one simple experiment: open a command window from your file that is called out of CMDLINES.TXT, and tell me where you are. Please. It is not to prove you wrong, it is to insure we are using correct info, that's all. As for your worries running hotfixes at this stage, slipstreaming the hotfixes themseves will eliminate that worry for you, and insure that when your users are requested to insert the XP CD, they will not overwrite your hotfixes. RyanVM? Any luck?

[Some registry tweaks don't activate at all during]

Creating the user beforehand does not insure that you log on to it. If the following is your case, it cannot work:

You have AdministratorAutologon (or whatever it is called) set.

AND

You call the set the registry from a call in the GuiRunOnce section of WINNT.SIF.

When it imports with regedit, it is logged into the Administrator account. The easy test would be to log on as the administrator, and see how it looks, no?

[Some registry tweaks don't activate at all during]

Could you be making registry changes to the HOT_KEY_CURRENT_USER section, and doing it as the administrator through GuiRunOnce and looking for them in a user other than the "Administrator" built in account?

[cmdlines.cmd]

Please, unforgiven, your off the track here. I also believe you are wrong, using outdated info. Open a command prompt from your CMDLINES.TXT file, and tell me where you are. $OEM$ is no longer automatically copied to the hard disk as I recall ... Furthermore, as he has autopartition to 0 in WINNT.SIF, there is no guarantee that he is installing on the C drive, why I said %SYSTEMDRIVE%\LOGFILES.TXT. Have you been following this thread, or did you just jump in at the end?

[cmdlines.cmd]

If you get to the first "pause" then you are back to the point where you put in either a bunch of "pause"s, or you try the LOGFILETXT thing again - onto the HDD not the CD ... It also would seem to be the CLS if that is all you changed, and that does not make a lot of sense to me ... the verdict is?

[cmdlines.cmd]

... you still with me RyanVM? ...

[cmdlines.cmd]

Maybe CLS, but that don't make much sense. For what it's worth:

@ECHO OFF

TITLE Post Install Setup

:: ---------- Update MS Components 

ECHO Starting DirectX 9 Install.
START "DirectX 9 Install" /WAIT ".\DIRECTX\DXSETUP.EXE" /opk

You don't need the CLS - you're off having a beer ... Try again from the setup without CLS (the only difference), and put a pause at the begining. Though, if there is any DOS box that pops up at all, it must be at list hitting CMDLINES.TXT.

[cmdlines.cmd]

Man, you're stumpin' me. Am I write in saying that it looks like UPDATE.CMD never runs? Do you have any proof that it even starts, other than the "1 file copied" windows?

[cmdlines.cmd]

What exactly do you have in CMDLINES.TXT? I dislike working there, as it has special rules and syntax. I have just two lines in my CMDLINES.TXT:

[COMMANDS]
".\INSTALLS.CMD"

Everything is done from the one CMD file INSTALLS.CMD. If you have more than one, test them all from the command line. If you do have only one, or UPDATE.CMD is the first one to run, it must be something else. What does CMDLINES.TXT look like?