32bit vs 64bit registry updates

[beatbox99]

I have an unattended install for Server 2003 that works flawlessly for 32bit versions of the OS, but I've run into a problem with registry updates when applied to a 64bit install.

I have a custom built application launcher (32bit) that accepts a text file as input with a line describing what is being done and the batch/cmd file to execute. Many of the items being applied are registry settings that I update to either tweak performance or configure the server to meet our environment requirements. On 32bit installs, it works flawlessly; however, when run on a 64bit installation, each of the commands gets processed, but every one of the registry entries gets put into the 32bit subkey, thus are never actually read by the OS when it boots up.

I've tried using regedit /s to import .reg files as well as reg ADD/UPDATE in my scripts and the result is the same; however, if I run the .cmd file manually from a command prompt, it will properly insert/update the registry keys every time.

I did some research and found that the problem is that there are both 32bit and 64bit versions of the cmd, regedit and reg commands on a 64bit OS and that because my launcher is a 32bit app, it will automatically call the 32bit version of these commands which then update the 32bit subkey of the registry even if you explicitly call the executables from the 64bit path. Apparently it has something to do with a 32bit process being unable to launch a 64bit process. When run manually from a command prompt when logged into the server, it will by default open the 64bit command processor when then calls the 64bit versions of regedit/reg which of course update the proper registry keys.

I thought I had figured out a way around this...Figuring that by utiliziing the RunOnceEx registry key, it would automatically open a native 64bit command processor in which to execute all of the batch files, I rewrote all of my registry updates into a .cmd file called by my launcher to populate them in the RunOnceEx key. The key does get populated and when the server reboots, it does process through the key, executing each of the .cmd files with the registry updates; however, most of the updates (I haven't checked them all, but did try to verify a bunch of them) do not appear in either the 64bit or the 32bit registry keys.

I'm desperate to find a solution to this problem...I have about 25 registry updates that need to be applied and of course I'm on a deadline at work to have a fully functional automated 64bit Server 2003 build ready before Friday morning. My fall-back plan is to write another batch file that applies all the registry entries and have the operators run this manually at the end of the server build, but this defeats the purpose of the automated build (and won't please my boss at all), as eliminating any manual intervention in the server build process, thus ensuring a consistent build every time was the entire purpose of this project.

Does anyone has any suggestions on how to get this to work as it should?

Cheers

Jeff

[Kelsenellenelvian]

WPI http://www.msfn.org/board/index.php?showtopic=129222 (Also see link in my sig but it is not updated to latest version right now. Doing that now!)

This will allow you to call those regtweaks as 64bit when you select them as 64bit.

[beatbox99]

Thanks K...I've downloaded the package and will take a look....Maybe you can answer a quick question though...

I have a series of modular make files which compile the DVD's that we use for our server installs. At the moment, we support Windows 2000 Standard/Advanced, W2K3 Standard/Enterprise and W2K3 x64 Standard/Enterprise. The make files determine which i386/AMD64 folder to drop into the root of the DVD, but the "packages" for all 6 flavours are always included on each of the DVD's produced.

Right now, my cmdlines.txt file which fires at T-13 executes three commands, the first applies all the hotfixes approved by our corporate security team, the second copies the OS files to a folder on the local C: drive and the third puts a .vbs script in the RunOnceEx key which fires on the first reboot after the OS is installed.

The .vbs script determines the installed OS and then calls one of 6 different batch files from the DVD to extract the appropriate packages (all in .cab files), it then copies another batch file to the All Users/Startup folder and triggers a reboot to kick off the app launcher. Each of the packages installed is triggered by a .cmd file which contains logic to determine if it's running on a physical server or a virtual machine (ie: should I install the HP Management Agents or VMware Tools) as well as logic to determine if a 32bit or 64bit version of a particular package (ie: .NET framework) should be installed.

One of the first commands in the batch scripts populate the registry to configure the automatic logon for the administrator account, so the scripts can reboot the server and pick up where it left off (as several of the packages require reboots), and one of the last commands issued is to clear the automatic logon, rename the administrator account and change it's password.

I assume WPI can do the same thing? Meaning, can I create 6 unique "default" installs and call the appropriate one by passing a command line parameter to WPI on startup or would I need to create 6 unique DVD's which include only the packages for that particular platform?

Cheers

Jeff

[Kelsenellenelvian]

You are assumming very correct!

WPI has built in commandlines so you can call it 30 ways from sunday.

And the latest WPI works fine on win2000 and upwards.

[Noise]

Sounds like you already have a top-notch install there. Sounds a lot like some of the setups I've developed. You should be proud of yourself.

Anyhow, I've never had a problem loading my reg files in to Win2K3 R2 SP2 64 Bit. Here's what I do, I throw all my reg files (simple, everyday normal reg files) in to $OEM$\C\Install\settings directory on the source media (CD, DVD, USB, PXE, whatever). The I load them during cmdlines.txt (t-12 actually).

In cmdlines.txt I call a very simple batch file that loops through all the reg files in the C:\INSTALL\Settings directory and loads them. A trimmed down version is below. Note that setup.cmd is in the same directory as cmdlines.txt.

CMDLINES.TXT

[Commands]

".\SETUP.CMD"

SETUP.CMD

echo *** Default Registry Settings

for %%i in (C:\INSTALL\SETTINGS\*.reg) do regedit /s "%%i"

This method of loading registry settings has the added benefit that it modifies the default user registry hive. That means that any registry file with HKCU entries get propagated to all users on that system automatically. T-12 (cmdlines.txt) is the only time you can do this trick.

[beatbox99]

WPI looks interesting and seems to be well documented, now all I gotta do is find time to read through it...

Nois...Thanks for the tip. I was wondering if running reg files from cmdlines.txt was possible as I know that not all command line utilities are availabe at that stage. This looks like an excellent solution and the added benefit of hitting the default hive will come in very handy. The only piece remaining would be the final reg file applied after all the packages have been delivered to clear the auto-logon settings, which ditching the custom launcher I'm using now for WPI would seem to solve.

Thanks for your help guys!!!

Cheers

Jeff