The Windows Registry in Terminal Server Environments (Part 1 of 3)

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.

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.

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.

Join the conversation


Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

This message was originally posted by an anonymous visitor on July 30, 2004
I've always been interested in TS registry. I hope your future articles will explain in detailed about HKLM\software\microsoft\windows nt\currentversion\terminal server\ and everything under it. In change user option subkey, what's the data value of 0 or 1 means. I've read a few books about TS registry but the authors don't seem willing to explain them in detail. Thanks. BTW I like reading all your articles.
This message was originally posted by an anonymous visitor on July 30, 2004
<no comment entered>
This message was originally posted by Brian Madden on July 29, 2004
Geez! I just can't win, can I? :)
This message was originally posted by an anonymous visitor on July 29, 2004
<no comment entered>
This message was originally posted by an anonymous visitor on July 29, 2004
A little basic for this crowed, ehh Brian

This message was originally posted by Freddie on July 30, 2004
This message was originally posted by an anonymous visitor on August 3, 2004
Last I checked, I didn't have to pay to access this site. I have years of experience plus I have your Citrix MFXP 2nd Ed ;-) so this is nothing new to me. My point is, if someone takes time to pass on experience, no matter how basic, it makes our jobs a little easier. Enjoy and be happy.
This message was originally posted by an anonymous visitor on August 1, 2004
There are new Citrix admins daily. Thank you for the article. This will help many.
This message was originally posted by SlyGoose on August 10, 2004
Nice to see someone covering the "basics" as a starting point,and to gently stir the grey cells of things we all should know but often overlook or fail to realize. Having worked in the Thin environment since WinFrame 1.7, it's always interesting to see what has and hasn't changed
Dude, Well Said...!!!!
I am so a newbie at this and from all the documents that I have downloaded or read at this site, he/they have been so informative.  It has been a true JOB Saver for me. I was thrown into a situation that caused me to search frantically for information on Terminal Services and I found this site.  I don't have the funds currently to purchase support I a crawl the WEB in search of the free stuff.  This has truly been a Godsend....Thanks to Brian and all the other contributors for this site. Please keep passing the knowledge someone somewhere can always use it.  I for one can...and will.....
As a newbie too I find all the information on this site a godsaver at times and lets face it from time to time we do forget stuff and need a nudge to remind us. :) Keep up the good work fella

good one.