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_MACHINESOFTWAREMicrosoft Windows NTCurrentVersionWinlogonAllowMultipleTSSessions specifies a Registry value that can be used to enable or disable the use of offline files with Terminal Services.

Figure 14-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.

Figure 14-1. Accessing a value according to its path in the Registry

Unlike Windows 2000 and Windows NT, Windows Server 2003 supports larger Registry sizes than were previously possible and no longer keeps 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. The new 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 2003 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.

Inside Out: Windows Server 2003 manages the Registry size and memory use

Windows NT and Windows 2000 store the entire Registry in paged, pooled memory. For 32-bit systems, this limits the Registry to approximately 160 megabytes (MB) because of the layout of the virtual address space in the operating system kernel. Unfortunately, in this configuration as the Registry grows in size it uses a considerable amount of paged, pooled memory and can leave too little memory for other kernel-mode components.

Windows Server 2003 resolves this problem by changing the way the Registry is stored in memory. Under the new implementation, 256-KB mapped views of the Registry are loaded into the system cache as necessary by the Cache Manager. The rest of the Registry is stored in the paging file on disk. Because the Registry is written to system cache, it can exist in system random access memory (RAM) and be paged to and from disk as needed. In previous versions of the Windows operating system, the operating system allowed you to control the maximum amount of memory and disk space that could be used by the Registry. With the improved memory management features of Windows Server 2003, the operating system has now taken over control of managing how much memory the Registry uses. Most member servers running Windows Server 2003 use between 20 and 25 MB of memory for the Registry. Domain controllers or servers that have many configuration components, services, and applications use considerably more. For example, one of my key domain controllers uses between 25 and 30 MB of memory for the Registry. Quite a change from the old architecture, when the in-memory requirements of the Registry could be up to 160 MB.

To read the Registry you need a special editor. The editor provided in Windows Server 2003 is Registry Editor. By using Registry Editor, you can navigate the Registry's logical structure from the top of the database to the bottom. From the top down, the levels of the database are defined as root keys, subkeys, and value entries.

Inside Out: Regedit replaces Regedt32 in Windows Server 2003

Unlike previous versions of the Windows operating system that included two versions of Registry Editor, Windows Server 2003 ships with a single version. This version, Regedit.exe, integrates all of the features of the previous Registry editors. From the original Regedit.exe it gets its core features. From Regedt32.exe, which is no longer available, it gets its security and favorites features. By using the security features, you can view and manage permissions for Registry values. By using the favorites feature, you can create and use favorites to quickly access stored locations within the Registry.

Regedt32 really is gone—although I, like many administrators, still refer to it. It is, after all, the editor administrators used because it gave us the ability to manage Registry security and it is the one that was recommended for administrators over Regedit. Because old habits die hard, Windows Server 2003 still has a stub file for Regedt32. However, if you run Regedt32, the operating system will in fact start Regedit.

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_MACHINESOFTWARE MicrosoftWindows NTCurrentVersionWinlogonAllowMultipleTSSessions 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 different terms beyond those already discussed. When reading about the Registry in various sources, you might see references to the following:

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.