Terminal Server and the Profile Challenge

Profile problems?

Profile problems? “No, we never have problems with our profiles.” This is almost the standard answer I get when asking, “Do you problems with your profiles?” to customers or system administrators at an event, when they tell me about some strange problems which they have.

So why am I writing an article about profile challenges if there are no profile problems? Because when discussing and asking more questions we find out that… the answers are coming:

  • Sometimes users get an error when launching Outlook
  • Some users cannot start Application X anymore
  • User Y cannot print from one Printer for a week
  • When User X logs in it takes almost two minutes…

…and these problems are not solved easily!

Sound familiar? How do you solve this kind of problem? Ultimately you probably delete the user’s profile and everything begins running fine again.

So we repeat the same question again: Are there some profile problems? Yes, it is clear there are absolutely some profile challenges.

What is a profile actually?

To solve these challenges first you need to know what a profile is exactly. To describe it briefly, a Windows user profile makes it possible for the user to have a personalized environment. The personalized environment consists of the content and arrangement of Start Menu groups, screen colours, desktop shortcuts, network and printer connections, internet favourites, personal application settings, temporary internet files, cookies, stencils, mouse / keyboard settings, certificates and much more.

The profile is normally created when the user logs on for the first time. Within the %systemroot%\Document and Settings folder a new folder is created with the username of the particular user. This folder is the first part of the profile. The second part is stored in the registry in the hive [HKEY_CURRENT_USER]. When the user logs off the hive is stored in a file called ntuser.dat, which is saved in the above mentioned folder.


Local profile

As you can see, all settings are stored locally on the machine the user is logged on to. This kind of profile is called a local profile. However, in a company, users can or may log on to several workstations. Of course your user will want the desktop environment to be the same on every machine, but the profiles are stored locally, so this is not possible. Also if the workstation fails the user will lose all his/her settings. Local profiles cannot be (fully) managed by the IT department either.

Roaming profile

To achieve the goal of giving the user the same desktop environment on every workstation, roaming profiles are set up. When using roaming profiles the user profile is loaded from a server, within the infrastructure, to the workstation, when the user logs on. The information is stored back on the server when the user logs off again. Roaming profiles consume a lot of resources, which results in synchronization problems when loading and storing the profile. In practice, roaming profiles are fragile components, which are difficult to administer and manage.

Mandatory profile

Within the Windows environment there is another profile type called mandatory profiles. Within this profile, changes to the desktop environment are not saved when the user logs off the system. Mandatory profiles are easy to manage, fast, and because nothing is saved to the profile, the profile cannot get corrupted.

In current environments it is almost impossible to use mandatory profiles, because usually user settings must be retained. In most cases, roaming profiles are used, with all the associated problems as mentioned above. Retaining user settings is a more important target than the challenges roaming profiles create for the IT department.

Terminal Server and Profiles

Are the challenges concerning profiles the same for Terminal Servers as compared to standard workstation environments or are they even more complicated?

In some ways it gets more complicated when Terminal Servers are part of the infrastructure:

  • If your users use applications both on their workstation and the Terminal Servers then on both systems the user settings need to be retained. Within Active Directory Service (ADS) you can specify a standard profile and a special profile for Terminal Servers. If you do not specify a Terminal Server profile, the standard profile will be used. You can imagine what results that can have if a workstation’s profile is loaded on a Terminal Server (with a different Operating System). Always specify a Terminal Server profile when using roaming profiles with Terminal Servers in the infrastructure.
  • Users log on to different servers when using Terminal Servers on a regular basis because of load balancing. Although the same situation is also possible with a normal workstation (when using flexible workspaces), practice teaches that end-users normally use the same workstation as much as possible.
  • Users log on to more servers at the same time. When using Terminal Servers it is more likely that users are logged on to various Terminal Servers at the same. This is especially applicable when the Silo or Load Managed Groups concept is used. This means that for several applications specific Terminal Servers are not used (in other words not all applications are installed on all Terminal Servers).
  • When using Published Applications (with third party products like Citrix, Provision, GoGlobal and others) there is a big chance that there are more logon and logoff processes than on normal workstations.
  • On Terminal Servers, time limits are often specified for inactive and disconnected sessions, which cause more logon and logoff processes.

The above mentioned examples cause more challenges for the management of the profile environment. Most likely in Terminal Servers, more corruption, lost user settings, and application errors will occur when using roaming profiles.

If you seriously take a look at these challenges, I am sure you would like to achieve mandatory profile attributes like: no corruption, fast load times and easy management, but with the option of saving the needed user settings. Fortunately nowadays this scenario is possible with so called Hybrid or Flexible Profiles.

These profiles use a mandatory profile which is configured and loaded in exactly the same way a mandatory profile is in a 100% mandatory profile environment. Take a look at the Microsoft Knowledge base article 323368 for creating a mandatory profile. (Tip: place the mandatory profile locally on the server, which speeds the loading of the profile). The (specified) end-user settings are stored by logon and saved by logoff by a third party tool, which creates the Flex or Hybrid profiles. The enormous growth of products in this market shows the necessity of these kinds of profiles.

One of pioneers is the Flex Profile Kit by Jeroen van de Kamp. The Flex Profile Kit (FPK) uses a modified version of the Office Profile wizard (proflwiz.exe) to store and save the user (registry) settings. With the FPK you need to specify using ini-file which registry keys need to be saved when the user logoffs. In version 4 of the FPK it is possible to specify folders (think of favorites) and more advanced options like saving and restoring certificates, Windows appearance settings, mouse settings, passwords and support for the Silo or Load Managed Groups. All settings are saved on a file share, so no additional software is needed. The FPK is still a freeware product.

Citrix itself has also realised the necessity and developed their Hybrid Profile. Only Citrix Consultancy Services can implement this product in your environment. Therefore not much information is available on this product. The configuration and the settings are placed in a SQL database.

After the FPK and Citrix Hybrid Profiles were released more commercial products were developed. TriCerat Simplify Profiles, Mancorp Managed Profiles, Terminal-services.net WTS Profiles, Provision Metaprofiles-IT and Jumping Profiles are the best known products.

Most of these products offer the functionality of saving and storing user specific registry keys. TriCerat, Mancorp and Terminal-services.net use a (SQL) database for configuring and storing the user settings. Configuring and managing these products is done via GUI. Every product offers some additional functionality. With WTSProfile you can also lockdown the start menu and desktop appearance based on several filters. Within Managed Profiles an additional Printer Management module is available and folder saving. Simplify Profiles offers a GPO comparable lockdown of the user environment.


Lots of IT departments face challenges when managing their roaming profiles environment. It takes some time to recognize these challenges, but the answer is to use the Flex/Hybrid profile solutions. All these products are developed with a Terminal Server infrastructure in mind, but they are also very usable in a traditional workstation infrastructure. If you are struggling with profile challenges, you should definitely consider using a Flex/Hybrid profile solution. On my own website VanBragt.Net SBC Centre all these products are reviewed, so that is good way to start investigating a possible Flex/Hybrid profile solution.

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top