If you're careful, you can configure Win2K in a dual-boot or multiboot configuration with several OSs, including additional Win2K installations, NT, Win9x, WFW, Windows 3.1, and MS-DOS. In addition, you can use third-party tools such as Gilles Vollant Software's BootPart 2.20 and boot managers such as BootMagic, System Commander 2000, and System Commander Deluxe to incorporate additional non-Microsoft OSs such as Linux and Be Software's BeOS into your multi-OS system. If possible, devote a separate partition to each OS on your system. However, in some situations, this setup might be undesirable or logistically impractical.
To Share or Not to Share
Whether you configure your multiboot system so that each OS is on a separate partition is as much a political decision as a technical one. Regarding Microsoft's support for dual-boot or multiboot systems that include Win2K, the company has taken a strong position: Microsoft supports dual- and multi-OS systems only if you use one partition per OS. (For more information about the company's multiboot-system support, see "Multibooting Resources.") Microsoft states that as a result of the potential conflict between certain files and directories (most notably, the \Program Files folder), the company won't provide support for configurations in which two or more Windows versions reside on the same partition.
This stance is somewhat disheartening because my experience proves that you can successfully maintain multiple Windows versions on one partition without major problems. In fact, Microsoft's dire warnings against creating a multi-OS system on which the OSs share a partition made me curious, so I created a multiboot Win2K and Win9x system. I even installed several applications from both OSs (including Microsoft Office 2000) in the same directory to minimize disk-space usage. I had made a full system backup, so I was prepared to accept the dire consequences of this configuration. At the end of the installation, I was pleasantly surprised to discover that the Win2K installation didn't damage any of the applications installed under the original Win98 installation. The only problem I encountered was an instance in which Win98 didn't let me empty the Recycle Bin just after the Win98 installation had completed. However, after I booted to Win2K and returned to Win98, the problem disappeared.
Fresh from my success with the Win2K and Win98 venture, I decided to push the envelope and install a triple-boot Win2K Pro, NT Workstation, and Win98 system on one FAT16 volume (the only common file-system format for all three OSs). I set up this configuration solely as a test—this setup isn't a recommended or desirable system configuration. In fact, this configuration has major drawbacks. First, FAT16 limits my system partition to 2GB or smaller. In addition, by the time I completed the Win2K Pro installation, the C drive was close to full, which didn't leave much space for applications. To make this configuration more usable and realistic, I would place Win2K or NT on a separate FAT32 or NTFS partition. However, my experiment proved to me that even the most extreme shared-partition multi-OS configurations might work for those who are willing to accept the associated dangers.
Despite my fairly successful experiments, setting up a shared-partition configuration involves risks. Always back up your system before installing shared-partition configurations and limit any experimentation to nonproduction or noncritical systems until you're confident that your multi-OS configuration won't cause major compatibility or system-stability problems.
Although these experiments prove that you can configure OSs to share a partition, the question remains: Should you chance sharing partitions among OSs or follow the Microsoft recommendation and install only one OS per partition? The proper choice depends on your situation.
If you're an advanced user who is prepared to accept the possibility that a shared-partition configuration poses potential risks to your system's stability, my recommendation is to try it. However, if you can't afford to take these risks or your system must be in a Microsoft-supported configuration, you must accommodate Microsoft's recommended configuration. (Configuring a multiboot system so that each OS is on a separate partition will probably entail disk repartitioning, for which you might want to employ one of the products that "Multibooting Resources" lists.)
NTFS + Win2K = Deep-Freezing NT 4.0
If you're planning to install Win2K on a production NT 4.0 system that uses NTFS4 volumes, be aware that Win2K automatically converts NTFS4 volumes to NTFS5, which is the only version of NTFS that Win2K can work with. This conversion happens automatically during installation, and Win2K provides no opportunity to confirm or decline this action. Only the ntfs.sys drivers in NT 4.0 Service Pack 4 (SP4) or later can work with NTFS5 volumes, so you must install SP4 on any NT 4.0 system before you install Win2K. Failure to do so results in a blue screen and an inaccessible NT installation when you try to boot NT 4.0.
After you convert an NT 4.0 SP4 or later NTFS volume to NTFS5, you won't be able to reinstall NT 4.0 on that system. The conversion puts your NT installation into what Microsoft terms a maintenance mode, in which you have OS functionality but you can no longer recover or repair the NT installation. In addition, NT 4.0 SP4 or later installations can't run Chkdsk against NTFS5 volumes, so you must boot to Win2K to perform any disk repair or maintenance.
Unfortunately, this conversion is a one-way trip. The only way to revert an NTFS5 volume back to NTFS4 is to back up the individual files on the volume, reformat the partition under NT, and restore the data. So don't take this conversion lightly. If you're running a production NT 4.0 system on an NTFS volume and you haven't firmly committed to Win2K, think twice before you install Win2K. Instead, I recommend that you back up your NTFS boot partition and reformat the partition as FAT16 or install Win2K on a different system.
Beta Leapfrog
If you participated in the Win2K beta program, you probably have existing Win2K installations whose configurations you want to preserve. Although you might assume that you can upgrade any Win2K beta to the final Win2K version (i.e., build 2195), you must follow a very specific progression. This version-upgrade leapfrogging is necessary because each Win2K version makes assumptions about existing Win2K installations—particularly about Win2K domain controllers. Table 3 details the upgrade path that Microsoft recommends to successfully upgrade workstations, member servers, and domain controllers from various Win2K beta versions to the final release.
If history is any indication, don't expect much support from Microsoft Product Support Services (PSS) for beta-upgrade systems. Microsoft's stance regarding upgraded beta installations has been a hands-off policy. If you want a stable and fully supported Win2K installation, you must install Win2K from scratch. In addition, if the system is an important server or domain controller, I recommend that you plan a fresh Win2K installation. You don't want to get off to a bad start with Win2K simply because you inherited a buggy installation after upgrading a beta version.
Beat the Multi-OS Upgrade Blues
If you want to upgrade a Win9x installation to Win2K on a system that hosts Win9x as well as Win2K or NT 4.0, you face unique challenges. You might discover that Win2K won't permit you to upgrade an existing Win9x installation to Win2K if the multiboot configuration already includes a Win2K installation.
When you try to upgrade the Win9x installation, Win2K Setup informs you that it has detected another Windows installation. The error message also states that Win2K doesn't support the configuration you're attempting because of the risks that the configuration poses to the system's other Windows installations. (Screen 2 shows this warning message.) As a result, Win2K Setup presents you with only the option to install a fresh Win2K installation. In the Welcome to Windows 2000 Setup Wizard dialog box, which Screen 3 shows, Win2K Setup makes the option to upgrade unavailable.
To trick Win2K Setup into letting you proceed with the upgrade, you can permanently or temporarily remove one of the Windows installations. However, this solution doesn't work in some cases. For example, on a dual-boot Win2K Server and Win98 system, I attempted to upgrade Win98 to Win2K Pro. However, even after I removed the Win2K installation folder from my D partition, which left Win98 as the only OS on the C drive, Setup insisted that the system was hosting multiple OSs. The presence of Win2K startup files (e.g., the Boot Loader) triggers this detection even when the installation directory is gone. To work around this problem, I used a Win98 boot disk and the Sys command to manually overwrite the Win2K boot sector with a Win98 boot sector. This action removed the Win2K Boot Loader menu, and the system booted directly into Win98. Next, I relaunched Win2K Setup, which let me select the upgrade option.
Microsoft documents this problem in the article "Cannot Upgrade Windows 95/98 Computers That Dual Boot Windows 2000 or Windows NT" (http://support.microsoft.com/support/kb/articles/q232/1/23.asp). However, this article doesn't explain some inconsistencies in Win2K's behavior. Microsoft's documentation states that the multi-OS upgrade problem affects systems running Win2K or NT as the additional OS. However, I have experienced this problem only on systems running Win2K as the other OS. When I've attempted to upgrade Win98 to Win2K on an NT 4.0 and Win98 system, Win2K hasn't presented the error message. I'm not complaining, just observing the inconsistencies between the article and my experience. In addition, I easily upgraded Win98 to Win2K Pro on a system that runs NT Workstation 4.0 and Win98 Second Edition (Win98SE), yielding a dual-boot configuration on a single partition. During this upgrade, Win2K Setup presented no warning about the fact that I was running a multi-OS system.
Although not supported by Microsoft, another workaround to this problem is to back up the existing installation directories of the OSs that you aren't upgrading and later restore them to the hard disk. If you're backing up Win2K, you also need to remove the Win2K boot sector and startup files as I described in the previous workaround. After the Win2K upgrade is complete, manually edit boot.ini to restore the reference to the original Win2K installation folder. If you're backing up NT 4.0 and NTFS volumes are present on the system, you need to update the NT installation to SP4 or later for the installation to work with Win2K in the multi-OS configuration. However, Microsoft doesn't support or recommend this procedure, so you're on your own if you damage or corrupt something during this process. But even if this method doesn't work for you, you'll have a backup of the original installation that you can use to restore to another machine or drive.
The Best of Both Worlds
Win2K's support for FAT32 gives you a new choice for the system volumes of dual-boot Win2K and Win9x systems. IT professionals who need to support both OSs and users who aren't ready to commit their whole system to Win2K will welcome the flexibility that FAT32 support provides.
Although you might need to avoid a few minor potholes along the way, the road to creating a multiboot Win2K system is fairly smooth. And until Win2K proves itself and overcomes the skepticism of the NT community, multiboot systems will be the rule rather than the exception.
Corrections to this Article:
- Table 2 in "Multibooting Windows 2000 Systems" contains several incorrect entries. Go to http://www.win2000mag.com/files/8824/table_02.html for an updated version of the table. We apologize for any inconvenience this error might have caused.