Mastering the Recovery Console

In Windows 2000, Microsoft introduces an enormous number of long-overdue features and capabilities. However, regardless of the new benefits available to administrators and users, the introduction of a new OS version inevitably presents at least one major disadvantage: It renders obsolete many of the skills, techniques, and tools that network administrators have developed for day-to-day OS maintenance.

Consider system recovery. I won't even ponder the mass deployment of a new OS on my network until I've mastered the basics of fixing the system when things go wrong. My reasons for this approach are simple. First, no OS is crash-proof or corruption-proof (not yet, anyway). Second, a large-scale deployment of any OS necessarily translates to a commensurately large-scale dependence on the availability of that system—particularly in the case of servers.

If your organization depends on Win2K, you need to know how to fix your Win2K systems when they break. Although Microsoft has greatly improved system reliability and recoverability in Win2K, things still can and do go wrong. When they do, you don't want to be unprepared. In Win2K, Microsoft offers new tools to help you in your efforts.

New Recovery Tools
In terms of performance, reliability, and scalability, Windows NT has maintained a long-standing superiority over the Windows 9x and Windows 3.x branch of the Microsoft family tree. However, Win9x has always dominated NT in at least one area: ease of recoverability. Anyone who has spent time as an administrator on Win9x systems has probably longed for the good old days of booting to MS-DOS (or MS-DOS mode) to repair system problems such as overwritten or corrupted system files. NT 4.0 lets you approximate some of these conveniences through techniques such as using the FAT file system on boot partitions, using third-party utilities that provide access to NTFS outside of NT (e.g., Winternals Software's NTFSDOS, ERD Commander), and using parallel OS installations. (For information about parallel installations, see the sidebar "Think Parallel" in "Recovering from NT Startup Failures, Part 1," September 1999.) However, these methods are either logistically inconvenient or require additional setup time or expense, which can be unappealing if you're dealing with dozens, hundreds, or thousands of systems.

In Win2K, Microsoft has finally leveled the recoverability playing field by providing features that put Win2K on par with its Win9x counterparts. In addition to the internal reliability enhancements that make Win2K less prone to crashes, Microsoft has introduced several new system-recovery features that make repairing an unbootable Win2K system easier. (For more information about Win2K reliability enhancements, see Mark Russinovich, NT Internals "Inside Win2K Reliability Enhancements," parts 1 through 3, August through October 1999.) For example, Win2K lets you boot into safe modes of operation in a manner similar to that of Win9x. And, like Win9x, Win2K offers additional boot-time choices that let you disable certain OS features so that you can successfully boot the system. To access most of these choices, you press F8 on the Win2K Boot Loader menu at startup. Pressing F8 displays a menu, which Figure 1 shows, of the following alternative safe-boot options:

• Safe Mode boots with the minimal set of drivers and services necessary to start Win2K.
• Safe Mode with Networking is similar to Safe Mode but adds drivers and services necessary to enable networking.
• Safe Mode with Command Prompt is similar to Safe Mode, but the system starts with a Command Prompt window instead of Windows Explorer.
• Enable Boot Logging creates an extended log file of success events and failure events for the initialization of system components as they load during system boot. (This behavior is the default for all safe-boot options except for the Last Known Good Configuration boot.) The log file is named ntbtlog.txt and resides in the \%windir% folder (e.g., C:\winnt).
• Enable VGA Mode starts Win2K in VGA mode by using the vga.sys driver instead of the regular video driver.
• Last Known Good Configuration starts Win2K by using a previous version of the SYSTEM Registry hive. (The Last Known Good Configuration is the most recent session in which a successful startup—one without any service or driver-initialization failures—and logon to the computer occurred.)
• Directory Services Restore Mode recovers the Active Directory (AD) database. This option is valid only for Win2K domain controllers.
• Debugging Mode enables a startup mode in which the system sends debugging information across a serial cable to another computer running a debugger. (The mode uses COM2 as the debugging port.)

One of these options might be appropriate at any given time, depending on the type of problem you're experiencing with a system. However, although Win2K's new safe-boot options enhance your ability to diagnose and recover a malfunctioning system, you won't find Win2K's most versatile boot option on this menu.

RC to the Rescue
Microsoft has introduced in Win2K a new startup mode called the Recovery Console (RC). For every NT administrator who has wanted to boot to a command prompt to perform system-recovery operations on NTFS-based computers, the RC is the answer. After you install the RC, you can boot to a special slimmed-down Win2K console session that provides access to all FAT16, FAT32, and NTFS disk partitions on the system, as well as a basic set of commands and utilities for performing system-recovery operations. (If you're familiar with NTFSDOS and ERD Commander—as well as Winternals Software's NTRecover and Remote Recover—you might recognize these capabilities because these products provide similar functionality for NT 4.0.)

To use the RC on a Win2K system, you must first install it by rerunning Win2K Setup (i.e., winnt32.exe) on the system with a /cmdcons switch (e.g., D:\i386\winnt32 /cmdcons). Win2K informs you that this action will install the RC and asks you whether you want to continue, as Figure 2 shows. After you click OK, the system copies the necessary files (typically, less than 6MB of data) to a hidden folder named \cmdcons, which resides off the root of your system's boot drive (e.g., C:\cmdcons). The next time you boot, your Win2K Boot Loader menu will contain a new Microsoft Windows 2000 Recovery Console option.

When you select this boot option, Win2K gives you a brief opportunity to press F6 to load a third-party SCSI or RAID driver. (This option is necessary if the RC can't properly detect your disk controller configuration.) Next, the system enters a text-based mode and prompts you for a Win2K installation to log on to, as Figure 3 shows. This feature lets the RC support the recovery of multiple OS installations on a multiboot system. After you select the Win2K installation you want to access, the system prompts you for that installation's administrative password. (This password is the local administrator account password for that installation, not the do-main administrator account password—assuming a domain membership exists.)

Although you'll probably want to install a hard-disk-based copy of the RC on each of your crucial systems, you can also start the RC from Win2K Setup's Repair menu. Thus, you can also access RC after you run Win2K Setup from CD-ROM or 3.5" disks. This capability is helpful if you're having problems with a Win2K system that has a damaged RC installation—or never had one to begin with.

   Previous  [1]  2  Next