In a load balanced environment terminal servers are grouped into farms, with each farm being represented to client machines as a single, computer name with one IP address. The device performing the load balancing redirects connections to each machine in the farm according to it's load balancing algorithm.
Note Terminal servers are required to be running Windows Server 2003, Enterprise Edition, or Windows Server 2003, Datacenter Edition, to participate in a Session Directory-enabled farm.
The Session Directory Database
The session directory is a database that can reside on a server that is separate from the terminal servers in the farm, although it is possible to have it on a member of the farm. The session directory database maintains a list of the user names associated with the session IDs connected to the servers in a load balanced Terminal Server farm.
Connecting to a Terminal Server Farm
When a user authenticates with a terminal server in the farm, the session directory is queried with the user name. If a session with the same user name exists on one of the farmed terminal servers, the session directory will redirect the client towards that terminal server. This allows a user to disconnect a session with applications running, whether intentionally or due to a network failure, then reconnect at a later time to the same session, with the same applications running. While this is a simple matter when the user connects to a single terminal server, scale out implementations, such as server farms, require the session directory to prevent the user from being connected to a different server in the farm and starting a new session.
This section provides a basic overview of a terminal server farm, illustrates the most common load balanced configuration, and discusses how to enable remote desktop connections and install a terminal server.
Terminal Server Farm
Keep in mind that when implementing Terminal Services in a load balanced environment, all terminal servers in the farm must be running Windows Server 2003, Enterprise Edition, or Windows Server 2003, Datacenter Edition, to participate in a session directory-enabled farm. Because a farm is viewed by users as a single machine, all servers in a farm should be as identically provisioned and configured as possible. Additionally, configuring network storage for user data will prevent the orphaning or duplication of data across farmed servers.
The Most Common Configuration
The most common load balanced configuration is for network traffic to be split between two network adapters—one used for terminal services, and the other for access to other network resources and infrastructure, as shown in Figure 1 below.
Figure 1. Common load balanced configuration
For more information on load balancing, refer to your load balancing vendor information. Microsoft Network Load Balancing information can be found in the Windows Server 2003 Help and Support topics under Availability and Scalability. See Windows Clustering—Network Load Balancing Clusters. For additional information on clustering, visit Technical Overview for Windows Server 2003 Clustering Services.
Enabling Remote Desktop Connections
To make certain that servers are properly configured for a load balanced terminal server farm, an administrator should first enable terminal services (it is turned off by default during installation). This may be done using one of the following methods:
· Windows Management Instrumentation (WMI) script.
· WMIC command-line tool—TSToggle.
· Group Policy.
· System applet found in the Control Panel.
Windows Management Instrumentation (WMI) script can be used to enable terminal services. Use the method AllowTSConnections (in the Win32_TerminalServiceSetting class), which can be set to true or false. Below is a sample script. Note that this is named .txt, whereas a an actual script must be named .vbs.
It is also possible to use WMIC to execute WMI script one line at a time. For example:
wmic /node:"SERVERNAME" /user:DOMAIN/USERNAME path Win32_TerminalServiceSetting where servername="SERVERNAME" call setallowtsconnections 1
The WMIC command-line tool TSToggle is a simpler way to enable terminal services quickly by using the following script:
From cmd.exe:
Wmic /NODE:”SERVERNAME” /USER:”Domain/User” RDToggle where ServerName=”SERVERNAME” CALL SetAllowTSConnections 1
From WMIC:
/NODE:”SERVERNAME” /USER:”Domain/User” RDToggle where ServerName=”SERVERNAME” CALL SetAllowTSConnections 1
The Group Policy to turn on Terminal Services is “Allow Terminal Services Connections,” and is located in the Computer Configuration/Administrative Templates/Windows Components/Terminal Services folder.
Note It is strongly recommended that all farmed terminal servers be placed in an organizational unit (OU), with Group Policies applied to the OU.
To find the System applet in the Control Panel:
1. Right-click My Computer and select Properties.
2. On the System Properties page select the Remote tab and check Allow users to connect remotely to your computer box, as shown in Figure 2 below.
Figure 2. Enabling Remote Desktop
Installing the Operating System with Terminal Services Enabled
The TerminalServer switch in the unattend.txt file may be set to perform an unattended operating system installation with Terminal Services enabled:
TerminalServer
Value: On | Off
Default: Off
Specifies whether or not Terminal Server (Terminal Services for multiple users) is installed on the computer. If TerminalServer = On, Setup installs Terminal Server and configures the computer to run in multi-user mode. If TerminalServer = Off, Setup does not install Terminal Server. The value of this entry does not affect the ability to establish a remote connection to the computer using Terminal Services Remote Desktop.
In the Windows Server 2003 family, Terminal Server is applicable to Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; the 64-bit version of Windows Server 2003, Enterprise Edition; Windows Server 2003, Datacenter Edition; and the 64-bit version of Windows Server 2003, Datacenter Edition.
To specify important security settings for a server with Terminal Server enabled, include the [TerminalServices] section and appropriate PermissionsSetting entry.
To specify the type of licensing you are using for Terminal Server, use the LicensingMode entry in the [TerminalServices] section.
Installing Terminal Server
Terminal Server is a Windows Component in the Add or Remove Programs applet, which is found in the Control Panel. Installing this component will ensure that your server is set up to handle multiple session requests from users.
Note This should be done before any applications are installed, because making this change will alter how installations are performed. Remember that terminal servers are required to be running Windows Server 2003, Enterprise Edition, or Windows Server 2003, Datacenter Edition, to participate in a Session Directory-enabled farm.
This section discusses the following: how to install and configure Session Directory server and client server configurations, Session Directory architecture, revectoring clients, and formatting routing tokens.
Installation and Configuration
When planning your Session Directory environment, it is vital to ensure that all terminal servers that will be included in the Session Directory are running at least Windows Server 2003, Enterprise Edition—Datacenter Edition can also be used.
Windows Server 2003, Standard Edition may be used to run the Session Directory service; however, only terminal servers that run Windows Server 2003, Enterprise Edition, or Datacenter Edition, may connect to and use the Session Directory service.
Session Directory Components
There are two Session Directory components to consider when installing and configuring Session Directory:
· Session Directory server
· Client servers
The Session Directory server is the server that is running the Session Directory service. It is not required to be a Terminal Server, or even to have Remote Desktop enabled.
The client servers are the Terminal Servers which will request data from the Session Directory server. Client servers need to be configured to point towards the Session Directory server for Session Directory requests. Architecturally, one Session Directory server may service multiple load balanced farms, although this may cause confusion if the administrator configures all farms to have the same logical cluster name value. (See the Client Server Configuration section below for more information regarding cluster name value).
The Session Directory is very simple to configure. Choose any Windows Server 2003-based computer to host the Session Directory, and start the Terminal Services Session Directory service. The Windows Server 2003-based computer may be within the terminal server network load balanced farm, but this is not necessary. The Session Directory service is installed by default on all editions of the Windows Server 2003 family.
While performance is dependant on the number of client servers, the Session Directory service generally has fairly small CPU, memory and hard drive requirements. A lower-end server (for example, a departmental print server) may be used to host the Session Directory service if the client server load is relatively light.
To start the Session Directory Service
Find the Session Directory Service in the Services section of the Computer Management tool, and open the Property page. To make certain that the service starts whenever the server starts up, it is recommended that this service be configured to start automatically, as shown in Figure 3 below.
Figure 3. Starting the Terminal Services Session Directory Service
Once the Terminal Services Session Directory service is started on a server, both the Session Directory server hosting the Session Directory service and each client server node in the load balanced cluster must be configured. The Session Directory server must be configured to accept connections from authorized computers, and each load balanced cluster node must be configured to use the Session Directory Service on the Session Directory server.
Host server configuration must be done using the Computer Management Microsoft Management Console (MMC) snap-in, while client server configuration may be done by using Group Policy, or the Terminal Services Configuration tool.
Session Directory Server Configuration
To configure the Session Directory server:
1. Turn on the Terminal Services Session Directory service.
This service is off by default, and set to Disabled. Starting this service and setting it to Automatic will ensure that the service starts when the Session Directory server is turned on.
2.When the Session Directory service is started, it will look for a local computer group named, “Session Directory Computers”—if this group does not exist, it will be created. It is possible to create this group prior to starting the Session Directory service.
Note If the Session Directory Service is started on a domain controller this group will be a domain local group and available on all domain controllers, therefore running the Session Directory Service on a domain controller is not recommended.
The Session Directory service will not accept any connections from servers that do not have their domain computer account included in this local group. By default, when the Session Directory Service creates the “Session Directory Computers” group, it is empty—therefore no computers will have access to the Session Directory unless they are explicitly granted access.
3.To grant access to the Session Directory Service, add the computer accounts of each client server node in the load balanced cluster to the group.
4. Adding computer accounts to a local group may be done by selecting the Object Types button shown in Figure 4 below.
Figure 4. Selecting users, computers, or groups
5.In the Object Types dialogue box the Computers object must be checked, as shown in Figure 5 below.
Figure 5. Selecting the Computers object
Client-Server Configuration
Client-server configuration can be done using the Terminal Services Configuration Tool, or with the Group Policy Editor.
Using the Terminal Services Configuration Tool
1.For each server in a load balanced cluster, open the Terminal Services Configuration tool (tscc.msc) and in the left pane click Server Settings..
2.In the right hand pane, from Session Directory, open Properties.
3.On Properties, check Join Session Directory. Add the cluster domain name to the “Cluster name” field, and the Session Directory server name or IP address to the “Session Directory server name” field.
Note that the “Cluster name” must be uniform across the cluster, although this name is arbitrary, and does not need to be related to individual server names or the organizational unit name. Because the Session Directory service may assist multiple Terminal Server farms, the cluster name is used to determine which Terminal Servers are in a single farm. This allows the Session Directory the ability to redirect the same user to different servers when that user connects to different server farms. To reduce confusion specify the name that clients will use to connect to the terminal server farm.
IP Address Redirection
The “IP address redirection (uncheck for routing token redirection)” check box should only be unchecked if:
1.Your load balancing solution does not allow direct connectivity from the client computer to the Terminal Server, (for example, your load balancer is also a router)
2.Your load balancing solution supports the use of Session Directory routing tokens.
Some third party load balancing solutions act as a router as well as a load balancer. When this is the case, the client computer cannot communicate with the Terminal Server directly. Normally, when redirection is performed, the Terminal Server gives the client an IP address to reconnect to. If the load balancing solution is also a router, the client will not be able to connect directly to the Terminal Server IP address.
Un-checking the IP address redirection box will change the way that the Session Directory performs redirection. Instead of sending the IP address of the server to the client, the terminal server will send a routing token with the server's IP address embedded in the token. When the client re-connects to the load balancer, the routing token will be presented to the load balancer. Some third party load balancers support the Session Directory redirection routing token, and will interpret it successfully, redirecting the client computer to the correct terminal server.
Note It’s recommended that you keep the default setting for this option (checked). See your load balancing solution documentation for further use of this setting
Determining the IP Address for Redirection
The “Network adapter and IP address Session Directory should redirect users to” setting determines which IP address the Session Directory will send to client computers for redirection. This setting is necessary because many servers have multiple network adapters and IP addresses—not all of which are visible to the client computer. Choose the network adapter and IP address that client computers should connect to from the drop down box.
Using Group Policy Editor
The most efficient way to manage the Session Directory configuration settings of multiple servers is to set Group Policies using the Group Policy Editor. Group Policies allow administrators to centrally configure Session Directory settings (and a great many other settings) on defined groups of machines. On an individual basis, it may be more efficient to use the Terminal Services Configuration Management tool (TSCC).
In environments where Active Directory® is not deployed (and hence no centralized Group Policy) these settings may still be managed via the Group Policy Editor, by running GPEdit.msc locally on each machine being managed.
Session Directory Group Policy Settings
The Session Directory Group Policy settings are located in Computer Configuration/Administrative Templates/Terminal Services/Session Directory. The settings at this location are: Join Session Directory, Session Directory Server, Session Directory Cluster Name, and Session Directory IP Address Redirection.
· Join Session Directory: Enables or disables participation of a machine in the Session Directory. When unconfigured or disabled, the Session Directory is not specified. When configured, the server(s) affected will also need to have the Session Directory Server name and the Session Directory Cluster Name specified.
· Session Directory Server identifies the computer on which the Session Directory service is running. All servers using the same Session Directory should point to the same server. When disabled or left unconfigured, the Session Directory server will not be specified. Enabling this setting requires that you enter the DNS name or IP address of the server, and that the Session Directory service is started on computer specified as the Session Directory server.
· Session Directory Cluster Name is the name of the cluster that load balances new incoming connection requests among Terminal Server machines in the site. Disabling or not configuring this setting will leave the cluster name unspecified to servers affected. Enabling this setting requires that you enter the DNS name of the cluster that servers affected will participate in. This also allows the Session Directory to distinguish between handling multiple load balanced clusters.
· IP Address Redirection (uncheck for routing token redirection) determines whether or not clients that connect to a load balanced terminal server farm are redirected to a server IP address, or use a routing token to mask the IP address of the destination server.
If the Session Directory is enabled, the Session Directory server field must have a computer name (or IP address) in order to close the dialog. If this field is not populated, or is populated with an invalid server name, the terminal server will generate an event log error stating that the location cannot be found. The possible event log errors relating to the Session Directory are:
· 1001 “The RPC call to join Session Directory to <SD SERVER NAME> got Access Denied.”
· 1002 “Session Directory service on server <SD SERVER NAME> is not available.”
· 1003 “Session Directory server name <SD SERVER NAME> is invalid.”
Clustering the Session Directory Server
To provide high availability for the Terminal Services Session Directory Server on a server cluster, the following tasks need to be completed:
Note Information on creating a server cluster is available in the Help and
1.On all Windows Server 2003, Enterprise Edition or Datacenter Edition systems that are nodes in the server cluster where you want to host the Terminal Services Session Directory server, these nodes must have the service set to automatic. This is done by going to Services.msc and changing the startup value from Disabled to Automatic.
Note If Step 1 is not done, when you attempt to bring the resource online on one of the server cluster nodes, you will receive the error 1069 in the event log from ClusSvc; and the following associated entry in the %windir%/cluster/cluster.log on that node: This is not replicated to all nodes “ERR Generic Service <Generic Service Resouce name>svc: The service is DISABLED”
2. Review the Help and Support topics on Creating Server Cluster Resources, and specifically Generic Service Resources, which are available under the Availability and Scalability topic on the main Help and Support window when launched from the Start Menu.
3.Make sure you have the following resources available in the server cluster configuration, specifying to connect to the server cluster name created during the cluster configuration process; (as seen by running Cluster Administrator (Cluadmin.exe) while being logged on as a cluster administrator account remotely or locally):
· Physical Disk—This needs to be a resource that is not used to store the quorum information, and must be able to failover to all nodes in the cluster that you want to be able to host the Terminal Services Session Directory database. The physical disk must be configured in the cluster before being configured to provide failover of the Session Directory Service.
· IP Address—This needs to be a static IP address that is accessible from all the terminal servers that will be configured in the load balancing cluster so they can update the Session Directory database.
· Network Name—This needs to be a name that is accessible from all the terminal servers that will be configured in the load balancing cluster so they can update the Session Directory database. For security reasons, Kerberos is required for all communication between the terminal server and the Session Directory server, so “Enable Kerberos Authentication” and “DNS Registrations Must Succeed” need to be selected, as shown in Figure 6 below, before bringing the network name resource online.
Figure 6. Selecting Group Name Properties
Note The IP address and network name will be what the terminal servers will specify for the Session Directory server to ensure consistent network connectivity no matter what server cluster node is hosting the Session Directory database. Also, the Cluster Administrator has a wizard, Configure Application from the File Menu, that will configure the IP address and network name, as well as the Generic Service resource, to manage the Terminal Services Session Directory Service.
4.If a cluster group already exits with the IP address, network name and disk resources to be used for the Terminal Services Session Directory server, you can create the Generic Service resource by going to the File menu, and selecting New and then Resource.
5.On the first page of the wizard, as shown in Figure 7 below, fill-in the data fields and then click Next.
· In the “Name” field, specify the name of the Resource—this will be what is displayed in the Cluster Administrator user interface and can be anything you like.
· “Description” is not a required field, but will also be displayed in the Cluster Administrator user interface.
· “Resource Type” should be set to Generic Service, and ‘Group” should be set to the cluster group that contains the resources mentioned in step 3 above.
Figure 7. Specifying properties for a new resource