3.2 Safety Strategies
The first step towards effectively
preparing yourself to handle Registry problems is to adopt some
strategies to safeguard your data. There are a number of fascinating
books about the minutiae of planning for disaster recovery, but this
isn't one of them, so I'll leave it to you to find out
about off-site backups, fire suppression, and the other facets of
preparing to deal with catastrophic failures. If you want to read
more on this subject, check out the free (and very scary) Disaster
Recovery Journal (http://www.drj.com). Instead, I'll
present two simple concepts that will save your bacon if you
implement them. While they're targeted at helping you recover
from Registry failures, you can also apply them to other situations
that might render your Windows 2000 machines (or any others, really)
unusable or unavailable.
3.2.1 Make Backups
The cardinal
rule of data protection is don't depend on a single
copy of your data! Of course, this rule is usually
observed in the breach. You'd probably be surprised at the
number of experienced administrators who make sure to back up data on
all machines on the network, then forget to back up their own
personal workstation! As you'll see in Section 3.4, there are several ways to duplicate
the Registry's contents. Whichever you choose, though, the
following four principles will make sure your backup strategy works
for you, instead of leading you into a false sense of security:
- Make regular backups
If you back up data only at irregular
intervals, you run the risk of losing an indeterminate amount of
data. Ask yourself this: if you had to reload your Registry tomorrow
from the most recent backup, how recent would it be? Would it reflect
all the configuration and user account changes you've made
since that last backup? (Hint: as often as the Registry's
contents change, the most likely answer is probably a rueful
"no.")
Only you know how frequently your Registry data changes, so only you
know how often to back it up. Remember that every change to the
domain or local SAM database--including adding or removing
accounts, changing the default profile, changing account policies in
the User Manager, or modifying any local or global groups in a
Windows NT domain--is actually a change to the Registry. On top
of these changes, installing or removing any Windows 2000 component
can cause changes, as can installing or removing applications.
However often things change, establish
a consistent schedule and stick to it. Since Windows 2000 includes an
easy-to-use frontend for scheduling tasks, you no longer have an
excuse not to be making regular backups. You can
probably schedule Registry backups in parallel with other scheduled
maintenance actions. I know of several sites that schedule software
installations and major account changes twice weekly; that night,
they back up the new changes. At worst, they lose no more than the
previous update's changes.
- Make sure your backup software is working
There aren't many feelings that
compare to the despair of trying to reload data from a backup and
finding that the data is missing or unusable. Oops. To prevent this,
you should make a regular habit of inspecting the data that is
actually sitting on your backup media. Make sure that the backups
contain everything that should have been backed up, and that the
modification and update times are reasonable.
If you're using conventional backup software, you can check to
make sure the files named in Section 3.4.1 later in this chapter are actually
making it onto the backup media. If you're building an
emergency repair disk (ERD), you can check the timestamps on the
files to make sure they correspond to your expectations.
As a practice measure, one day when you're feeling brave, go
out and find a scratch machine somewhere on your network. Back up its
Registry using your preferred method, then intentionally damage it
and see whether you can restore it. Be sure not to do this
on a production machine, but be sure to do it. Experience
is the best reassurance, and if you're comfortable with the
process of restoring a damaged Registry you'll be much less
stressed when the time comes to do it for real.
- Don't leave anyone out
Your backup plan needs to include every machine that's
important. At a minimum, make sure you're backing up all your
Windows 2000 servers, especially domain controllers and any other
machine whose presence and function are critical to your network. If
you have special-purpose servers running software such as Microsoft
Exchange Server, Lotus Notes or Domino servers, or Netscape's
server products, make sure you include them as well, since server
products like these often make exceptionally heavy use of the
Registry for their own settings.
User workstations present a slightly different kettle of fish. If
every user has her own workstation, you probably need to back them
all up. If all users share a pool of workstations, and your network
is set up to use roaming profiles, you may be able to slip by without
backing up the Registry data of pool machines. If one crashes, you
have to reload whatever software was on the machine to restore its
installation entries in the Registry, but the user account and
profile data are transparently restored by Windows 2000 as users log
in.
- Make sure your backups reflect recent changes
Even if you make regular
backups, you still need to keep your ERD up to date. In Windows NT
4.0, the ERD contains the local machine's SAM database and
portions of HKLM and HKU. In Windows 2000, the ERD contains
information the operating system can use to repair a damaged Windows
2000 installation, but no Registry data. That means that you have to
unlearn the old NT 4.0 habit of relying on the ERD as a Registry
backup.
 |
The RDISK utility (which you'll learn how
to use later in this chapter) displays a message telling you not to
depend on ERDs as a backup tool. This is good advice; an ERD should
be part of your backup plan, not a substitute for one.
|
|
This leads me to another general principle: make backups when things
change. For example, one network administrator I know instituted a
strict policy of updating ERDs and Registry backups before installing
prerelease or beta versions of any web browser. To her delight, this
strategy saved her a significant amount of trouble when the
browser's installers misbehaved and damaged the
Registry.
3.2.2 Be Prudent
"Fools rush in where angels fear to
tread." When Alexander Pope said so in 1711, he wasn't
talking about Windows 2000, but his words apply, in spades, to
working with the Windows 2000 Registry, since it represents a
potential single point of failure that can render your whole machine
unusable if you make a mistake while editing it.
The best defense against this sort of mistake is simple: abstinence!
However, it's not always possible to avoid editing the Registry
yourself; some settings and parameters aren't editable anywhere
else. Here's how you can exercise maximum prudence to guard
yourself against Registry mishaps:
- Practice random acts of self-restraint
A wise man named Mitch Ratliffe once opined that computers allow
people to make mistakes faster than any invention other than handguns
and tequila. You should keep that thought in mind whenever the
temptation to edit the Registry enters your mind.
Don't change a value just to see what it
will do when changed; if you want to know what a particular key does,
look it up in Chapter 11,
instead of tweaking it to see what breaks.
In the same
vein, don't remove keys or their values unless you've
previously uninstalled the software that uses those values. You may
be certain that no one needs the data in
HKLM\Software\SomeVendor\SurfWriter, but it's generally not
wise to test your certainty by arbitrarily whacking the whole subkey
to see what happens. Instead, you can use the
REGCLEAN utility (provided with
Microsoft's Developer Studio, Visual Basic, and Visual C++
products, or at
ftp://ftp.microsoft.com/softlib/mslfiles/regcln41.exe)
to automatically clear out any superfluous entries in HKCR.
You're on your own for clearing out other keys and values in
other root keys.
 |
Many people still have REGCLEAN Version 4.1. This version is
dangerous under Windows NT and Windows 2000; make sure you get
Version 4.1a or later if you want to use it.
|
|
- Practice safe security
Of course, self-restraint is a virtue, but so is good security. You
can think of it as a way to help others have self-restraint when it
comes to your data. Make sure you follow the suggestions for choosing
appropriate Registry permissions and auditing settings in Chapter 9.
 In particular, if you choose to enable
SYSKEY
protection on a Windows NT 4.0 computer (as described in Section 9.5 in Chapter 9), make
sure you pay careful attention to the description of what you must do
to restore a SYSKEY-protected Registry. Remember
that SYSKEY is always on for Windows 2000
machines!
- Use the scientific method
Sometimes there actually are good reasons for editing Registry
values. Microsoft's
Knowledge Base (http://support.microsoft.com) is chock-full
of articles that explain how to tweak normally invisible Windows 2000
and NT parameters. These settings are often worth changing for
security, performance, or bandwidth-related reasons; however, it can
be hard to tell whether making the changes will work well for you or
not.
If possible, set aside a machine or two on your network for
experimenting with these sorts of seemingly necessary changes. Doing
so gives you a safe area to make changes, then study their effects,
without compromising any of your production machines. If the changes
have the desired effect, you can always add them to more machines
when it's convenient; if, by chance, they turn out to be
detrimental, you don't have a long list of user or server
machines to fix.
- Consider buying better tools
Neither of the Registry editors provided
with Windows 2000 support an "undo" function, and neither
of them log what changes were made during an editing session. While
word processor, CAD, spreadsheet, and other
"productivity" applications have had both of these
features for years, they haven't made the leap into
Microsoft's OS development group. There's good news and
bad news to report. First the good news: there are other third-party
editors that allow you to undo changes at any time, even if
you've already applied them. The bad news: they cost money.
Consider Symantec's Norton Utilities for NT (available from
http://www.symantec.com/). For its US$100 or so
purchase cost, you get a Registry editor that combines many of the
features included in RegEdit and
RegEdt32 with a robust undo capability. As it
turns out, you can use the Norton Registry Editor under Windows 2000,
too, by installing it on Windows 9x or Windows NT, then copying the
needed files to your Windows 2000 machine. If $100 is too rich for
your blood, you can instead use the shareware RegView
and RegView Pro applications
(available from http://www.xnet.com/~vchiu/regview.shtml), which runs fine under NT and Windows 2000 and offers
its own undo facility.
|
