Fooling Windows Setup and Getting Away with It.
Say you’re wanting to run multiple installs of windows on multiple partitions, but you want to make sure that one install of windows doesn’t affect the other in any way. Why would you want to do this? The perfect example is if you’ve got a new version of windows currently installed and you want to dual boot an older one. Another reason to do this is to enable proper testing of a OS in an automated scenario.
A quick disclaimer – all the next info is specifically to do with x86 and x64 systems – ia64 is a completely different kettle of fish and deserves it’s own post at a later date.
If you install an OS that’s older than the currently running OS in a dual boot scenario, Windows Setup will overwrite the boot files from the newer OS with the older OS files. Generally, Windows bootloaders are backwards compatible but not forward compatible, so if you want to be able to boot back in to your original OS you’re pretty much hosed. For instance, if I’m running Windows 2003 Server SP1 and I run an install of Windows XP RTM, the boot files on my current system will be overwritten with the XP RTM versions. Even though the boot.ini file will be updated to contain links to both OSs, attempting to boot into Win2k3 will fail as the bootloader files are much older than the operating system files. Most of the time this is only an issue with major OS releases, servicepack releases will generally be compatible with other releases of the same OS.
There’s a couple of interesting things about the bootloaders and the basic sequence that happens when you turn on a machine. I’ll just quickly run through a functional sequence here:
1) Computer turns on and runs BIOS checks, determining which hard drive it has set to be the primary
2) BIOS checks this primary hard drive’s partition table, looking for the partition that is currently marked as the active partition
3) If the active partition is located, the loader is looked for in the root of that drive. The loader may or may not be a windows loader, so this is where the windows specific stuff comes in. If it’s a windows loader (for NT this is the hidden, system, readonly file ntldr) then the loader will typically (at least for a full OS, WinPE is a slightly different story I’ll talk about later) look for a file called boot.ini also located on the root of the drive.
4) The boot.ini file shows the partition that actually contains the windows version to boot. The loader will go to this partition and search for the directory listed in the boot.ini for the Windows loaders and proceed with them.
This sequence is interesting from a dual boot scenario because the bootstrappers rely on a single partition (the active one) to boot multiple OSs. This can cause a number of problems, specifically:
1) The older OS overwriting the newer OS’s boot files as described above.
2) If you’re testing a new OS by installing it from a known good older OS (what we call the “Safe OS”) and the new OS setup overwrites your Safe OS’s bootloaders, you’re relying on a potentially untested operating systems’ ability to successfully install and not have a buggy loader. This can be a very bad assumption to make, especially when restoring the original Safe OS configuration can take upwards of 40 minutes.
3) If you’re testing or using WinPE as a Safe OS, the current WinPE bootloader does not give you the ability to use a boot.ini file so there’s actually no way this will work.
So, having said all this, what’s a good solution? Well, the best way to do this is to make sure the test OS never overwrites the safe OS’s boot files. Before initiating an install, we make sure the Active partition is changed to the partition we’re planning on installing to.
How is this accomplished? Through the magic of diskpart. This is a fully scriptable command line disk and partition management tool that is included in Microsoft operating systems from Win2k up, including WinPE. To script diskpart, create a text file with one command per line and pass it in with the /s parameter. One tip – you only need to use the first three letters of any diskpart command, so for instance “select disk 0” can be abbreviated to “sel dis 0” - just a quick hint for those wanting to save some keyboard time. To activate Partition 2 on Disk 0, the diskpart script would be:
Select disk 0
Select partition 2
It’s that simple. One fun thing to be aware of is that the disk numbers are generally zero based, but the partition numbers are generally one based. Also, volume numbers (which generally correspond to partitions) are zero based, so it can be very easy to get confused.
Once the partition is marked active, it’s time to fire off the Windows install. There’s a problem though – winnt32.exe (the windows setup executable) tends to freak out when you’ve changed the active system partition from underneath it. Here’s where some extra command line parameters come in handy. Call winnt32.exe with the syspart parameter as follows:
This will let Windows setup know exactly where it should put the system files.
Booting back and forth with this configuration
This config is only really useful if you’re running beta versions of Windows, or you really don’t want installs screwing around with your boot files. The main issue is that you need to change active partitions to boot between operating systems which can be a major pain. If you’re using WinPE, however, this issue is a given. If you’re not, you can manually modify your boot.ini to allow an easy boot back and forth. (If you’d have installed your 2 windows in the correct order originally, ie. oldest version first, without using the active partition trick setup does this next part for you.)
A typical boot.ini file looks like this:
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect
Just modify this by adding in another entry under the Operating Systems heading, as so:
multi(0)disk(0)rdisk(0)partition(2)\WINNT="Microsoft Windows 2000 Professional" /noexecute=optin /fastdetect
If there’s more than one entry in the OS section the bootloader will display a menu, then after the timeout time (in this case 30) will boot the default entry (in this case XP).
- mike (Michael Warmington, email@example.com)