I have an older Dell Windows 2000 server that runs Microsoft Exchange Server and several crucial services. The server has suffered an apparent motherboard failure: The system powers up but won't boot. The machine has a hot-swappable SCSI drive cage with several installed disks, all of which appear to be fine. I need to get this system back up quickly. I have a replacement server, but it doesn't have a hot-swappable drive cage. If possible, I'd prefer to use the live data on the original system's disks rather than restore a backup because I'll lose a few days' worth of data if I restore from tape. What's the quickest way for me to recover this system?
First, make sure that the other system you want to use as a temporary (or permanent) replacement and recovery system has
- an installed backup device (e.g., DDS, AIT, or DLT tape drive) or network access to such a device
- a functioning Win2K installation in a directory with a name different from the original system's installation directory
- a number of CPUs and a hardware abstraction layer (HAL) similar to the original system
- a SCSI adapter (even if the system uses an IDE-based hard disk and CD-ROM drives)
Most passive SCSI backplanes with hot-swappable drive cages (including Dell's) use a standard female SCSI connector on the drive cage. Thus, you should be able to gain access to your original system's disks if you connect a sufficiently long SCSI cable from the replacement system's SCSI adapter to the original system's drive cage, then boot into Win2K on the replacement system. This method essentially makes the original system an external disk array of the replacement system. Depending on the hardware differences between the two systems, you might even be able to successfully boot your original server's OS if you use the original disks as the only disks in the new system. (Because of the unpredictability of SCSI adapter enumeration, the original system's disks might be enumerated first in the replacement system's logical disk priority order even when you've installed the replacement system's disks.) However, connecting two systems in this manner obviously isn't a long-term solution, so you need to take some additional steps to complete the recovery operation.
Your first task in any recovery situation is to immediately back up the data from the original disks if and when you gain access to them. Typically, you'd use a locally attached tape drive, but if your replacement system is connected to a network, you might have other available backup options (e.g., backing up over the network). After you back up all the original data, you're ready to put your replacement system in a more permanent state of readiness.
To do so, you need to restore the original system's data, including the original Win2K installation folder and other necessary application and data folders, on the replacement system. You can either copy the necessary data from the original disks (to retain file ACL and ownership information, be sure to use Xcopy—with the /O option—or Robocopy from the Microsoft Windows 2000 Resource Kit) or restore your newly created backup to the new disks. Because the restored Win2K installation will be in a folder different from the replacement system's existing installation, you effectively end up with two parallel Win2K installations: the original server's old installation and the replacement system's new installation.
When you restore the original system's data, be especially careful not to replace the replacement system's boot.ini file, which contains the list of OS choices that Win2K's Boot Loader menu displays at startup. If you do, you might end up in an inescapable situation in which the system gives you a blue screen when you try to boot into the old OS. After you copy the necessary data from the original system, boot your new Win2K installation and use it to manually edit the replacement system's boot.ini file so that it includes an option to boot into the old OS installation. (For information about editing the boot.ini file, see Kathy Ivens, Getting Started with Windows 2000, "Kick-Start Startup with Boot.ini," July 2001, InstantDoc ID 21192.)
Next, try to boot into the old OS. If you're lucky, the system will successfully boot into your old Win2K installation (although hardware differences between devices such as video and network adapters might cause those device drivers not to load correctly). However, you might receive a blue screen, typically of the Inaccessible boot device variety—for example, when your original system doesn't use IDE but your replacement system does.
In such cases, you might need to manually enable the IDE (atapi.sys) driver through a bit of remote registry editing (i.e., editing the registry of the old OS installation from the new one). Boot the new, functioning Win2K installation and fire up regedt32. In the HKEY_LOCAL_MACHINE window, select the HKEY_LOCAL_MACHINE key, then select Registry, Load Hive from the menu bar. Point to the old Win2K installation's \system32\config folder, select the SYSTEM hive, then click OK. Name the hive; the name can be anything you want (e.g., TEMP, OLDHIVE). Now, you can edit the original system's registry.
You need to change the value that controls the startup state for the atapi.sys driver. However, you first need to determine the current ControlSet, as you'll find several versions (e.g., ControlSet001, ControlSet002). To make this determination, examine the data of the 'Current' value under the HKEY_LOCAL_MACHINE\SYSTEM\Select subkey; if, for example, the 'Current' value is 3, the current ControlSet is ControlSet003. Navigate to the Services\Atapi subkey under the correct ControlSet key, then set the Start value to 0 (automatic). Finally, highlight the name of the hive you chose for the SYSTEM hive (e.g., TEMP, OLDHIVE), then choose Registry, Unload Hive from the menu bar to save your changes. When you restart the replacement system, the old OS should boot. If video-adapter differences exist between the original and replacement systems, you might need to boot into VGA Only mode to read the display.
You might find a few other disaster-recovery resources useful. One is Microsoft's new Data Recovery and Disaster Planning Support Center (http://support.microsoft.com/default.aspx?scid=%2fdefault.aspx%3fscid%3dfh%3ben-us%3brecovery). Also, read Windows 2000 Pro, "Recovering from B-Day," June 2001, InstantDoc ID 20724. And although your situation involves a Win2K machine, you might want to read "Recovering from NT Startup Failures, Part 1," September 1999, InstantDoc ID 7076, and "Recovering from NT Startup Failures, Part 2," November 1999, InstantDoc ID 7280.