Publishing Windows 2008 Terminal Services Farm (session broker) behind IAG 2007
The Terminal Server Session Broker Load Balancing feature allows to evenly distribute the session load between servers in a load-balanced terminal server farm. With TS Session Broker Load Balancing, new user sessions are redirected to the terminal server with the fewest sessions.
Using TS Session Broker to load balance sessions involves two phases:
1. In the first phase, initial connections are distributed by a preliminary load-balancing mechanism, such as Domain Name System (DNS) round robin. After a user authenticates, the terminal server that accepted the initial connection queries the TS Session Broker server to determine where to redirect the user.
2. In the second phase, the terminal server where the initial connection was made redirects the user to the terminal server that was specified by TS Session Broker. The redirection behaviour is as follows:
• |
A user with an existing session will connect to the terminal server where their session exists. |
• |
A user without an existing session will connect to the terminal server that has the fewest sessions. |
For more details on Session broker please refer to the following TechNet article:
Publishing Terminal Server farm using Windows 2008 Session Broker server behind IAG 2007 appears to be a challenge. You would be essentially publishing it as one of the Terminal Services application over an HTTP/S Trunk. The problem is when you publish the session broker server via IAG assuming that DNS Round Robin configured for load balancing will enable session broker to distribute the terminal session to the backend farm effectively it will not work for end user connecting through IAG to this farm.
IAG is aware of only one published Terminal Server – the Session Broker – and will therefore route terminal service requests from end users only to this server. What Session Broker does for load balancing at the backend is that it redirects sessions to another terminal server in the farm, and this is essentially a new session request from IAG perspective each time.
When, after being load balanced, this traffic is sent from the client back through IAG towards another terminal server in the farm, IAG will not treat this as a valid request since in the IAG configuration the Terminal Services application exposes only the Session Broker server. With this configuration when a client connects via IAG server to a Session Broker managed farm, the client gets an error message saying “the client cannot connect to the remote computer”, as no handling is performed by the IAG SSL VPN components on the client side in order to intercept RDP traffic to this other terminal server.
To solve this problem we have to consider using Socket Forwarder and publishing the entire Terminal Server farm and not only the Session Broker server.
Here is the step by step configuration:
1. Publish the Terminal Server application for the entire farm by specifying all the terminal servers IP addresses (single/ranges/subnets) and hostnames (all listed manually or by using wildcards).
2. Set one Terminal Server as the jump-start and set it as a lead server.
3. The MSTSC.exe client will connect initially to that server, but if the TS session broker will "redirect" to another terminal server in the farm (either by its name or its IP address) the Socket Forwarding component will intercept and route that RDP traffic to the appropriate server seamlessly.
4. Without Socket Forwarder installed, only the first server on the list is supported.
Author: Faisal Hussain
Developer Support - Security
UK GTSC Developer Internet Team