Microsoft Windows Server 2008 Terminal Services

14. Registry

Posted by Benny Tritsch on August 24, 2008

[Registry] [Introduction] [TS Keys and Values] [App Settings]

14.1. Introduction to the Registry

Read in this lesson...

1. Registry Structure
2. Regedit – The Registry Editor

 

The Windows Server 2008 registry represents the central configuration repository of operating system and user environment. Without basic knowledge of the registry’s hierarchical administration element, it is very difficult to understand solutions to the challenges described in later sections of this chapter. These problems may occur during application installation and system optimization.

The registry concept evolved during the development of Microsoft Windows NT. The registry was applied as a successor to .ini files that were used in Windows for Workgroups (WfW) and Windows 3.1. The reason for this change in design was that .ini files had (and still have) a number of disadvantages. For instance, they are significantly limited in terms of size, there is no standard layout, access is comparably slow, and they cannot be used across the network. Additionally, the different .ini files have an immense number of parameters.

An early version of the registry already existed under Windows 3.1. It managed dynamic data exchange (DDE), object linking and embedding (OLE), and file manager extensions. For Windows NT and all later systems, this registry was significantly expanded and still forms the heart of the operating system. However, Windows Server 2008 still supports .ini files for backward compatibility reasons to older applications, even though their use is not recommended any more. These .ini files are normally found in the %SystemRoot% or %SystemRoot%\System folders.

Applications that are based on the Microsoft .NET Framework – referred to as managed applications – typically store configuration parameters in XML files. Conventional, unmanaged applications use the registry for the same purpose. With managed applications and XML files Microsoft returns to a design that, in contrast to using the registry, is easier to read and manage. The effort required to install multiple applications is also reduced as the install program simply copies the executable program and configuration files in ASCII format. However, even for Windows Server 2008, the registry still plays a key role in configuring system settings and conventional applications.

Registry Structure

Each change in the system, each installation of conventional software, and each modification to the user environment cause the registry to be accessed. Areas of the registry can be generated, changed, or deleted. In this way, the registry handles user, system, and application settings during system runtime. It also determines which drivers and services need to be loaded when the operating system is started.

The hives in the root of the registry hierarchy have preset names and meanings (hive key = HKEY). Each hive is constructed as a branch of the registry in which applications find individual keys and their related individual values. In other words, hives are the major subdivisions of all of sub-trees, keys, sub-keys, and values that make up the registry.

Registry Hives

The registry can more or less be divided into two areas. One area contains the system-wide information including hardware data. The other area comprises settings for individual users. For simplification the branches of these two registry areas are assigned special names or abbreviations. These will be used in further documenting the registry entries.

• HKEY_LOCAL_MACHINE (HKLM): This hive contains entries for hardware configuration and system-wide data on software installed on the local computer. It also includes the paths required to load application components. If you change individual keys, you might irreversibly destroy the system. The most important entries for a terminal server's software configuration are located here as well. Most setting are found under HKLM \System \CurrentControlSet and HKLM \Software.
• HKEY_USERS (HKU): This hive contains all currently loaded user profiles including the default profile. Each user profile is identified by an SID (security identifier) and includes individual application settings, paths, configuration data, temporary directories, desktop settings, environment variables, network connections, or printers. The specific software configuration for a user profile is usually located in the \Software sub-hive. This branch has priority over HKLM \Software.

The HKLM and HKU root hives have many more branches. Three of these sub-hives are so important that they have their own abbreviated names in the registry editor described later. Due to the arrangement of these sub-hives in the registry hierarchy, it looks as if there were five root hives. In reality, there are only three root hives within HKLM and HKU which can easily be identified.

