TS Session Broker

If you adopt TS for any of your technology needs, you will be impressed with how scalable Windows Server 2008 is with it. Unlike Windows Server 2003, which peaked at 800 users on 16 cores and saw no additional benefit as additional cores were added, Windows Server 2008 continues to scale, supporting nearly 1,200 users on a 32-core box. This does not necessarily mean you can make do with only 1 terminal server in your environment. Depending on the applications and the work being done, sessions may use a lot of processor or memory, which may limit the number of real users that can be supported. More importantly, you can’t put all your eggs in one basket. You need multiple terminal servers, known as a farm, for redundancy and load-balancing purposes. You don’t want to have to give the users multiple terminal servers to connect to, with instructions that if one is not available, go to a different one.

As shown in Chapter 18, “Highly Available Windows Server 2008,” there are various options for high availability, one of which, network load balancing, would seem to be a good fit. It enables a single IP address and name to point to multiple servers. In this case, you could have a name such as tsfarm.savilltech.net that could point clients to savdalts01.savilltech.net, savdalts02.savilltech.net, or savdalts03.savilltech.net, and if a server was unavailable, the network load balancer would stop pointing clients to the unavailable terminal server. This is a fine solution with nothing else needed if users logged on and logged off. However, that is not always the case with terminal servers. Users often log on to a terminal server, disconnect, and then reconnect to their sessions. If the users connect to a farm of terminal servers via a network load balancing solution, they are connected to one of the available terminal servers. If they disconnect and reconnect, the network load balancing might connect them to a different terminal server than the one they were originally connected to, so they would have lost their session and any open work. They may keep reconnecting, hoping to eventually get put back through to the original terminal server.