Wilco van Bragt - LinkeIn Wilco van Bragt - Twitter rssa 

Basic Concepts of Terminal Server Environments

The main part of the IT professionals thinks Terminal Servers are complex and difficult to administrator. This feeling will be fanned by stories where users are complaining about the performance, strange behavior and so on. This article will describe the basic concepts op Terminal Server Environments. When adopting these concepts in your environment will result in an easy manageable terminal server farm.

 

 

Introduction




Which causes these general considerations of a Terminal Server environment are complex and difficult to manage? Mainly these considerations are based on stories where Terminal Server environments are not stable because applications and printers which are not suitable for Terminal Server environments are implemented. This can result in crashing applications, spooler service or even famous blue screen of deaths (BSOD).

We are not going to discuss this behavior in this article, but also in infrastructures where applications and printers are fully covered administrators often notice strange behavior and not reproducible user errors.

 

Reason number one causing this behavior is that the terminal servers in the infrastructure are not 100% identical. This is the reason that errors are not or difficult to reproduce. The error is occurring only on one or a few servers, because the configuration on the server(s) is different then on the others.

 

Concept Rule Number 1: Automate the installation and configuration

Why should the servers be 100% identical? If I buy a new server it is almost impossible to buy exactly the same server. When talking about the concept that the servers should be the same we are not talking about hardware, but about the installation and configuration of all software components on these servers.

How can you accomplish that all your servers to be exactly the same concerning the software part? There is only one solution for, automate the complete building and configuration of the servers completely. With everything I mean everything, a server should be built and configured without any manual intervention directly on the server.

In a nutshell this means that the installation of Windows 2003 special for a Terminal deployment should be automated. This can be done via unattended installations, cloning, and third party products. I’m not going to discuss this part in detail, because there are already wonderful documents about unattended Windows installation on several websites.

 

If you are using Citrix Presentation Server (or another SBC products) this party should also be installed silent. I will discuss the installation of Citrix unattended in another article on this website later on.

 

Another software, which should be available on the server like monitoring tools and antivirus, should also deployed unattended. This is comparable with deploying the applications which will be published to the users. Best practices about this kind of deployment will also be described in another article, which will be available soon.

 

Chronology of the application installation.

Only one thing concerning the (management) applications is important for this article, which need be described to understand the following rule.

Several manufacturers are building a lot of applications. Often these manufacturers are using shared resources or support software. Every installation often installs his “own” files within these shared directories overwritten earlier or other version of the existing files. Normally a manufacture does not mention every file his software is installing or using. In other words it is almost impossible to know which files are installed or overwritten when you are installing a new application on your system.

 

So if you install a new application on your existing Terminal server there is a big change this installation is overwriting some file which are also used by one (or more) existing application(s). This can cause that some existing applications are not functioning anymore or there are some behavior changes. Let focus on these behavior changes. If we install the applications in a different order on several machines, the behavior of the applications can be (and often is) different. This explains why lots of problems are not reproducible. They only exist on one machine because the installation order is causing the different behavior. To prevent this different behavior all the applications should be installed in exactly the same installation order on all the machines. This installation order is tested so you can ensure that applications are working properly and guarantees that all the applications are working exactly the same way on all the servers. In SBC terms it is called the chronology of the applications installation. As mentioned earlier this best to gain this is to use automated installation packages of these applications.

 

These packages should be deployed in such way that the chronology is guaranteed. Making a numbered list is one of the easiest ways, but remembers that some deployment tools (like Altiris) are using their own internal system to create the order of the deployment order. So if you are assigning more then one job to the target machine the jobs could be installed in a different order then you meant it.

 

Separation of the installation and configuration part

Normal application installation actually exists of two parts. The first part is adding the binary files of the application to the system and some settings to make it possible to start the application. The second part is configuring the application itself so it satisfies your needs. You can think of connection to database servers, file shares, the view settings in the application, the place of toolbars and so on.

Although it sounds like a good thing to combine these two parts together, it is actually not a good idea. By separating the installation of the binary files and configuration for the company needs you are much more flexible when something is changing in the needs or to the infrastructure. For example the database is moved to another server you only need to adjust the configuration part and not the package.

 

Separation of the User and the Machine part

Even more important is to separate the user and the machine part. Every application consists of a machine part and a user part. The machine part is normally installed on one of the local discs in the server and registry setting in the keys HKEY_LOCAL_MACHINE and/or Classes Root. To following properties apply to the machine part: the data is static, errors have a high impact, 20% of all changes are applicable to the machine part and no back-up is necessary. The machine part can be managed via machine policies, unattended installations and configuration scripts (for example a startup and shutdown scripts)

The user part of an application can be found in the user profile and the user home drive and in the registry within the HKEY_CURRENT_USER. The user part are recognized as dynamic, low impact for the whole organization by errors, 80% of the changes are allocated to this part and a back-up is necessary. User policies, login scripts and third party software are tools that are used to manage this part.

 

Shadow Key

If applications are installed on a Terminal this is normally done via Add/Remove programs or via change user /install command. This sets the Terminal Server in installation mode. When an application within this installation mode writes registry keys to the HKEY_CURRENT_USER Microsoft writes this key also in the HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software. These values in this key, called Shadowkey, will be applied to a user when he logs on to the Terminal Server if no keys (or older keys) are found in his profile based on a time stamp. Because the checking is done on time stamp you can experience strange behaviors if a new server is applied to your infrastructure. This behavior occurs because the values in the Shadow key got the time stamp when they are installed. Users can have different settings in their profile, but with an older timestamp. When these users logs on to new server, the Shadow keys settings are written in their profile because the date is newer than the setting in the user profile, which is logically unwanted. Microsoft recognizes this behavior in knowledgebase article 297379. In this article three solutions are proposed.

  1. Use Sysprep and "image" new servers. This ensures that new servers inherit the registry timestamps from the original build.
  2. Write to HKEY_CURRENT_USER\Software in Install mode with the system clock set in the past.
  3. Remove shadow keys that could potentially overwrite user preferences

Solution one is not desirable because changes to your environment are difficult to manage/arrange when applications are available in an image. Solution two and three works perfectly. When using solution two your unattended scripts should need to have some logic to change date stamp of the new values created by the application in the Shadow Key. It is preferable to delete all keys in the Shadow Key when using solution three. These values should be monitored during packaging of the application and then added to the user login scripts (or something similar). My personal opinion is that solution three is the best solution, because you can manage the values in the easiest and best way.

Use a DTAP environment

DTAP stands for Develop, Test, Acceptation and Production. Because are main goal is to guarantee that all server are 100% identical every new setting, application installed should be tested rigorous. To ensure this several environments are needed. Sometimes the Development and Test environment can be combined for the Terminal Servers. Dependent of your complete infrastructure some back-end infrastructure (like file, exchange and some database functions) can also be combined, but try to separate these functions in at least two parts. One for Development/Test and one for Acceptation/Productions.

Profiles and Printer drivers

The last two rules in the Terminal Server basics are restrict the usage of profiles and printer drivers. On MSTerminalServices.org several articles are already published like Terminal Server and the profile challenge and How can third party software solve your Terminal Server printing problems so it is not necessary to go into detail about these two in this article.

Conclusion

To keep your Terminal Server in good shape and easy management you servers should be 100% identical. This is the only way to ensure that all servers are responding the same way on all requests. Using the basic concepts like chronicle installations, separating user and machine part,  usage of the Shadow Key, using a DTAP environment are necessary to achieve to goal to make and keep your server identical. 

Article previous published at MSTerminalServices.org.