• HKEY_CURRENT_USER (HKCU): This hive contains data on the session currently running. However, you need to bear in mind that on a terminal server, the information in this registry hive is represented in the context of the observing user. If an administrator looks at this hive, he or she sees only his or her own settings. The administrator cannot view or modify the settings of another user who is logged on. It is therefore easy to see that HKCU is an HKU sub-hive. HKCU data originates in the profile file of the corresponding user and is loaded when that user logs on.
• HKEY_CLASSES_ROOT (HKCR): This hive allocates file extensions and programs, that is, it lists the file association or application for each file type. It also saves OLE data. Physically, HKCR is a reference to the HKLM \Software \Classes hive.
• HKEY_CURRENT_CONFIG (HKCC): Contains configuration data for the current hardware profile. Hardware profiles reflect only changes in the default system configuration. The changes themselves are located in the HKLM software and system hives. Physically, HKCC is a reference to the HKLM \SYSTEM \CurrentControlSet \Hardware Profiles \Current file.

Keys and Values

In principle, the hives listed consist of hierarchically arranged keys that can be assigned sub-keys or values (data). Sub-keys themselves can have sub-keys or values, too. Each key has an additional default value (without a name).

The values possess a value name, data type, and data. A value can have different data types. However, only the first five data types in this list are commonly used:

• REG_BINARY: A data field of any length that can be stated in binary or hexadecimal notation.
• REG_DWORD: A numerical value of four bytes (32 bits) that can be stated in binary, decimal, or hexadecimal format.
• REG_SZ: A single character string that ends in a zero byte.
• REG_MULTI_SZ: A multiple character string or sequence divided by zero bytes.
• REG_EXPAND_SZ: A dynamically expandable character string or sequence.
• REG_RESOURCE_LIST: A series of linked data fields that can save a resource list. This type of list can be used for device drivers or the connected devices themselves. In the registry editor, this type of data is displayed as a binary value.
• REG_RESOURCE_REQUIREMENTS_LIST: A series of linked data fields that enable you to save a list of possible hardware resources for a device driver. This type of data is displayed as a binary value in the registry editor.
• REG_FULL_RESOURCE_DESCRIPTOR: A series of linked data fields that are used to save a resource list and can be used by a physical device. This type of data is displayed as a binary value in the registry editor.
• REG_NONE: Data of no special type. This type of data is displayed as a hexadecimal value in the registry editor.
• REG_LINK: A character string that represents a symbolic link.
• REG_QWORD: A numerical value of eight bytes (64 bits).

Each value can be assigned data according to its data type. The data is usually initially arranged and set by an installation program. Applications have the ability to dynamically modify registry data during runtime. The same is true for user profiles, modifying registry data relevant for the user interface and application settings. Through specific programming commands, applications read and write to the registry values.

Each key or value can be assigned an access control list. An access control list determines read or write permissions for individual users or user groups. Additionally, a time stamp is maintained for each registry value, keeping track of the time when a key is created or value is modified.

New Registry Entries

During their installation, most conventionally programmed applications create a number of entries in the registry. For some large application packages, this can be considerably more than 10,000 entries. The entries are located either in the system-wide or user-specific part of the registry. For this reason, it is imperative to control the registry in order to manage user settings and applications.

NOTE: When you uninstall some programs, not all entries that were made during installation are undone. It is therefore recommended that you back up the registry before you install a new application. This allows you to restore the registry's original state, if need be.

If the HKLM (system-wide data) and HKCU (user-specific data) registry hives have the same keys but differing values, the HKCU values have priority. When you install an application for all users of a terminal server, you need to make sure that you enter the application-specific entries in the registry for all users and not for the installing user alone. However, this is difficult, especially with older applications, when their standard installation procedure lacks of a mechanism to control the target location in the registry.

Remote or automated access to the registry is granted either through special registry tools, script concepts, user profiles, or Group Policies. The latter, however, no longer represent classical remote access but are based on transferring remote data to the local system, where that data is then used to modify the registry.

NOTE: Profiles are the individual user settings on a computer running Windows Vista or Windows Server 2008. A Group Policy is a set of registry settings describing those computer resources that are available for individual users, user groups, or the entire computer.

