Before building system policies within Windows NTespecially if youre going to migrate to Windows 2000you must first understand the Registrys structure and how it can be modified.
System Policies and the Windows NT Registry
Before building system policies within Windows NT—especially if you’re going to migrate to Windows 2000—you must first understand the Registry’s structure and how it can be modified.
- By Michael Chacon
- March 01, 1999
Despite increased attention to system policies and the
Windows NT System Policy Editor, many people still view
the underlying process of setting up a system as a black
box. Day-to-day administration of Windows NT workstations
can be tedious and time consuming. Many sites still manage
and configure each desktop individually, often in response
to configuration problems. This method, fraught with frustration
and needless hours of support, is a major reason why Windows
NT networks are perceived as difficult to manage. This
neednt be the case.
The obvious solution is to create enforceable policies
that can be centrally managed for any number of users.
This means using the System Policy Editor, an often-ignored
tool that sits under the Administrative Tools menu. This
tool will become increasingly important as companies migrate
to Windows 2000, because all the configurations that you
perform with the many NT 4.x administration GUIs will
be moved under the umbrella of the Computer Management
section of the Management Console tool. In effect, the
majority of the users environment configurations
will be made through the process of system policies, which
are essentially Registry edits applied in a controlled
and systematic manner.
Even if you dont plan to implement Windows 2000,
you should still consider system policies as a professional
method to manage networks. Theyll simplify network
administration and support. But before you move forward
and build a policy from the boilerplates that come with
the System Policy Editor, you must first understand how
this tool works and how it fits architecturally within
NT. All roads lead to the Registry with NT, and policies
are no exception. Therefore, the place to begin building
a system policy is by understanding how the Registry is
structured and how it can be modified.
All configuration information for NT is stored in the
Registry. The Registry is actually several databases stored
in WINNT\SYSTEM32\CONFIG (Figure 1). Unique NTUSER.DAT
files for each local user are stored in WINNT\PROFILES\"Username"
and are created as each user logs on and off a workstation.
|Figure 1. The Windows NT Registry
is composed of several databases that are collectively
stored in WINNT\SYSTEM32\CONFIG.
Each Registry file is referred to as a hive, and each
listed hive also has related files with the same name
but different extensions, such as .SAV and .LOG. The .SAV
extension is a remnant of the text portion of the NT installation
process, and the .LOG files contain changes made to each
hive. The hives are brought together and organized under
handle keys, a name that refers to the handles used by
programs to reference underlying keys and their values.
This handle architecture creates some consistency for
the database hive files. The handle keys are most commonly
seen in the Registry Editor, which displays five keys.
In reality there are only two keys, HKEY_ LOCAL_MACHINE
(HKLM) and HKEY_USERS (HKU). The other three keys visible
in the Registry Editor are aliases that point to sections
of one of the two fundamental keys. This is designed to
simplify programmatic access and navigation. Changes made
to aliases are actually made to HKLM or HKU, as you can
see in Figure 2.
|Figure 2. Changes made to aliases
in the Registry Editor are actually made to the HKLM
or HKU keys. In this case, the HKEY_CLASSES_ROOT handle
key is actually an alias for the HKEY_LOCAL_MACHINE\SOFTWARE\Classes
Understanding the Registry structure is important not
only for general support purposes, but also because creating
and writing Registry keys is a core part of implementing
Before we jump into the Registry Editor, let me make
this obligatory caution: Back up the Registry before you
modify anything. Always start with the RDISK.EXE utility
using the /S switch. This utility copies most of the Registry
hives to the \WINNT\SYSTEM32\CONFIG directory and also
lets you copy them to an Emergency Repair Disk (ERD).
Make sure you use the /S switch or all files wont
be included. Keep in mind, however, that the ERD is a
repair utility, not a backup tool. It also doesnt
copy all the NTUSER.DAT hives.
The approved method is to use a tape backup program.
You need to check the Backup Local Registry box and select
at least one file on the same partition. Another method
is to use the REGBACK.EXE utility from the Windows NT
Resource Kit, which copies all the open Registry hives
to a location that you specify on the disk. These hives
can then be restored with REGREST.EXE, which is also included
in the Windows NT Resource Kit. If you type in either
command with no arguments or parameters, a help screen
will appear that explains the syntax for the arguments.
As with all NT Resource Kit tools, this method is unsupportedbut
Theres another method built into the Registry Editor
that can be quite useful, particularly for quick restores
when editing specific key branches. When you use tape
to back up your Registry, it neglects to store one key:
the list of shares that have been created on your server.
This can be very disconcerting if youre trying to
get back online quickly. Imagine a hard drive fails and
no mirrors are available (doesnt mirroring always
look better after a failure?). So you pull out your trusty
verified tape and slap it on a new drive. The problem
is, users will still complain that the system is broken
because their shares arent present.
Instead of pulling out that hardcopy documentation of
all your configurations (you did make a copy, right?)
and re-creating the shares, try the following procedure.
Open the Registry Editor to the HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares
key, which will display all the shares on the machine,
as shown in Figure 3.
|Figure 3. Opening the Registry
Editor to the HKLM\SYSTEM\
will bring up a display of all the shares on your
With the key highlighted, select the Registry|Save Key
menu option. This will bring up the Save Key dialog box.
When saving the key, you can use any name you want. The
best practice is to use something narrative and leave
it in a directory where you can find it again when needed.
Because thisll be a regular unopened file, itll
be backed up with the normal tape backup. When you have
to rebuild a disk subsystem and restore the system from
tape, you then use the Registry|Restore menu option and
bring the key back into the Registry. Your shares will
be available again immediately.
The procedure I just described works with other keys
as well. For example, if you save a key before you install
a software package and you have an installation problem,
you can restore the key and go back to where you started.
One thing to remember is that when you restore a key using
this technique, the key is completely replaced. Instead
of making selected changes, the process completely overwrites
whatever information was there in the first place.
Another example of how the Registry is built and edited
can be found in HKEY_USERS. If you open the HKEY_USERS
handle key in Registry Editor, youll notice that
you can only see the .DEFAULT hive and the currently logged-in
user hive. This key is reflected in the alias handle HKEY_CURRENT_USER,
which is actually the NTUSER.DAT file for that user.
There is a way to bring other users hives onto
a particular machine, be it locally or remotely. Open
the HKEY_USERS and, with the handle key highlighted, select
the Registry|Load Hive menu option and navigate to the
WINNT\PROFILES\ Username directory where the Username
is the directory that reflects the user you want to modify.
Select the NTUSER.DAT file in that directory. Youll
be prompted for a name. This name can be whatever you
choose, because its only a label for use in the
Registry Editor. Convention suggests that you use the
Username. This will bring that users NTUSER.DAT
hive into the Registry Editor (Figure 4).
|Figure 4. After you bring another
users hive onto your machine, that users
NTUSER.DAT hive will be visible in your Registry Editor.
Now you can make any changes that you want. For example,
you might want to copy a section of one user to another
if an applications setup program modified the Current
User instead of all the users. You can use the Registry|Save
menu option to create a hive and then use Registry|Restore
to bring those entries into the other users hive,
avoiding the need to reinstall the application under the
new user. When youre finished, you use the Registry|Unload
Hive menu option to write the changes back to the NTUSER.DAT
file, which will now reflect the changes youve made.
- You can find more information about
the Registry in chapters 23-26 of
the Microsoft Windows NT Workstation
4.0 Resource Kit, Microsoft Press,
$69.95, ISBN 1-57231-343-9. The REGENTRY.HLP
file, which comes with the Resource
Kit, details the contents of the Registry.
For more information, visit www.microsoft.com/mspress.
- Also, you can read Practical
Policies by Joseph Phillips
in the December 1998 issue, which
provides an overview of the System
Keep it in Perspective
Im not recommending that everyone start editing
NTUSER.DAT files by this method. First, it isnt
the most efficient and scalable way to control these files.
And second, if you dont know what youre doing,
youll eventually trash your Registry. My point this
month was to describe how the Registry works and how it
relates to system policies. Working with the Registry
Editor helps you understand this because system policies
are actually systemic edits of the Registry on each local
workstation. When a system policy is enforced, a preplanned
Registry section or hive is written to the local Registry.
Next month, Ill discuss the Registrys architecture
further and how it relates to profiles and system policies.
What I discussed this month is similar to profiles and
system polices in how they function. Each, however, is
a more sophisticated step in the road to the polices that
will permeate Windows 2000 and beyond.