Despite the common thought that the Emergency Repair Disk utility is MIA in Win2K, this backup tool is alive and well — and ready to save the day.

ERD to the Rescue

Despite the common thought that the Emergency Repair Disk utility is MIA in Win2K, this backup tool is alive and well — and ready to save the day.

• By Michael Chacon
• 01/01/2001

One of the minor annoyances of Windows 2000 is locating utilities that you can reach for blindfolded from the old Windows NT locations. One of these missing-in-action utilities is the Emergency Repair Disk utility, which you may have noticed no longer runs as the RDISK command. I’ve even talked to people who are under the impression that ERD is no longer needed with Win2K. This isn’t true. After years, however, of Microsoft Official Curriculum material stating that RDISK is not a backup utility, Microsoft finally broke down and recognized that the ERD is indeed a form of backup and is now found in the backup utility as a menu option as shown in Figure 1.

Figure 1. Emergency Disk Repair is now found in the Win2K backup utility as a menu option.

Selecting the Emergency Repair Disk option brings up a display box that allows you to also select an option to save the registry to the %systemroot%\repair\regback directory, which is also familiar to Windows NT administrators. The GUI is a little different, as shown in Figure 2, and there are some significant changes under the covers as well.

Figure 2. Selecting the ERD option brings up a display box that allows you to save the registry to the %systemroot%\repair\regback directory.

Because the registry files in Win2K are so large, there’s no chance that the hive files that comprise the registry were saved to the ERD disk in a previous version. With Win2K, there are now only a few files saved to the ERD. Instead, the majority of the files are all copied to the %systemroot%\repair directory. But be very careful here as %\systemroot\repair contains the backup of the registry when Win2K was originally installed. If the above option is selected, it backs up the current registry to %systemroot%\repair\regback. It’s important you know the distinction if you attempt to restore the current registry with one of these backup copies!

The most important file is the SETUP.LOG file that’s used to compare system files on the hard drive against the same files on the installation CD. If the CRC doesn’t match, then the file from the CD is written to the hard drive — replacing the offending file even if the offense is from a service pack.

Recovery Console: More Than Just a Sidekick
At first glance, these changes appear to have introduced limitations by leaving the hive files on the hard drive. ERD is still useful and has its place in the tool kit, but it’s a blunt tool that in some ways blindly replaces files on the system. But this concern soon fades with the introduction of a Win2K companion tool with a finer edge called Recovery Console. Recovery Console is a command-line utility that runs under the micro-kernel OS that’s used during setup and can be called from the regular startup menu during boot or run from the setup disks if you didn’t have the foresight to install it. Regardless of how you choose to run it, Recovery Console allows the administrator to perform specific tasks that are useful in repairing or troubleshooting a wounded system.

While ERD allows you to replace system files to a problem system, even if the disk is formatted with NTFS, Recovery Console allows you to actually boot to that NTFS disk and make granular file changes to the impaired system. This gives you the flexibility to copy individual files over to the hampered system from a floppy or other removable media. But this functionality isn’t set up by default. Although you can run Recovery Console from the installation CD, the more prudent approach is to install Recovery Console before there’s a problem.

To install Recovery Console on a functioning system, you need to place the original installation CD in the drive and enter the command shown in Figure 3 in the Start _ Run dialog box. This brings up Figure 4, which gives you a brief overview of what Recovery Console does and warns you of yet more hard disk space consumption.

Figure 3. To install Recovery Console on a functioning system, you need to insert the original installation CD and open the program.

Figure 4. During setup, Recovery Console gives an overview of its features and informs you of hard disk space consumption.(Click image to view larger version.)

With this little confidence-builder behind you, the installation program copies more than 100 files that take up just less than 6MB of disk space in a system folder called CMDCONS. You are then told that the next time you start Win2K, you’ll have the option to start Recovery Console. The next time you boot your machine, Recovery Console is presented as just another operating system option during the operating system startup.

Be Prepared
There is one major “gotcha” here, and that’s to make sure that you have any special drivers, such as SCSI, that are necessary for Win2K to boot properly with the hardware in your machine. When you select the Recovery Console option, a message is shown at the bottom of the screen that informs you to press [F6] if you need to supply a custom driver. If you need one and don’t select this option, you’ll most likely “blue screen.” In addition, your driver must reside on a 3.5-inch disk, as the OS cannot access any other devices at this point. Finally, for the same reason, you must present this floppy disk with the proper driver each time you start Recovery Console. I highly recommend that you keep this disk along with the machine’s ERD somewhere near the machine. This may seem like a security issue, but if you don’t have physical security then you don’t really have security at all.

After successfully navigating the previous caveats, you’ll see the familiar dots pass across the screen as the various drivers are loaded until the lovely “console” interface of text shows up as the entry point into the utility as shown in Figure 5.

Figure 5. Once Recovery Console is installed, you’ll be asked to restart and given the option to choose which Win2K installation you want to use.

