We touched briefly on the Session Directory service back in Chapter 3 when we discussed the design of your Terminal Server network environment. Since the Session Directory is only used in multi-server load balanced environments, we'll explore it fully here.
The Session Directory is a database that keeps track of which users are running which sessions on which servers. This information is used when a user wants to disconnect from a session and then reconnect back to it in multi-server environments. Without the Session Directory, the system would not know that the user had a disconnected session on a server and might route her to a different server where she would start a new session. In addition to being annoying for the user, this is a waste of resources. A single user could leave many orphan sessions throughout the environment.
Not every multi-server load-balanced environment needs a Session Directory. For example, if your environment is configured so that users are not allowed to leave disconnected sessions on a server, then you won't need a Session Directory.
By itself, a Session Directory does not enable load balancing. It's merely one of the components that make up a load-balanced cluster of Terminal Servers. Figure 7.3 (facing page) outlines these components.
Figure 7.3: The elements of a Terminal Server cluster
- Terminal Servers host users' sessions.
- A Session Directory is the optional component that allows users to reconnect to previously disconnected sessions.
- A load-balancing mechanism routes users' inbound connections. (Load balancing is discussed in the next section.)
Prior to implementing the cluster, determine if a Session Directory Database will be required. In addition to allowing users to reconnect to disconnected sessions, a Session Directory can restrict users to a single Terminal Server session in the cluster. If you wish to use this feature or have the ability to reconnect users to disconnected sessions, you will have to implement a Session Directory.
The downside to using a Session Directory is that the Terminal Servers that participate in it must run at least Windows Server 2003 Enterprise edition, costing about $3000 more than the standard edition of Windows 2003.
Advantages of using Session Directory
- Allows users to reconnect to disconnected sessions.
- Allows you to enforce single-session only user policies.
Disadvantages of using Session Directory
- Requires at least the Enterprise edition of Windows 2003.
- Requires an external load-balancer.
How the Session Directory Works
The Session Directory is a simple Windows service and a small database that run on a Terminal Server in your environment.
When a Terminal Server is configured to participate in a Session Directory, a record is created in this central database each time a session is started. These records are queried or updated by the Terminal Servers in the cluster whenever users log on, log off, or disconnect his session. Users can quickly reconnect to their existing disconnected sessions even though the client has no idea to which server they were attached. The Session Directory service (the database itself) is light on required resources and one Session Directory server can handle multiple Terminal Server clusters.
To use the Session Directory in your environment, two configurations are needed:
- Install the Session Directory database on the server that will host it.
- Configure each of your Terminal Server member servers to participate in that Session Directory.
Configuring the Session Directory Database
You can make any Windows 2003 server into a Session Directory server. It need not be running Terminal Services. Furthermore, the Session Directory service is "preinstalled" on every Windows 2003 server. To use it, simply enable the service (Start | Administrative Tools | Services | Double-click "Terminal Services Session Directory" | Change Startup type to "Automatic" | Apply | Click "Start" button).
Several things happen as soon as you start the Session Directory service. First, a folder called "tssesdir" is added to the system32 folder. This folder contains the database and some supporting transaction log and check files.
Also, a local group is created on the server called "Session Directory Computers." At first this group is empty, but each Terminal Server's computer account must be added to this group to use the Session Directory on that server. It should be noted that if the Session Directory is started on a domain controller, the "Session Directory Computers" group will be created as a Local Domain group.
As this service is fairly light, it can easily be run on a file server for smaller implementations. With thousands of users, however, you might consider a dedicated server (or redundant servers).
That's all there is to it. No GUI configuration tool in needed for the Session Directory service. The task of defining Session Directory clusters falls to the individual Terminal Servers themselves.
Creating High Availability Session Directory Service
The Session Directory can be used to ensure that Terminal Servers are highly-available. However, what happens if the Session Directory itself fails? In addition to losing the ability to make use of the Session Directory features, your users' logon times will dramatically increase as each Terminal Server tries to connect to the Session Directory server. Therefore, in larger environments, it's worth spending the money to cluster your Session Directory server. (In this case the term "cluster" is used in its proper sense.)
Since Session Directory is nothing more than a simple database, the only way to make it fault-tolerant is to cluster it. Fortunately, Microsoft wholly supports Session Directory clustering on a Windows Server 2003 Microsoft cluster. (Of course clustering requires at least the Enterprise edition of Windows 2003.) While some might feel that clustering such a small service is overkill, losing a Session Directory in a production environment can cause major problems.
Clustering is a complex technology. Entire books have been written about Windows clustering, so we won't address it here. However, we will discuss the Session Directory-specific cluster components.
At this point, we'll assume that a two-server Windows 2003 cluster has been created and you're getting ready to create a new resource. In order to cluster the Session Directory Service, follow these steps:
- Set the Terminal Server Session Directory service to "Automatic" on any Windows Server 2003 (Enterprise or Datacenter edition) servers that will host the service.
- Verify that the cluster group already exits with the IP address, network name and disk resources to be used for the Terminal Services Session Directory server.
- Create a Generic Service resource (MMC Cluster Administrator Snap-in | File | New | Resource).
- The New resource wizard is launched. Enter the following information on the first screen:
- Name (This doesn't really matter. Most people use something like "TS Session Dir.").
- Description (not required for functionality).
- Configure the Resource type as a Generic Service.
- Configure the group as the cluster group name already configured for the cluster.
- The "Physical Disk" resource.
- The "Network Name" resource
Configuring Servers to Use the Session Directory
Each Terminal Server in your environment must be configured to participate in a Session Directory. At the most basic level, you need to tell each Terminal Server which server it should contact to find the Session Directory and what cluster name it should use. Think of this as a restaurant reservation. In order to meet your friends, you need to know both the name of the restaurant (the Session Directory server) and the name on the reservation (the cluster name).
We've mentioned previously that a single Session Directory server can support multiple clusters (just as a single restaurant can support multiple parties). What's interesting about this is that you don't configure these cluster names on the Session Directory server itself. Instead, you configure each Terminal Server so that it looks for a specific cluster name on a specific Session Directory server.
In order host multiple clusters on the single Session Directory server, simply specify the same server for multiple Terminal Servers and give each group of Terminal Servers a unique cluster name in its Session Directory settings. The Session Directory server will manage each cluster separately without any other configuration.
Keep in mind that all Terminal Servers that use a particular Session Directory server—regardless of cluster name—must have their computer account in the "Session Directory Computer" group on the server hosting the directory.
Use the following procedure to configure a Terminal Server to use a Session Directory:
- Open the Terminal Services Configuration MMC snap-in and select the "Server Settings" item in the left pane.
- Open the Properties page of the "Session Directory" item in the right pane.
- On the Properties page, check the box labeled "Join Session Directory."
- Add the cluster domain name to the "Cluster name" field. The actual name you choose is inconsequential and never revealed to clients. Just make sure the name is identical on each server that you want in that cluster.
- Enter the Session Directory server name or IP address to the "Session Directory server name" field. (If you're using a clustered Session Directory, this will be the Network Name of the cluster.)
- Ensure that the "IP Address Redirection (uncheck for token redirection)" box is checked. Token redirection is used with some hardware load balancers and is covered later in this chapter.
- The final setting on the server is the "Network adapter and IP address Session Directory should redirect users to." This setting tells the session directory which IP address to send to client computers for redirection, allowing you to control to which network card the client will connect. It also allows you to isolate RDP traffic to a single network card and use a second network card for backend traffic (more on this later).
Configuring Session Directory Options Using a GPO
Since Active Directory will be used in almost every environment where a Terminal Server 2003 Session Directory is used, it's easiest to configure each server's Session Directory settings via a GPO (Computer Configuration | Administrative Templates | Terminal Services | Session Directory).
The only setting that you can't configure via a GPO is the server's IP address used for IP Address Redirection. This setting doesn't matter if you are using Routing tokens, but since it's unique for each server it can't be set within the GPO. It will have to be set in the Terminal Services Configuration for each server.