ERD to the Rescue

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.