Managing Windows Server 2012 Systems : Managing the Registry (part 1) - Introducing the registry, Understanding the registry structure

12/17/2014 3:23:19 AM

Introducing the registry

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.

Windows Server 2012 implements transactional technology in the kernel to preserve data integrity and handle error conditions when writing to the NTFS file system and the registry. Applications that are written to take advantage of the Transactional Registry can use transactions to manage registry changes as discrete operations that can be committed if successful or rolled back if unsuccessful. While a transaction is active, registry changes are not visible to users or other applications—it is only when Windows Server 2012 commits the transaction that the changes are applied fully and become visible. Transactions used with the registry can be coordinated with any other transactional resource, such as Microsoft Message Queuing (MSMQ). If the operating system fails during a transaction, work that has started to commit is written to the disk and incomplete transactional work is rolled back.

The registry provider built into Windows PowerShell is designed to be used with transactions as well. In fact, when you manage the registry using Windows PowerShell, you script your changes within a transaction. Here, you use Start-Transaction to start a transaction before you modify the registry. Next, you make and verify your changes. Finally, you either finalize your changes using Stop-Transaction or you roll back your changes using Undo-Transaction.

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.

In Local Security Policy, Security Options can enable or disable registry virtualization. With Windows Vista and later, User Account Control: Virtualize File And Registry Write Failures To Per-User Locations enables the redirection of legacy application write failures to defined locations in the registry and file system. This feature is designed to allow legacy programs that require administrator privileges to run. When enabled as per the default setting, this setting allows the redirection of application write failures to defined user locations for both the file system and the registry. When you disable this setting, applications that write data to protected locations silently fail.

To view or modify this setting in the Local Security Settings console, open the Local Security Policy console, expand the Local Policies node in the left pane, and then select the Security Options node. In the main pane, you should now see a list of policy settings. Scroll down through the list of security settings. Double-tap or double-click User Account Control: Virtualize File And Registry Write Failures To Per-User Locations. On the Local Policy Setting tab of the dialog box, you’ll see the current enabled or disabled state of the setting. To change the state of the setting, select Enabled or Disabled as appropriate and then tap or click OK.

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.

Figure 1. Accessing a value according to its path in the registry.

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.

Early releases of Windows Server stored the entire registry in paged, pooled memory. For 32-bit systems, this limited the registry to approximately 160 megabytes (MBs) 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.

Current releases of Windows Server resolve this problem by changing the way the registry is stored in memory. Here, 256-KB mapped views of the registry are loaded into the system cache as necessary by 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, the operating system has now taken over control of managing how much memory the registry uses. Most member servers use between 24 and 32 MBs of memory for the registry. Domain controllers or servers that have many configuration components, services, and applications can use considerably more. That said, however, one of my key domain controllers uses only 28 to 42 MBs of memory for the registry. This represents quite a change from the old architecture, when the in-memory requirements of the registry could be up to 160 MBs.

To read the registry, you need a special editor. The editor provided in Windows Server 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.

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.

Unlike early versions of the Windows operating system that included two versions of Registry Editor, current releases of Windows Server ship with a single version. This version, Regedit.exe, integrates all of the features of both 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 Permissions feature, 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 2012 still has a stub file for Regedt32. However, if you run Regedt32, the operating system, in fact, starts Regedit.

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.