Advantages of Using Terminal Services

You might think that Microsoft Terminal Services is only good for providing a convenient way for the system administrator to do some remote administration their server. Although it is a great built-in tool for administering servers remotely, Terminal Services running in Application mode can accomplish a good many more things than just remote administration. Some of the ways organizations leverage Terminal Services include the following:

• Simplifies Help Desk duties . Using the Terminal Services administrator snap-in, help desk employees can be given the ability to shadow terminal sessions. With this ability there is now no longer a need to go visit the end user or buy or configure some sort of helpdesk or remote control application to assist in troubleshooting an application or answer a "how do I" question. The help desk employee instead clicks on a session, chooses Remote Control, and can see everything the end user sees in real time and can interact with that user's desktop.

• Reduces software installation and upgrade time dramatically. Instead of upgrading 1,000 desktops with new software, you would just upgrade a dozen terminal servers instead. Maintaining a dozen servers is going to be a lot easier and more cost effective than maintaining 1,000 desktops.

• Makes data protection easier. Use GPOs and Folder redirection intelligently along with Terminal Services and you can guarantee the safety of your users' data. Because all the computing is being done server side you have total control of where data is being saved. You can now know for certain that data resides on file servers where it gets backed up versus local hard drives where data can easily be lost.

• Easily deploys specialized applications. Some organizations have an application or suite of applications that change revisions much too often, or perhaps a difficult application that might take 30 minutes just to install and configure. These types of applications are ideal for Terminal Server. You can now just maintain the applications on a team of servers instead of hundreds or even thousands of individual end user machines.

• Consolidate and simplify IT for hub and spoke environments. Rather than hire unnecessary IT staff for small locations, administrators can use Terminal Services to maintain PCs and applications. Using Terminal Services, a corporation can in essence become its own ASP and serve applications from a central location to those 20 remote offices. This greatly reduces the complexity and cost of supporting the remote offices.

Performance Improvements in Terminal Services 2003

Microsoft's Terminal Services, now in its third generation, continues to evolve . A good number of improvements have been made based on the Windows 2000 platform. Significant enhancements include the following:

• Greater support for low bandwidth connections. Previous versions of Terminal Services did not fair well over low bandwidth connections. With Windows 2003 Microsoft promises marked improvements in low bandwidth performance.

• Greater scalability. At the Windows Server 2003 launch events Microsoft made claims of 2003 Terminal Services being able to support up to twice the number of users as the same hardware would with Windows 2000 Terminal Services. Although this seems a little aggressive to make this claim it must mean significant improvements have been made.

• Easier to manage. Terminal Services now takes greater advantage of Group Policies and remote management is now available through a comprehensive WMI provider.

• Greater client feature set. Terminal Services now supports true color , audio redirection, com port redirection, local and network drive redirection, smart card support, and time zone support.

Scaling Terminal Services

As the number of terminal servers needed and the number of users accessing these terminal servers increase so does the complexity for you. Administrators now have to consider how to scale hardware, how to handle redundancy, availability, load balancing, printing, user data, profiles, and so on. Without proper planning and consideration, Terminal Services can quickly become a burden instead of a blessing.

There are two schools of thought regarding how to scale the hardware needed to support the end users. For example, look at a company that wants to support 1,000 concurrent users and will be deploying a single application that it knows a server with dual 2.0 GHz processors and 4GB of RAM will be able to support 100 concurrent user sessions. One school of thought is consolidation, meaning do as much as possible with as few machines as possible. For this scenario you could purchase three 8-way servers loaded with 16GB of RAM, each machine supporting 350 concurrent users per server. The other school of thought is to tackle the issue with a larger amount of less powerful machines. For example you could purchases 10 dual processor servers with 4GB of RAM, each machine supporting 100 concurrent users per server.

Although both approaches will meet the goal of supporting 1,000 concurrent users, let's look at the pros and cons of each school of thought. Using three 8-way servers, updating applications, applying patches, monitoring performance, and other maintenance tasks only have to be performed on three servers as opposed to 10. Although this might look attractive, using this approach puts a lot of eggs into one basket . If a server has a problem, be it loss of connectivity, a blue screen, a hardware failure, or something else that will cause a service outage , 350 users are now affected versus 100 if you go with more of the smaller hardware.

With the cost of hardware today it will be more cost-effective to purchase 10 dual-processor boxes versus three 8-processor boxes. Terminal Services does not scale linearly with the number of processors. Just because a dual processor machine can support 100 users that does not mean an 8-processor machine can support 400 users. In reality scaling really starts to fall off beyond a quad-processor machine so a lot of money can be saved by choosing the hardware wisely. Blade type servers can be quite cost-effective in this application.

Using the larger amount of smaller servers will allow for more flexibility for you as far as redundancy is concerned . Having a larger hardware pool allows for additional flexibility in terms of where applications are installed. A particular application might be unstable or a huge resource hog and as such you might want to quarantine it to its own set of servers. With the larger amount of hardware you could do this and still have enough resources to support the user community.

Redundancy and Load Balancing

With Terminal Services out of the box load balancing is only available at the server level and not the application level and is accomplished using Microsoft Network Load Balancing or your favorite hardware/software-based solution such as those offered by F5, Cisco, and others. Unfortunately this means there are a few drawbacks of which you must be aware. Load balancing at the hardware level means that if you are publishing individual applications versus whole desktops then every server that is part of the load balancing pool must have the ability to serve up the particular application. This means that the application must exist on all the servers in the pool and be installed using the same path on each server.

Although at first this might not appear to be much of a hurdle , just make each server identical. Unfortunately, that is not always practical. As mentioned before, certain applications might need to be quarantined to a subset of servers, or for security reasons there might be multiple smaller farms of servers assigned to particular organizations within the company. So one large load balanced pool of identical servers might not be the solution. Instead some creative use of multiple load balancing pools might be in order.

For example you could break up your server farm into three distinct groups and create three load-balancing pools for it. Instead of one virtual address on the load balancer being associated with nine identical servers you might use three virtual addresses and associate them with three sets of three servers. Each smaller farm of three servers would be serving a different set of applications. For example, instead of the clients connecting to ts.companyabc.com they could have three separate connections defined that would connect to tsfinance.companyabc.com, tsengineering.companyabc.com, and tssales.companyabc.com. Each of which would be load balancing a team of three servers containing applications associated with finance, engineering, and sales.

Another drawback with the hardware-based load-balancing solution that Windows 2003 now addresses is that of reconnection. Prior to Windows 2003 if a user disconnects from a terminal server session and then attempts to reconnect to a hardware load balanced farm, the user might or might not attempt to connect back to the server where their disconnected session awaits them. Instead the user can end up having to start a brand new session instead of being able to continue working where she left off in the disconnected session. This leads to inconsistency, open files, wasted resources, and ultimately end user confusion and frustration.