Part 5 – When to Use and Not Use Terminal Services
by Greg Shields
When considering leveraging Terminal Services in your environment, there are a number of situations in which its use makes sense. There are also a number of situations where hosting applications atop Terminal Services will actually reduce their performance. When thinking about those applications you want to host atop Terminal Services, keep in mind a subjective metric I call the user’s experience. This metric is subjective because it effectively measures the user’s ability to accomplish tasks on a Terminal Server in comparison with the level of performance the user would normally see in running that application locally.
The goal of any Terminal Services deployment is to maintain the user’s experience for each of the applications you plan to host. If users do not see at least the same level of performance and functionality with Terminal Services-hosted apps as they saw with those that were previously local, they are not likely to be happy with the result.
To that end, consider a few situations in which Terminal Services is a good idea for hosting applications:
- Applications that need access from anywhere. When users have a need to access an application and its data from multiple locations, the application is a good candidate for Terminal Services. With Terminal Services, the RDC, and the correct networking configuration, you can make an application available anywhere. This is of particular use for apps used by remote users, and particularly helpful for applications whose local installation you don’t want to maintain remotely.
- Applications with low resource needs. A Terminal Server involves the cohabitation of multiple users on a single server. Thus, the actions of one user affect others. Because of this, applications that have high processor and memory use will have the result of lowering the number of users that can simultaneously be hosted on a single server. The best method for determining the resource needs of applications is to measure PerfMon counters on a system where that application is installed locally and being used. The next part in this series will discuss counters you might consider when determining which applications are right for hosting on Terminal Services.
- Applications that require regular patching. Because Terminal Services moves applications from the desktop to the data center, the count of installed instances is significantly reduced. For apps that require regular patching, this setup reduces the overall administration of installing patches.
- Applications where configuration control is necessary. In the same vein as the previous bullet, applications that require a high level of configuration control for their proper functionality are excellent candidates for Terminal Services. With apps installed in a fewer number of locations, maintaining that correct configuration-either through local or Group Policy control-is made much easier.
- Poorly-coded or problematic applications. Applications that consistently cause problems on installed desktops also make good candidates because the Terminal Services environment provides an easy way for IT to remotely administer the environment when these applications cause problems. Eliminating the local installation of these applications reduces the number of administrative touch points for IT to manage across the environment.
- Applications that require high security. Lastly, some applications and the data they work with are considered highly sensitive to your environment. Terminal Services provides a smaller number of interfaces that users have with that sensitive data. This enables better control over your sensitive data by reducing the number of touch points that users can connect with that data.
At the same time, there are a number of situations in which Terminal Services is not the best solution for hosting applications. Consider the following situations as those where Terminal Services may not be a good solution:
- Applications that have high resource needs. Applications that have high needs for physical resources such as processor and memory are often not good candidates for Terminal Services. Such is the case because these kinds of applications tend to require lots of hardware resources, reducing the number of simultaneous users that can use them.
- Applications that have “spiky” resource use patterns. Even more problematic are applications that have “spiky” patterns of resource use. These applications can run with little usage for periods of time before requiring spikes of resources. These spikes in resource needs impact the available resources for other users on the same server, reducing their user experience through slowdowns, pauses, and hesitation. These types of applications are often the most difficult to track down because the resolution of PerfMon monitoring often cannot “see” the spikes when they occur.
- Applications that require offline usage. Applications that require usage when not connected to a network are not good candidates for Terminal Services. Any application used by Terminal Services must be connected to a network to be used.
- One-off applications. The decision to host an application on Terminal Services also involves the decision to support that application over its entire life cycle. That determination involves a cost to IT in terms of time and money. Applications that have a very limited install base may not be good candidates due to this added cost.
Obviously, your mileage will vary when it comes to the applications you want to host on Terminal Services. The major factor in any determination is performance. Measuring the performance of applications and their impact on user experience is crucial to maintaining a successful Terminal Services environment. Be aware too that the decision to add applications after your Terminal Services environment is set up is another activity that requires a look at how that application will impact the performance of others collocated on the same server.
About the Author
Greg Shields is an independent author, speaker, and IT consultant, as well as a Partner and Principal Technologist with Concentrated Technology. With 15 years in information technology, Greg has developed extensive experience in systems administration, engineering, and architecture specializing in Microsoft OS, remote application, systems management, and virtualization technologies. He is a Contributing Editor and columnist for TechNet Magazine and Redmond Magazine, and serves as the Series Editor for Realtime Publishers, the world’s leading provider of high-quality content for the IT market. Greg is a highly sought-after and top-ranked speaker for both live and recorded events, and is seen regularly at conferences like TechMentor Events, Microsoft Tech Ed, VMworld, and more. He is a multiple recipient of Microsoft “Most Valuable Professional” award.