Registry File Structure

On hard disk, the registry is represented by a set of discrete files, each containing a branch or a hive of the registry. By default, most of the individual registry hives are saved in the %SystemRoot% \System32 \Config folder.

• SAM and SECURITY: SAM is short for Security Accounts Manager. The keys in the hives HKLM \SAM and HKLM \SECURITY contain information such as user rights, user and group info, and passwords. The keys are binary data and are only accessible for users with system privileges.
• SYSTEM: The keys in the hive HKLM \SYSTEM contain basic operating information, such as startup procedures, loaded device drivers, or services in use. The hive is split into ControlSets, maintaining several versions of unique system configurations.
• SOFTWARE: The keys in the hive HKLM \SOFTWARE contain information on software installed locally. File associations, OLE information, and some additional configuration data are located here.
• COMPONENTS: The keys in the hive HKLM \COMPONENTS contain information on components installed locally.

File names and registry hives are associated through the values under HKLM \System \CurrentControlSet \Control \hivelist. The configuration manager of the Windows system links these hives together, which builds the rather static part of the registry. Additionally, there are volatile hives that are created at boot time and managed in memory.

• HARDWARE: Volatile hive, which contains information about physical hardware components and devices. Hardware detection and resource assignment happens every time the system boots.

The registry hive HKU contains user profiles, each represented by its own sub-tree. A user’s profile is the individual configuration of a user session and the user interface display. Each time a user logs on to a terminal server, a new sub-tree with the user’s SID is added to the registry. The individual settings of the user profile are loaded from the binary file Ntuser.dat. This file is located on the %Systemdrive% \Users folder (= %UserProfile folder) on the local system's hard drive or on a central network share.

From a user perspective this means for the individual settings:

• HKCU: This registry sub-tree is linked to by HKEY_USERS \ and stored under %UserProfile% \Ntuser.dat.
• HKCU\Software\Classes: This registry branch is linked to by HKEY_USERS\_Classes and stored under %UserProfile% \Local Settings \Application Data \Microsoft \Windows \Usrclass.dat.

If a user logs on to a terminal server for the first time, his or her profile is created using the hidden %UserProfile% \Default User folder as a template. In addition to the user-specific profile data, the generally valid settings saved under %UserProfile% \All Users are used as well. Therefore, the resulting profile is a combination of individual and general settings.

NOTE: Under Windows Server 2008, restricted permission settings prevent direct access to many of the profile folders, even when you are logged on as an administrator. However, the user profile service responsible for loading and unloading user profiles is executed with local system privileges. This gives the service all necessary access permissions to the relevant folders. If this service is stopped or disabled, users will no longer be able to successfully logon or logoff, applications may have problems getting to users' data, and components registered to receive profile event notifications will not receive them.

Registry Virtualization

Windows Server 2008 has introduced limited registry virtualization, where write operations to the HKLM hive can be redirected to a more appropriate location. This may either be a different location in the registry or a non-registry backed location, such as a file. The advantage of this virtualization technology is that the application itself does not to be modified. The registry access is completely transparent to the application, as it does not know that its registry operations have been directed elsewhere.

The Microsoft Application Compatibility Toolkit provides so-called shims that can transparently redirect HKLM or HKCR registry operations to HKCU. This helps preventing issues that cause applications not to work for limited users.

Regedit – The Registry Editor

The administration programs that were introduced in previous chapters are used to properly change certain values in the registry. In addition, there is a graphical tool for general changes to the registry. This tool, called the registry editor (Regedit.exe), is located in the %SystemRoot% directory. It allows you to access the registry database at a system level, including direct changes to registry keys or values. You can use this tool to back up parts or the entire registry, as well as to reconstruct it.

IMPORTANT: You can launch the registry editor by selecting Run under the Start menu and then typing in Regedit. But even a small change in the registry through the registry editor can be fatal for a terminal server. It can lead to the terminal server refusing to reboot, which in some cases, may require reinstalling the complete system.

