The registry is written as a binary database with the
information organized in a hierarchy. This hierarchy has a structure much like that used by a file system and is an inverted tree with the root at the top
of the tree. Any time the Windows operating system must obtain system default values or
information about your preferences, it obtains this information from
the registry. Any time you install programs or make changes in Control
Panel, these changes usually are written to the registry.
Note
I say “usually” because in Windows domains some configuration information is written to the Active
Directory directory service. For example, beginning with Microsoft
Windows 2000, information about user accounts and network objects is
stored in Active Directory. In addition, when you promote a member
server to a domain controller, key registry settings that apply to
the server, such as the default configuration values, are
transferred to Active Directory and thereafter managed through
Active Directory. If you were later to demote the domain controller,
the original registry settings would not be restored either.
Instead, the default settings are restored as they would appear on a
newly installed server.
The registry’s importance is that it stores most of a system’s
state. If you make preference and settings changes to a system, these
changes are stored in the registry. If a system dies and cannot be
recovered, you don’t have to install a new system and then configure
it to look like the old one. You could instead install Microsoft
Windows Server 2012 and then restore a backup of the failed system’s
registry. This restores all the preferences and settings of the failed
system on the new system.
Although it’s great that the registry can store settings you’ve
made, you might be wondering what else the registry is good for. Well,
in addition to storing settings you’ve made, the registry stores
settings that the operating system makes as well. For example, the
operating system kernel stores information needed by device drivers in
the registry, including the driver initialization parameters, which
allows the device drivers to configure themselves to work with the
system’s hardware.
Many other system components make use of the registry as well.
When you install Windows Server, the setup choices you make are used
to build the initial registry database. Setup modifies the registry whenever you add or remove hardware from a
system. Similarly, application setup programs modify the registry to store the application installation settings
and to determine whether components of the application are already
installed. Then, when you run applications, the applications make use
of the registry settings.
Unlike Windows XP and early releases of Windows, current Windows
operating systems don’t always store application settings directly in the registry and might,
in fact, read some settings from a user’s profile. This behavior
occurs because of User Account Control (UAC). Of the many features UAC
implements, there are two key features that change the way Windows
installs and runs applications: application run levels and application virtualization.
To support run levels and virtualization, all applications that
run on current Windows operating systems have a security token. The
security token reflects the level of privileges required to run the
application. Applications written for Windows Vista and later can have
either an administrator token or a
standard user token. Applications with
administrator tokens require elevated privileges to run and perform
core tasks. After it’s started in elevated mode, an application with
an administrator token can perform tasks that require administrator
privileges and can also write to system locations of the registry and
the file system.
On the other hand, applications with “standard user” tokens do
not require elevated privileges to run and perform core tasks. After
it’s started in standard user mode, an application with a standard
user token must request elevated privileges to perform administration
tasks. For all other tasks, the application should not run using
elevated privileges. Further, the application should write data only
to nonsystem locations of the registry and the file system.
Standard user applications run in a special compatibility mode
and use file system and registry virtualization to provide virtualized views of resources. When an application
attempts to write to a system location, Windows Vista and later give
the application a private copy of the file or registry value. Any
changes are then written to the private copy, and this private copy,
in turn, is stored in the user’s profile data. If the application
attempts to read or write to this system location again, it is given
the private copy from the user’s profile to work with. By default, if
an error occurs when working with virtualized data, the error
notification and logging information shows the virtualized location
rather than the actual location the application was trying to work
with.
Understanding the registry structure
Many administrative tools are little more than friendly user interfaces for
managing the registry, especially when it comes to Control Panel. So,
rather than having you work directly with a particular area of the
registry, Microsoft provides tools you can use to make the necessary
changes safely and securely. Use these tools—that’s what they are
for.
Caution
The importance of using the proper tools to make registry
changes cannot be overstated. If there’s a tool that lets you manage
an area of the registry, you should use it. Don’t fool around with
the registry just because you can. Making improper changes to the
registry can cause a system to become unstable, and in some cases,
it could even make it so that the system won’t boot.
As you can see, nearly everything you do with the operating
system affects the registry in one way or another. That’s why it’s so
important to understand what the registry is used for, how you can
work with it, how you can secure it, and how you can maintain
it.
The registry is first a database. Like any other database, the
registry is designed for information storage and retrieval. Any
registry value entry can be identified by specifying the path to its location. For example, the path
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ServerManager\DoNotOpenServerManagerAtLogon
specifies a registry value you can use to enable or disable the
automatic display of Server Manager at log on.
Figure 1
shows this value in the registry. Because of its hierarchical structure, the registry appears to be
organized much like a file system. In fact, its structure is often
compared to that of a file system. However, this is a bit misleading
because there is no actual folder/file representation on a system’s
hard disk to match the structure used by the registry. The registry’s
actual physical structure is separate from the way registry
information is represented. Locations in the registry are represented
by a logical structure that has little correlation to how value
entries are stored.
Windows Server doesn’t keep the entire registry in paged pool memory. Instead, 256-kilobyte
(KB) views of the registry are mapped into system cache as needed.
This is an important change from the original architecture of the
registry, which effectively limited the registry to about 80 percent
of the total size of paged pool memory. Now registry implementation is
limited only by available space in the paging file.
At startup, 256-KB mapped views of the registry are loaded into
system cache so that Windows Server 2012 can quickly retrieve
configuration information. Some of the registry’s information is
created dynamically based on the system hardware configuration at
startup and doesn’t exist until it is created. For the most part,
however, the registry is stored in persistent form on disk and read
from a set of files called hives. Hives are
binary files that represent a grouping of keys and values. You’ll find
the hive files in the %SystemRoot%\System32\Config directory. Within
this directory, you’ll also find .sav and .log files, which serve as
backup files for the registry.
At the top of the registry hierarchy are the root keys. Each
root key contains several subkeys, which contain other subkeys and
value entries. The names of value entries must be unique within the
associated subkey, and the value entries correspond to specific
configuration parameters. The settings of those configuration
parameters are the values stored in the value entry. Each value has an
associated data type that controls the type of data it can store. For
example, some value entries are used to store only binary data, while
others are used to store only strings of characters, and the value’s
data type controls this.
We can now break down the registry path
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Winlogon\AllowMultipleTSSessions so that it is more
meaningful. Here, HKEY_LOCAL_MACHINE is the root key. Each entry below
the root key until we get to
AllowMultipleTSSessions represents a subkey level
within the registry hierarchy. Finally,
AllowMultipleTSSessions is the actual value
entry.
The registry is very complex, and it is often made more
confusing because documentation on the subject uses a variety of terms
beyond those already discussed. When reading about the registry in
various sources, you might see references to the following:
-
Subtrees
A subtree is the name for the
tree of keys and values stemming from a root key down the
registry hierarchy. In documentation, you often see root keys
referred to as subtrees. What the documentation means when it
refers to a subtree is the branch of keys and values contained
within a specified root key.
-
Keys Technically, root keys
are the top of the registry hierarchy, and everything below a root
key is either a subkey or a value entry. In practice, subkeys are
often referred to as keys. It’s just easier to refer to such and
such a key—sort of like when we refer to “such and such a folder”
rather than saying “subfolder.”
-
Values A value is the lowest
level of the registry hierarchy. For ease of reference, value
entries are often simply referred to as values. Technically,
however, a value entry comprises three parts: a name, data type,
and value. The name identifies the configuration setting. The data
type identifies the format for the data. The value is the actual
data within the entry.
Now that you know the basics of the registry’s structure, let’s dig deeper, taking a closer look at the
root keys, major subkeys, and data types.
