Windows Vista x64 imaging in the Enterprise: Trials and Tribulations galore

If your company has pursued the holy grail of the "single workstation image" like mine has (and we got there with Windows XP, woohoo!), you may be wondering if your tools are up to the challenge of doing a single build process with Windows Vista across the x86 and x64 environments. Microsoft likes to say that the new tools in Windows Vista and new HAL technology makes it possible to cut your number of images in half. However, in a well managed shop that used some hacks with Windows XP it was very achievable to be at one image already (and we were!). Now, with Vista though, x64 is going a bit more mainstream. It isn't to the point yet where everyone will or even should get it – but there are going to be some folks that need it. One of the things my team has done over the last several weeks is to go through our tool set and try to make an x64 image work using the same base building scripts and tools as we use for x86 32 bit images. The results surprised me – and this wasn't a good thing. I thought I already understood where x86 and x64 differed in terms of 32 bit software but I definitely learned a bunch during this process. For the results, read on.

So, how did it go?

The first things we hit was just trying to lay the image down on a machine. This testing was with just a generic MS Install.wim with no customizations. What we found was a catch-22:

• Our tools (mostly in-house and mostly VB6 since .Net doesn't work on WinPE) are all 32-bit.
• The x64 WinPE doesn't support any 32 bit code at all.
• The 32 bit setup.exe is incapable of installing the 64 bit Windows

Great! Blocked right out of the starting gate! We can't run our tools in a 64 bit WinPE and can't run the 32 bit setup.exe against a WIM with 64 bit windows. So, we found that although we deploy our 32 bit images using the "Install Based Setup" or IBS (MS: who comes up with these acronyms – Google IBS and see what you hit first) we had to use a down-level look and feel to deploy the x64. That's right: ImageX will deploy a 64 bit image from a 32 bit WinPE. So while the 32 bit installs have the new pretty setup screens, the 64 bit ones are stuck looking like a DOS install in a command window. This at least let us use the same boot.wim – the same tools running in it to check things like whether the hardware is supported or not, etc.

Next Snags

In order to build an image, we use a process that is repeatable and deterministic – nothing new there. In our process we install the base OS (either with an unattend or a sheet showing step 1, step 2, etc.). Then we run a series of installs that are scripted. In our case we are using Wise Installmaster 9.x, but it could be just about any 32 bit tool. We probably have a set of 40 or so scripts (many are run at once by some master scripts) that manage this process. They install software, configure user settings, load up the default user's HKCU hive and make changes to it so that all new users on the machine get the settings, etc. All pretty standard stuff actually. Howewver, we hit several issues in our code:

• A few hard-coded references to "C:\Program Files" were causing x86 code to end up in the 64 bit program files location. Easy fix: slap the coder that did it and recompile.
• Registry changes that needed to go into the real HKLM\Software were getting sent to the HKLM\Software\Wow64Node. These were things like the Autologon settings that go in the WinLogon area of the registry. It also redirected everything that we tried to put into HKLM\Software\Microsoft\Windows\CurrentVersion\Run. These edits were being made by standard "edit registry" command in Wise scripting. They could as easily have been made by any other 32 bit tool with the same results as all 32 bit code that writes to HKLM\Software gets redirected. Fix: not so easy!

For that last one, we ended up scratching our heads for quite awhile. We could have done several things:

• Compiled some VB.Net 2005 code using the "Any CPU" compile option so that the code would run as 32 bit on x86 and as 64 bit on x64. This would be a maintenance problem for us as minor changes would need a recompile of VB code. Not too bad.
• Change the script to call the new API function to disable registry virtualization of 32 bit code. Oops, there ISN'T one! What there is, is a new flag to the registry functions like RegCreateKey that allows you to turn off the virtualization. The problem here is that none of the scripting languages (and even VB.Net) will let you control those flags. So you can't use them in scripting at all.
• Turn off file system virtualization for 32 bit code. This trick we came up with does work. What we did was call the "Wow64DisableWow64FsRedirection" function from kernel32.dll. How does that help? Well, then we can call reg.exe and pass it the items we want to set. On a 32 bit system, that API call just silently fails and you call the correct 32 bit reg.exe. On an x64 system, the call works and you end up calling the 64 bit reg.exe which does not get virtualized. At the end, you test the result code from Wow64DisableWow64FsRedirection. If it succeeded (you were then on 64 bit), you call Wow64RevertWow64FsRedirection. We found a lot of places in our scripting where we needed to use this clumsy mechanism.

The results of all this:

We have a single set of build scripts that can take a base install of Windows x86 or Windows x64 and get it loaded up and installed with all of the items we put in our single corporate image. We can also use a single boot.wim (a customized 32 bit one) that will determine whether it must run setup.exe for 32 bit OS installs or ImageX for x64.

Hopefully Microsoft will get this right next time and have a way to actually deploy this stuff easily. For now, be prepared to do a lot of work to get a single set of tools working for both x86 and x64.