Emergency Service

Anyone who’s installed Windows NT has seen the prompt,
“Would you like to create an Emergency Repair Disk?”
at the end of the installation process. Most people who
are unsure of what this means dutifully place a disk in
the drive and wait while the mysterious process completes.
With the installation complete, the disk is usually put
aside while the more pressing tasks of configuring the
system are completed.

Exploring the ERD during an emergency is like buying
automobile insurance while viewing the remains of your
car. Even for those of you who know what the ERD is, how
many of you have actually taken the time to see if it
works? Do you know the specific steps necessary to use
it? If not, you’re not alone—so read on and
sharpen another arrow for your quiver.

ERD Basics

The general rule of thumb is that if there’s a configuration
problem and you haven’t logged onto the machine,
try the LastKnownGood option during boot time. If this
doesn’t work or if you have a corrupted system file
on the machine, you should use the ERD process. If this
last-ditch effort fails, it’s likely that you’ll
have to reinstall a new system and restore the original
system from backup.

The ERD shouldn’t be considered a replacement for
backup—it’s a repair utility. The ERD is a machine-specific
disk that contains copies of certain Registry hives, system
files, and a log of the installation process created during
the setup process. The files on the ERD are copied from
the ones that are located in the \%Systemroot%\Repair
directory. On a Windows NT 4.x machine these files are:

AUTOEXEC.NT initializes the MS-DOS environment
and is located in \%Systemroot%\System32\.

CONFIG.NT also initializes the MS-DOS environment
and is located in \%Systemroot\System32\.

DEFAULT._ is the compressed Registry hive
HKEY_USERS\DEFAULT.

NTUSER.DA_ is the compressed Registry hive
located in %Systemroot\Profiles\DefaultUser\Ntuser.dat.

SAM._ is the compressed Registry hive HKEY_LOCAL_MACHINE\SAM,
which contains the user account information for this
machine.

SECURITY._ is the compressed Registry hive
HKEY_LOCAL_MACHINE\SECURITY, which contains the security
context for the users on the machine.

SETUP.LOG lists the files that were installed
and the CRC information that’s used during the
repair process. This file is updated as configuration
changes are made to the machine.

SOFTWARE._ is the compressed Registry hive
HKEY_LOCAL_MACHINE\SOFTWARE, which contains configuration
information for the applications installed on the machine.

SYSTEM._ is the compressed Registry hive HKEY_LOCAL_MACHINE\SYSTEM,
which contains configuration information for the services
installed on the machine.

This brings up an important point: When you create an
ERD, you’re actually copying these files from the
\%Systemroot%\Repair directory to a 3.5-inch disk. It’s
possible that this directory contains out-of-date information
or that the ERD contains different information than the
%Systemroot\Repair directory, as shown in Figure 1 by
the different dates for the files.

Figure 1. When you create an
ERD, you’re actually copying these files from
the \%Systemroot%\Repair directory to a floppy disk.
It’s possible that this directory contains out-of-date
information or that the ERD contains different information
than the %Systemroot\Repair directory, as shown here
by the different dates for the files.

The reason many ERDs haven’t been updated is because
there’s no icon to the utility that manages the ERD
built during installation. This utility is called RDISK.EXE
and is located in \%Systemroot\System32. As with any program,
you can create an icon for the program or you can simply
enter RDISK.EXE at the command prompt, which will bring
up the screen in Figure 2.

Figure 2. The utility that manages
the ERD built during installation is called RDISK.EXE,
and it’s located in \%Systemroot\System32. Entering
RDISK.EXE at the command prompt will bring up this
screen.

Exit and Help are self-explanatory, but let’s look
at the other two options. Create Repair Disk will copy
the files that are currently in the \%Systemroot\Repair
to the ERD. Update Repair Info will compile the current
system configuration information from the Registry and
create new files that reflect this information in the
\%Systemroot\Repair directory. This option will also ask
if you want to update the ERD as well. If you follow these
prompts, you’ll notice that the dates on the ERD
will match the dates of the files in the \%Systemroot\Repair
directory (see Figure 3).

Figure 3. RDISK.EXE will update
the ERD so that the dates on the ERD match the dates
of the files in the \%Systemroot\Repair directory.