History of Registry Editors

Under Windows 2000, there were two different registry editors: Regedt32.exe and Regedit.exe. From a historical point of view, Regedt32 was the older program. Its user interface still adhered to the graphical style of Windows 3.x or Windows NT 3.1. However, in contrast to Regedit, Regedt32 allowed comprehensive security settings in terms of access permissions for the registry keys.

The Regedit program was introduced later and was based on the Windows 98 registry editor. It had several functions that Regedt32 did not have. For instance, only Regedit was able to perform recursive searches for keys, values, and data. In general, Regedit was far easier to handle and always displayed the current position within the registry in the status bar.

Due to its history, Regedit encountered several limitations under Windows 2000. The most problematic restriction was that it did not support all data types for registry values. Particularly, REG_MULTI_SZ data was automatically converted to REG_SZ data when it was modified with Regedit. This, in turn, could lead to massive problems with programs accustomed to receiving multi-line character strings from the registry that suddenly receive only one line.

As you can imagine, using two different registry editors was problematic under Windows 2000. When do you use which? The updated version of the Regedit program on Windows Server 2003 and Windows Server 2008 is the result of a combination of the earlier versions of Regedit and Regedt32. It makes an administrator's life much easier, because now there is only one tool to directly manipulate the registry.

NOTE: For legacy reasons, the Regedt32 program is still available on Windows Server 2008. The Regedt32.exe executable file in the %SystemRoot%\System32 directory is only 5 KB and serves as a reference to the actual registry editor Regedit.exe. This means that the Regedt32 command at the prompt starts the Regedit program.

Regedit Functions

Regedit's central role is to generate, modify, and delete keys and values in the registry. This happens either via the context menu of a key or value, that is, through right-clicking with the mouse and selecting the corresponding option in the menu that appears. Alternatively, you can get to these options via the Edit menu item in the main window.

Additionally, Regedit allows you to import and export the entire registry or a selected sub-structure. The following data formats are supported:

• Registry file: Current Windows format of registry information; can be viewed and modified with any ASCII editor (for example, Notepad).
• Registry hive file: Binary format that can be processed only by Regedit.
• Text file: Structured ASCII file, very suitable for documentation purposes.
• Win9x/NT4 registry file: Older Windows format of registry information; can be viewed with Notepad.

Regedit also provides command line options to import and export without any graphical user interface. These options are therefore suitable for scripts or batch processing programs, also.

• Saving registry keys: regedit /e Filename.reg [Keyname]
• Recovering registry keys; importing subtrees or subkeys: regedit /i Filename.reg
• Recovering registry keys; the entire registry is overwritten by a reg file: regedit /c Filename.reg

Certain registry structures can be loaded, if needed, using File | Load Hive or be removed using File | Unload Hive. You can do this only at the root level of HKU and HKLM. The respective Ntuser.dat profile file of logged-off users can be opened, for instance, to modify individual keys and values and save the results. In this way, it is possible to correct a faulty configuration or create a template for a mandatory profile. The source data does not have to be from the same computer as the target registry editor.

With the corresponding permissions, Regedit is very effective for viewing a remote computer's registry and modifying it, if required.

Regedit inherited a very important function from Regedt32: the possibility to modify the security settings of keys and values. The corresponding dialog boxes are reminiscent of the NTFS file system permission mechanisms on Windows Server 2003. They include different permission levels for users and groups as well as monitoring and ownership options.

You can add frequently used areas of the registry to a list of favorites. This often helps in your daily routine by eliminating the need to navigate through the deeply nested hierarchy. We will now take a closer look at the preferred locations for terminal servers.

 

 

Read in this chapter...
14	Registry
14.1	Introduction to the Registry
14.2	Terminal Services-specific Keys and Values
14.3	Application specific Settings and Compatibility Flags