|
|
The Windows Server 2003 registry is a central instance and, as such, contains numerous configuration data about the operating system. Without basic knowledge of the registry’s hierarchical administration element, it is very difficult to understand solutions to the problems described in later sections of this chapter. These problems might occur during application installation and system behavior 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 (64 kilobytes), 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.
A registry already existed in principle 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, because Windows Server 2003 is backward-compatible to existing 16-bit applications, .ini files are still supported even though their use is not recommended. They are normally found in the %SystemRoot% or %SystemRoot%\System folders.
Applications that are based on the Microsoft .NET runtime environment usually don’t require use of the registry. (See Chapter 5.) The corresponding configuration parameters were normally saved in the registry are now stored in XML files. In this way, Microsoft returns to a design that, in contrast to 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. Under Windows Server 2003, the registry still plays a key role in system settings and conventional applications (that don’t use the .NET runtime environment).
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 registry hives (or just hives) in the root of the hierarchy have preset names and meanings (hive key, or HKEY). Each hive is constructed as a branch of the registry in which applications find individual keys and their related individual values.
| Caution |
When you shut down the system, many system settings are saved in the registry. For this reason, you should never simply switch off Windows Server 2003. |
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 settings 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 a security identifier (SID) 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 subhive. This branch has priority over HKLM\Software.
The HKLM and HKU root hives have many more branches. Three of these subhives are so important that they have their own abbreviated names in the registry editor described in the following section. Due to the arrangement of these subhives 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 that 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 subhive. 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.
In principle, the hives listed consist of hierarchically arranged keys that can be assigned subkeys or values (data). Subkeys themselves can have subkeys 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_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.
Each value can be assigned data according to its data type. The data is usually arranged and set by an installation program. Applications have the ability to dynamically modify registry data during runtime. 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 the read or write permissions for individual users or user groups.
During their installation, most conventionally programmed 32-bit 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 (HKLM) and not for the installing user alone (HKCU). However, this is difficult, especially with older applications, because there is often no user control of the target of registry entries via installation scripts delivered with the application.
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 2000, Windows XP, or Windows Server 2003. A Group Policy is a set of registry settings that describes those computer resources that are available for individual users, user groups, or the entire computer. See Chapter 4 for more information. |
By default, the individual registry hives are saved as files in the %SystemRoot%\System32\Config directory. It contains a number of files representing the respective hive. Table 6.1 shows the significance of the individual files.
Under Windows Server 2003, the individual configuration of a user session and the user interface display is called a user profile. These profiles are saved in the %Systemdrive%\Documents and Settings folder on the local system’s hard drive or on a central network share. The individual registry settings for a user are located in the binary Ntuser.dat file. When a user logs on, the data contained in Ntuser.dat are loaded and added as entries in HKCU. (See Chapter 4.)
If a user logs on to a terminal server for the first time, his or her profile is created using the hidden %Systemdrive%\Documents and Settings\Default User directory as a template. In addition to the user-specific profile data, the generally valid settings saved under %Systemdrive%\Documents and Settings\All Users are used as well. Therefore, the resulting profile is a combination of individual and general settings.
The administration programs that were introduced in the 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 is included with the standard system installation and is called the registry editor (Regedit.exe). It allows you to access the registry database at a system-core level, including targeted changes to registry keys or values. You can use this tool to back up parts or all of the registry, as well as to reconstruct it.
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 multiline 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 new Regedit program on Windows Server 2003 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 |
On Windows Server 2003, the Regedt32 command at the prompt starts the Regedit program. 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 in the %SystemRoot% directory. |
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 substructure. 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 structure 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 Dateiname.reg.
Recovering registry keys; importing subtrees or subkeys regedit /i Dateiname.reg.
Recovering registry keys; the entire registry is overwritten by a .reg file regedit /c Dateiname.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.
For several years, Windows experts Mark Russinovich and Bryce Cogswell have been publishing a lot of interesting data on Windows operating systems on their Web page System Internals at http://www.sysinternals.com. This Web site also offers a number of very powerful administration tools for free downloading. They even provide source code for some of the tools. One essential tool for examining the registry is the Registry Monitor.
| Note |
Only administrators can start the Registry Monitor; other users do not have the required permissions. If you want to examine accesses in the context of a user, you need to start a corresponding Terminal Services session while an administrator starts the Registry Monitor on the same physical server. |
The Registry Monitor is a combination of a graphical application and a special device driver (filter driver). This combination enables the recording and displaying of all accesses to a registry of a Windows Server 2003 system. With integrated filter and search functions, the Registry Monitor is a powerful tool for investigating the relevant registry entries of a terminal server.
The graphical user interface of the Registry Monitor is mostly a list of registry accesses. Each access is displayed on one line with different fields. The fields comprise sequence number, process name, type of access, registry path, access result, and additional information. The access result and the complete path are particularly important, as is the additional information that can contain read or written registry values, for example.
A terminal server’s registry analysis procedure is quite simple. An administrator starts the Registry Monitor and performs the desired actions. All accesses to the registry are collected in the Registry Monitor. The information presented is usually quite comprehensive. It is therefore practical to hide part of the list using filters you set via the Options\Filter\Highlight... menu item. You can use the * as a wildcard for any character strings.
|
|
