In this three-part series, I’m going to detail the Windows registry as it relates to Terminal Server environments. Part one (today’s article) explains the basics of how Terminal Server uses the registry. Part two will cover how the registry is used when applications are installed on a Terminal Server, and part three contain a complete reference list of all the Terminal Server-specific registry keys that any Terminal Server system engineer should be familiar with. With that, let’s jump right into our overview of the Terminal Server registry.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
The current version of the Windows registry has been the anchor of Microsoft operating systems for about ten years. It’s been a part of Terminal Server for six years and part of Citrix WinFrame before that. However, every time I teach one of my advanced MetaFrame design classes, there are always students who are not familiar with the basic workings of the registry in a Terminal Server environment.
Before we look at the parts of the registry itself, let’s go over a few details about editing the registry. Don’t worry! I’m not going to make you read a legal disclaimer about the potential dangers of editing the registry. Instead, I want to discuss how you can view and edit the registry. More specifically, “What the heck is the difference between regedit and regedt32?”
There have long been two ways to edit the registry of a Terminal Server—regedit.exe and regedt32.exe. The exact usage of each of these applications changes with each version of Windows. In Windows 2000 environments, regedt32 was the “real” registry editor, and most people used it to do “real” registry editing. (Of course there were some specific search functions that were not available in regedt32 that forced people to use regedit in some cases.)
Fortunately, the regedt32 versus regedit complexity has recently been eliminated. In Windows Server 2003, regedit is the only choice (although regedt32.exe still exists as a little 4kb stub program that launches regedit.exe for people who forget and still type the old name).
Once you fire up the registry editor, you’ll see that there are five main sections (or “hives”) under “My Computer.” Of these, two are actual storage locations and three are alias links that pull there information from other places. (If that sounds a bit confusing it will make more sense in a minute.)
The two main hives are HKEY_LOCAL_MACHINE and HKEY_USERS. As you probably know, the registry is where all configuration information for the server is stored, There are literally thousands and thousands of settings for a single server, including things like the Windows time zone, computer name, device lists, screen fonts, color schemes, application settings, etc.
The HKEY_LOCAL_MACHINE (HKLM) hive contains system-wide “machine” settings, and the HKEY_USERS (HKU) hive contains user-specific “per user” settings.
Among the thousands of HKLM settings are things like the computer name, hardware device configuration, driver lists, software paths, and application settings. The thousands of HKU settings include such items as window colors, screen fonts, personal dictionaries, and email settings.
The idea behind the separation of machine settings and user settings is that this architecture allows an administrator to configure server hardware properties while allowing users to each have their own environmental and application settings. (Whether users actually have the ability to change their own settings is a profile and policy question and a topic for another day.)
Now, here’s where it gets interesting. As you well know, multiple users can be logged on to a Terminal Server at the same time, and they can each simultaneous have their own specific “per user” settings. For example, you might have a single Terminal Server that supports 90 concurrent users, and each user could have their own personalized color scheme or animated cursor settings.
So how does a single Windows server track all those settings for all the currently logged on users? It all goes back to that HKU hive. The HKU registry hive contains a different subfolder for each user who’s currently logged on, and each or these subfolders contains the thousands of settings for that specific user. Our 90-user server mentioned in the previous example would have an HKU hive that contained 90 subfolders—one for each user.
You can see this for yourself by browsing to the HKU registry hive. Notice that there are multiple subfolders. You’ll see that the names of the folders correspond to each users Security Identified rather than their usernames. (Remember from your basic Windows training that a SID is a unique serial number—such as S-1-5-21-1993962763-920026266-854245398-1002—that is used internally by Windows to keep track of each user.)
Each time a user logs on to a Terminal Server, his or her own subfolder (technically called a “subtree”) is added to the HKU hive. If you have two users logged onto a server then you will see two SIDs listed under the HKU hive and each user’s unique settings stored in the registry structure under his SID. Fifty users logged in at the same time will appear as fifty SID folders listed in the HKU hive.
Now that you understand the basic components of a Terminal Server’s registry, there are a few more things that we should discuss that will be of benefit to you later on.
Firstly, I’d like to point out that there are a lot of settings that can be specified on both a “server-wide” or “user-wide” basis. This means that there is a potential for conflict when a single setting might be configured for conflicting values in HKLM and HKU. In the case of a conflict, a user’s individual settings take precedence over the machine-wide settings.
The other thing that we should point out is the role of the HKEY_CURRENT_USER (HKCU) hive. The HKCU hive does not contain any actual data; rather, it is simply a pointer (or “alias”) to the current user’s SID in the HKU hive. This hive exists to allow an application that’s running within a user’s session to be able to read and write settings for that user. (Essentially, the application only has to request data from the HKCU hive, and the system will automatically sort out which SID folder in the HKU hive it will use.)
If you view the HKCU hive from an RDP session that’s logged on as “Brian,” you will see one set of data. Viewing the HKCU from another session logged on as “Ron” will reveal a different set of data. You can edit a user’s registry settings in either place—the HKCU hive or the user’s SID subtree in the HKU hive.
Well, that pretty much sums it up! Tomorrow we’ll look at how these various registry locations are used when you install applications onto a Terminal Server.