Recovery Console will identify all Win2K installations on your system and present them as the menu shown in Figure 5. You choose the installation you want to work with by selecting the number in front of the physical directory location of the files. This is important because when you select an installation you’ll be authenticated by the SAM (yes, it still exists in Win2K) of that particular installation using the built-in administrator account.

After you are authenticated, you’ll be presented with a familiar-looking command processor at the directory location specified in the menu options. But this isn’t a DOS processor, or even the NT processor. This is an environment wholly its own and contains a predefined set of 30 or so commands that allows you to perform various administrative tasks. The processor also only allows you to have access to specific directories. These are the root directory, the %SystemRoot% and its subdirectories, the cmdcons directory, and one directional access from removable media drives, such as the 3.5-inch disk and CD-ROM.

Thwarting the ‘Blue Death’
The most obvious use of Recovery Console is the ability to copy specific files from source media to the system installation. For example, you may have downloaded that new shiny driver from 3Com or Intel that promises to make your NIC do unnatural acts. You plop it in your system only to be visited by the grim reaper of blue death. Now you can restart the machine, select Recovery Console, and copy the old driver back into its proper place — at which point, all should be well with the world, unless of course the driver installation also modified the directory. If this is the case you can also use the Recovery Console to copy registry hives from the %systemroot%\repair directory or the %systemroot%\repair\regback directory. Again, be careful in regard to what you’re restoring. Keep in mind, too, that these backup copies of the Registry are also in a particular state depending upon when you last updated your ERD with the backup registry option or the “save system state” option during backup operations.

Keeping Services in Check
One of the most interesting capabilities of Recovery Console is the ability to enable and disable services that are causing you grief. What if you didn’t follow the time-honored best practice of only making one change to your system at a time or if something just went wrong and a service is causing your system to die at boot? What’s an admin supposed to do? You can use a combination of a few Recovery commands — LISTSVC, ENABLE, and DISABLE — to troubleshoot the problem. First, the LISTSVC command reads the SYSTEM registry hive located in the %systemroot%\system32\config\ directory and presents all the available services, associated drivers, and their start types for the respective Win2K installation (see Figure 6). And these aren’t just services such as DSN and DHCP, but all the low-level services as well.

Figure 6. The LISTSVC command reads the SYSTEM registry hive and brings up all the available services, associated drivers, and their start types.

Once you have this information, you can selectively disable a suspect service, perhaps because of information obtained through the blue screen, and reboot the machine until you have disabled the proper offending service, then repair it.

As this is a text-command processor, you have to know what commands you’re typing ahead of time and that the syntax is correct. To deal with this, Recovery Console has a help system that is straightforward. You type in HELP and the command, such as ENABLE, at the command prompt and the proper usage for that command is displayed.

There’s no way that I can discuss all of the commands that are available in Recovery Console in this space. For more information about ERD and Recovery Console, refer to Chapter 13 of the Operations Guide in the Windows 2000 Server Resource Kit, or Chapter 31 of the Windows 2000 Professional Resource Kit.

There’s one more important command that’s worth covering here before you drop everything and install Recovery Console. This is the SET command.

Access Control with the SET Command
The SET command is interesting because it controls various levels of access to the machine. But you can’t use the SET command unless it’s enabled through the Group Policy or the Security Configuration tool. The SET command controls four Recovery Console environment variables that allow or deny specific functionality. These functions are the following:

• AllowWildCards—Turns on wildcard support for commands, which allows action on multiple files.

• AllowAllPaths—Allows access beyond the system files and folders to the files and directories on the entire machine.

• AllowRemovableMedia—Allows files to be copied to the removable media, not just from the removable media to the machine.

• NoCopyPrompt—Turns off the prompt warning when overwriting files.

The default for all of these variables is FALSE. You can always see what the variables are set to by typing SET at the command prompt with no parameters.

As mentioned earlier, these functions can’t be turned on until you enable them through policy configuration. To enable this function, open your Group Policy snap-in from the MMC and navigate to Local Computer Policy | Computer Configuration | Windows Settings | Security Settings | Local Policies. Look down the list until you find the Recovery Console section as shown in Figure 7.

Figure 7. By opening the Group Policy snap-in and navigating to Local Policies, you can find the option to enable the SET command. (Click image to view larger version.)

Double-click, and this will bring up the dialog box as shown in Figure 8 where you can use the radio button to enable or disable this functionality of Recovery Console.

Figure 8. The Local Security Policy Setting dialog box gives you the ability to enable or disable the SET command.

After enabling the policy, the next time that you run the Recovery console you’ll be able to copy files from and to locations other than the default system areas.

There are far too many commands to cover here, but you shouldn’t wait to look at this tool and explore it before you need it. The help menu will guide you as you use the commands. It’s also much easier to work with Recovery Console if it’s already installed. Finally, of course, it’s a tool that gives you access to sensitive areas of the operating system. As with any powerful tool, virtual or physical, it can damage a system as much (or more) as it can protect it. Have fun, but hey, be careful out there.