TESTING & INTEGRATION GROUP SOLUTION GUIDE Radware WSD and Microsoft WTS 2003 Cluster INTRODUCTION...2 SOLUTION DETAILS...2 SOFTWARE AND HARDWARE... 3 TESTED NETWORK OVERVIEW... 4 CONFIGURATION...5 WSD... 5 MICROSOFT WTS SERVERS AND DOMAIN CONTROLLER... 6 TECHNICAL SUPPORT...7 TECHNICAL SOLUTION GUIDE AUTHOR: Elad Kurzweil DATE: Monday, April 18, 2005 Version: 1.0
Introduction Terminal Services is a technology that lets users run Microsoft Windows -based applications on a remote Windows Server 2003-based computer. In a Terminal Serverbased computing environment, all application execution and data processing occur on the server. In a load balanced environment, a farm of terminal servers have incoming session connections distributed in a balanced manner across the servers in the farm. The session directory (SD) keeps a list of sessions indexed by user name, and allows a user to reconnect to the terminal server where the user's disconnected session resides and resume that session. Solution Details The Terminal Server Session Directory provides functionality to make a group of terminal servers appear more like a single terminal server. It is a database of interactive user sessions that logically connects back-end servers behind Radware WSD solution. All sessions on the cluster are stored in a central database. This database is updated and queried by the terminal servers whenever users log on or off, or disconnect their session while leaving their applications active (disconnect can happen voluntarily or involuntarily). Therefore, users redirected to a random server behind the load balancer can be revectored to the server that already hosts their session. This is how the components are laid out in the Network Diagram : Clients connect through WSD to a virtual server (Farm) and get redirected to an actual server. The destination (initial) server queries the session directory to see if the user has a session on another machine. If so, the initial server "revectors" the client. Revectoring means telling the client to reconnect, then dropping that connection so that the client can try again with its new configuration. Revectoring when Internal IP Addresses are not Visible Externally In the simple case, all IP addresses are visible to all clients and servers. In this case the initial Terminal Server redirects by simply sending the right IP address to connect to next time. For example, if the user has an existing session on USER2 and gets balanced to USER1 by the WSD, USER1 queries the session directory, finds out that the user already has a session on USER2, and simply sends the client the IP address for USER2 and drops its network connection. The client then reconnects directly to the IP address of USER2, and the user logs in to his or her existing session. Unfortunately it is not usually a good idea to keep internal IP addresses visible to the whole world. Therefore the session directory provides for a cookie in the initial packet sent by Terminal Server s RDP protocol when the client connects. In this case, the initial connect works as before. In the redirection phase, though, instead of sending the client the IP address to which to reconnect, the server tells the client to connect to the same (virtual) IP it did initially, but this time it is to provide a cookie which the WSD can parse in order to get the client to the correct server. For example, again the user has an existing session on USER2 and gets balanced to USER1 by the WSD. USER1, again, queries the session directory, and finds out that the user has a COMPANY CONFIDENTIAL 2
session on USER2. This time, though, it tells the client to reconnect to the same virtual IP as before, but it also tells the client to send a cookie at a certain offset in its first packet sent to the server. Then USER1 drops the connection. The client connects to the same virtual IP, and this time it provides the cookie. The WSD looks at this cookie, which contains information on the IP address and port number to which to redirect the client (which are the correct IP and port number for USER2), sets up the proper internal mapping, and the user successfully logs in to his or her existing session on USER2. Software and Hardware The following is a list of hardware and WTS software tested to verify the interoperabilty of the presented solution: Radware s WSD v.7.54 and up. Operating System: Windows 2003 Etnerprise servers Clients : Microsoft Remote Deskop COMPANY CONFIDENTIAL 3
Tested network overview Network Diagram COMPANY CONFIDENTIAL 4
Configuration WSD WSD Network Configuration - Create IP 20.1.1.1/24 on port 1 - Create IP 30.1.1.1/24 on port 2 WSD Configuration - Create FARM in WSD -> Farm -> Farm Parameters with these parameters: o Farm Name WTS Cluster o Aging time 28800 Seconds o Session Mode EntryPerSession - Create WTS Server 20.1.1.100 in WSD -> Servers -> Application Servers with these Parameters o Servers Address 20.1.1.100 o Server Name TS1 - Create WTS Server 20.1.1.101 in WSD -> Servers -> Application Servers with these Parameters o Servers Address 20.1.1.101 o Server Name TS1 - Create WTS Server 20.1.1.102 in WSD -> Servers -> Application Servers with these Parameters o Servers Address 20.1.1.102 o Server Name TS1 - Setup additional supports for WTS, from the menu bar, click WSD -> Farms -> Additional Parameters. Select the farm 30.1.1.200. Set the Terminal Server Port field to the correct TCP port for your implementation. By default, Microsoft uses 3389 unless otherwise noted or reconfigured. Specify the correct port and click Set to finalize configuration WSD Health Monitoring - Enable Health Monitoring for the device in WSD-> Global -> Connectivity Checks and in the Check connectivity Status table choose health monitoring. - Define health checks in the Health Monitoring -> Check Table to check each of the Servers 20.1.1.100, 20.1.1.101 and 20.1.1.102 using TCP port 3389 - Bind the WTS servers health checks to the FARM IP in the Health Monitoring -> Binding Table and use Mandatory option. COMPANY CONFIDENTIAL 5
MICROSOFT WTS SERVERS AND DOMAIN CONTROLLER Verify that these steps are done: - The Terminal Servers should be members of the same domain - Windows Terminal Server is installed on each server that hosts the service - Session Directory service is enabled on one of the WTS servers - Cluster Service for HA on the Directory Service please refer to http://www.microsoft.com/windowsserver2003/techinfo/overview/clustering.mspx Session Directory Service configuration Configuration on Terminal Server 20.1.1.102 - By default the Terminal Services Session Directory service is Disabled you will need to enable and start the service (this example uses server 20.1.1.102 to host the Session directory service) in Start -> Programs -> Administrative Tools - > Services and find the service Terminal Services Session Directory click twice a window will open, chose automatic and start the service. Configuration on Domain Controller 20.1.1.105 - Create a User Group with the users that the Terminal Servers will host in the Domain Controller Server IP 20.1.1.105 Start -> Programs -> Administrative Tools -> Active Directory users and Computers add a user group called Terminal Server Users and add the desired users to the group. - In order to work with all Terminal servers there will need to get permission to all servers these will be done on the Domain Controller Server IP 20.1.1.105, go to Start -> Run and type secpol.msc the Security policy program will pop-up, go to Local Policy -> User Rights Assignments press on Allow Log on through Terminal Server and add the user group called Terminal Server Users - In the Domain controller 20.1.1.105 choose Start -> RUN gpedit.msc o Go to Administrative Templates -> Windows Components -> Terminal Services o Enable Allow users to connect remotely using terminal services o At the same tree go to Session Directory folder and enable Session Directory Services and add in the Session Directory Server field the IP that host the service 20.1.1.102 o Enable Session Directory Cluster Name and add the name Cluster1 in the Session Directory Cluster Name field. Adding Terminal Servers to Session Directory Service. Note: These steps need to do on each Terminal Server. - Go to Start -> Programs -> Administrative Tools - > Terminal Services Configuration - Click on Server Settings then Session Directory - Mark a check in Join Session Directory check BOX, write cluster1 in the Cluster Name filed, add the IP 20.1.1.102 at the Session Directory Server Name field and enable the IP address redirection. COMPANY CONFIDENTIAL 6
Technical Support Radware offers technical support for all of its products through the Radware Certainty Support Program. Please refer to your Certainty Support contract, or the Radware Certainty Support Guide available at: http://www.radware.com/content/support/supportprogram/default.asp. For more information, please contact your Radware Sales representative or: U.S. and Americas: (866) 234-5763 International: +972(3) 766-8666 COMPANY CONFIDENTIAL 7