Wilco van Bragt - LinkeIn Wilco van Bragt - Twitter rssa 

How to Ensure your application is TS aware

Although more and more manufactures are aware of the Server Based Computing concept and which impact this can have on the usage of the application there are still lots of applications which are not compatible with Server Based Computing. In this article I will describe which tests you need to go through to ensure that the application is ready for your SBC infrastructure.

Step 1: Inventory of the application


The starting point for a new application on your SBC environment is to determine of the application can be installed on the Operating System of your Terminal Servers. At this moment this will probably Windows 2003, but soon this can also be Windows 2008 (with the same compatibility issues as Microsoft Vista). To accomplish this read the documentation of the product, consult the website of the manufacture or call the manufacturer. 

If you have the possibility to contact the manufacturer always ask him the question if the support the application when it runs on Terminal Services or Citrix Presentation Servers. I have seen applications that runs perfectly using Terminal Services, but the manufacturer did not supported this. When an error occurred within the application the customer was forced to reproduce the error on a traditional installed client before they would accept the bug in their product.

Beside determine if the application can be run on the operating system you should also consider if the application is suitable for the Terminal Server infrastructure. If you already know that the application has characteristics like a high update frequency, high resource usage or similar consider to deploy the application using another method, otherwise you can continue to step 2.

Step 2: Install the application manually on the test server

If you can not resolve if the application is compatible with your operating system just install the application on a test server and see if the application installs without errors.

But also if you found out that the application can be installed on your operating system, you should not skip this step.

With this step you can also find out which kind of information you need to enter during the installation (like database or file share connections, port numbers, etcetera) and monitor where files are stored during the installation. Also check if the installation fills the shadow key and follow the recommendations to ensure that this not changes the behavior or the user experience.

Step 3: Create unattended package

In the article Basic Terminal Server Concepts one the recommendations is to deploy the applications via an unattended script. This is the only way to guarantee that the application behavior is exactly the same on all servers. Preferable use the unattended options provided by the manufacturer or the unattended options provided by MSIExec or Installshield or if this is not possible repackage the application to a MSI package.

Of course this is the old style way nowadays you should really consider using an Application Virtualization product to deploy applications.

Not a real phase to ensure that the application can be used in Terminal Server environment, but still mentioned because it is really important to perform this action when using unattended installations. Let your colleague roll-out your created unattended installation (or virtualized application) to ensure that the application is correctly installed by our package.

Step 4: Multi Server Test

When the applications is installed and configured correctly it is time to start testing the application for Terminal Server compatibility. Remember to carry out all the tests with a standard user account with no privilege rights (like local administrator rights).

The first test you need to perform is test often called multi server test. Therefore you need to have at least two Terminal Servers with the application installed on it. You log on to the first server and start and use the application. Change some settings within the application and close the application. Start the same application with the same user account on the second server and see if the application behaviors are the same and that your changed settings are also applied.

If this fails most often the applications stores the settings on a non-user specific location. For example an application that writes the settings in configuration file in the application directory. Happily this application had a start-up parameter to specify this configuration file, so we added this parameter with a redirection to the user's home directory. To troubleshoot issues in this phase think about profile management and registry redirection tools.

Step 5: Multi User Test

The second really important test is the multi user test. To carry out this one you need to have at least two normal user accounts and one server with the application installed. During this test the application need to be used by the two user accounts on the same time, using the same component and options in the application. Logically both users should see the application on their screen and could use it without any errors.

One of my experiences with this one is that the application started by the second (or following) user started in the session of the user which started the application first. The manufacturer of the product created a solution for this behavior by assigning each user a specific user variable, which was checked during startup to determine in which session the application should be displayed.

Step 6: Performance Test

Especially when you are situated at customers you do not have any experiences with the behavior of the application concerning resource usage. Therefore you should perform a (small) performance test to monitor the behavior. To accomplish this test you need one server with the application installed on it and a number of user accounts. The amount of users depends on how long and with which conditions you would like to carry out this test. During the test let (key) users work with the application as they are used to be and monitor the most common resources. Start with one user and monitor the resource usage, followed by adding a second user and keep monitoring the application usage. Mostly using around 5 users you can see a trend how the application behaves. You could consider using test tools and automated script to simulate user actions within the application.

Standard I will monitor the following performance counters:

Processor; processor time %, System; Processor queue length, Memory; Pages/sec, Network interface; Bytes sent/sec, Network interface; bytes received/sec, Physical disk; % disk time, Physical disk; current disk queue length and Server; server sessions. If one of these counters shows a high value you can add more counters to find more detailed information about the usage. Determine the maximum value of the counters to pass the application this test.

Step 7: Combination Test

Last but definitely not the least is the combination test. In this test you add the application to a server where also all the other applications are installed on. Within this scenario you are testing that all applications are still functioning the same way when a new application is added. Logically we also test the new application it selves works with the other application. This test can be time consuming because you need to start at least all available application once and carry out some basic tasks within the application. If you created a script for the performance test you definitely should use these also for this test, otherwise determine strictly which tasks within the application are included in this test.

Logically if you have virtualized application this step is much easier, because the risk of conflicting applications is reduced to almost zero. The same applies if you are repacking the applications and have a conflict database. You could test the integration of the application with the local applications, although issues on this area are normally not Terminal Services related.


In this article the steps are described to ensure that the applications are capable to be used on terminal servers. If the application fails one of these tests you can start troubleshooting and find a possible solution. If there are no solutions or work around at the end you sadly need to conclude that the application can not be presented to your users via Terminal Services and should be offered via another method.