It’s important to update the ERD every time you
make significant changes to a machine’s configuration.
This brings up another issue: you’ll notice that
only some of the Registry hive files have been updated.
This is because on some machines, notably Domain Controllers,
this information can consume many megabytes of space,
well beyond the space limitations of a 3.5-inch disk—and
an ERD can’t span disks. For this reason you have
to take an extra step to update the user and security
information in the %Systemroot\Repair directory. That
extra step is to use an /S switch when you run RDISK.EXE.
This will update the other Registry hives as shown in
Figure 4. Also note that when RDISK /S is run at the command
prompt, the Repair Disk Utility screen won’t be displayed.
And finally, you should document what administrator password(s)
were at the time that the recovery disk were made, in
case you need to repair the SAM. Otherwise, life can get
very interesting trying to remember old passwords.

Figure 4. Adding an /S switch
when you run RDISK.EXE will update the other Registry
hives.

Creating the ERD

Now that we’ve discussed the various alternatives
for creating or updating a new ERD, let’s step through
the emergency repair process. The ERD isn’t a bootable
disk. Rather, it’s used with the NT setup program.
The setup program is run by using the three setup disks,
which you can re-create using the winnt32 /ox command
from the NT CD. Place disk 1 in the machine, or boot from
the NT CD if possible, and reboot. This will load some
system files and then request disk 2. You’ll reach
a screen that asks if you want to update a current installation
or create a clean install. At the bottom of this screen,
there’s also an option to press R—Repair. This
will bring up the following text:

As part of the repair Process, Setup
will perform each of the optional tasks shown below
with an "X" in its check box.

To perform the selected tasks, press
ENTER to indicate "Continue." If you want
to select or deselect any item in the list, press the
UP or DOWN arrow key to move the highlight to the item
you want to change.

Inspect Registry files
attempts to load each selected Registry hive from a
second screen and determines if it’s corrupted.
If so, it gives the administrator the opportunity to
replace it with the copy on the ERD or leave it alone.

Inspect startup environment
verifies that the system partition files such as NTLDR
are present. If they’re missing or corrupt, they’re
replaced from the Windows NT installation CD.

Verify Windows NT system files
uses a checksum to verify that all of the files are
good by matching them with the files on the installation
CD. If any of the files don’t match, then you’re
given an opportunity to replace them from the CD.

Inspect Boot Sector checks
the boot loader functionality, which calls NTLDR and
replaces it if necessary from the ERD.

You can select one or all of these functions by using
the up and down arrow keys and pressing enter to select
and de-select the options. After this screen, the normal
setup screens follow and display information regarding
the mass storage devices and SCSI adapters, and it gives
you the opportunity to specify additional adapters. Windows
NT 4.x requires the installation CD to continue and will
request it if you don’t have it in the drive. (Refer
to KnowledgeBase article Q150497 on How to Repair Windows
NT System Files Without a CD-ROM Attached if you don’t
have a CD-ROM available on the server.) You’ll then
be prompted for an ERD or be asked if you want setup to
locate the files on the local hard drive, which will be
the \%Systemroot\repair directory. Regardless, if you’ve
chosen the Inspect Registry files option, the next screen
will present some more detailed options for the recovery
process:

Setup will restore each registry
file shown below with an "X" in its check
box.

To restore the selected files, press
ENTER to indicate "Continue." If you want
to select or deselect any item in the list, press the
UP or DOWN ARROW key to move the highlight to the item
you want to change. Then press ENTER.

WARNING: Restore a registry file
only as a last resort. Existing configuration may be
lost. Press F1 for more information.

If you select any of these options, the Registry hives
will be checked for corruption. You’ll be given the
option to replace any corrupt files with the copy on the
ERD or in the \%Systemroot\Repair directory.

If you select the Verify Windows NT system files option,
the files on the hard drive are compared with the files
listed in the SETUP.LOG file on the ERD (see Figure 5).

Figure 5. If you select the Verify
Windows NT system files option, RDISK.EXE will compare
the files on the hard drive with the files listed
in the SETUP.LOG file on the ERD..

As you can see, the location path is listed along with
the checksum values that are used for verification. If
these differ from the files on the CD, you’ll have
the option of individually replacing the file. You can
also select an option to have any file with a checksum
mismatch be automatically replaced. After the ERD process
is complete, you’ll be prompted to remove any disks
and CDs from the drives and reboot to bring the system
up... hopefully.

Coming Next Month...

The ERD process provides a reliable and straightforward
method for repairing files that would otherwise prevent
your NT system from booting. There are still several issues
that prevent the widespread use of the ERD. For one, in
an installation of thousands of NT workstations it can
be very time-consuming to keep all the ERDs up to date.
For this reason, many sites just use the ERD process for
Domain Controllers. Next month, I’ll explore some
of the deeper details surrounding the ERD and some methods
for solving or working around those issues.