Understanding the Terminal Server Session Directory

http://www.brianmadden.com/blogs/brianmadden/archive/2004/11/30/understanding-the-terminal-server-session-directory.aspx
by Brian Madden
I briefly mentioned Session Directory in yesterday's article. I've received a lot of email since then about it, and I think there are several misconceptions about what the Session Directory does and doesn't do. The Session Directory is nothing more than 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. Also, if you're using a third-party tool like Citrix MetaFrame Presentation Server, then you will not need to use Microsoft's Session Directory since MetaFrame will manage it for you.
One important fact about Session Directory is that by itself, a Session Directory does not enable load balancing. It’s merely one of the three components that make up a load-balanced cluster of Terminal Servers.

1. Terminal Servers host users’ sessions.
2. A load-balancing mechanism routes users’ inbound connections.
3. A Session Directory is the optional component that allows users to reconnect to previously disconnected sessions.

Prior to implementing the cluster, you need to 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 want 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 their session.s 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 (in terms of 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:

1. Install the Session Directory database on the server that will host it.
2. 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 does not have to 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.
Since 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. 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:

1. Set the Terminal Server Session Directory service to “Automatic” on any Windows Server 2003 (Enterprise or Datacenter edition) servers that will host the service.
2. 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.
3. Create a Generic Service resource (MMC Cluster Administrator Snap-in | File | New | Resource).
4. 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.
5. On the next screen, select the nodes in the cluster on which you wish to host the Session Directory Service.
6. On the Dependencies screen, specify that two resources need to be online before bringing the Session Directory service resource online. These two resources are:
   • The “Physical Disk” resource.
   • The “Network Name” resource.
7. On, the Generic Service Parameters screen, configure the Service name as “TSSDIS,” and check the box next to “Use Network Name for computer name.” TSSDIS.EXE is the EXE that loads the service. Using the network name for the computer name allows computers to connect to this service despite which physical server they actually get connected to.
8. On the Registry Replication screen, the Terminal Services Session Directory Service requires the following: System\CurrentControlSet \Services\Tssdis\Parameters. Notice that this entry does not contain “HKEY_Local_Machine.” Type the entry just as it is listed above to configure the nodes in the cluster to replicate these registry entries between them and allow service settings between servers to be identical.
9. Once you’re finished with the wizard, verify that the resource appears in the Cluster Administrator and bring the service online (Right-click on the service name | Bring On-line).
10. Finally, since your Session Directory service is running on multiple servers, create a domain group for use in the Terminal Servers Session Directory local groups on your clustered servers. This domain group should contain all of the computer accounts of the Terminal Servers that will act as clients to the Session Directory Cluster. Once the group is created, add it to the local group on each Session Directory server.

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:

1. Open the Terminal Services Configuration MMC snap-in and select the “Server Settings” item in the left pane.
2. Open the Properties page of the “Session Directory” item in the right pane.
3. On the Properties page, check the box labeled “Join Session Directory.”
4. 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.
5. 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.)
6. 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.
7. 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.
=======================================
Windows Server 2003 Terminal Services Session Directory

A. Imagine that you have multiple terminal servers and instead of letting users connect to one of them by individual name (which is problematic), you create a Network Load Balanced (NLB) cluster that collects all the terminal servers into a terminal server farm and users connect to the DNS name or the IP address of the NLB. The incoming connections are then automatically distributed to one of the terminal servers in the NLB cluster. However, if a user disconnects from a session (which means the session is still available on the terminal server) and later attempts to reconnect, the NLB cluster may redirect the user to a different terminal server instance and thus a new session is created on that terminal server.
The solution is a terminal server Session Directory server, which keeps track of user sessions in a simple database. When a user requests a new connection, the Session Directory server checks for the user account and if a disconnected session is found, the server directs the user to resume that existing session.
The Session Directory can run on any server, but ideally, it shouldn't run on any of the terminal servers in the farm. One note, only terminal servers running Windows 2003 Enterprise Edition can communicate with session directory--not the standard edition. To enable the Session Directory on a server, perform these steps:

1. Log on as Administrator to the server that will host the Session Directory.
2. Start the Microsoft Management Console (MMC) Computer Management snap-in (Start, Programs, Administrative Tools, Computer Management).
3. Expand "Services and Applications" and select Services.
4. Right-click Terminal Services Session Directory and select Properties.
5. Set the Startup type to Automatic and click OK.
6. Now select the "Terminal Services Session Directory" and click Start.

The Session Directory database is now stored in the %systemroot%\system32\tssesdir folder, and if you look at the files, you'll see it's an Extensible Storage Engine (ESE) database (the same kind that Microsoft Exchange Server uses). The installation also creates a group called "Session Directory Computers" to which you must manually add the computer accounts of each terminal server that will participate with the Session Directory. (The computer account is the name of the computer with a $ at the end (e.g., savdalts01$.) To configure the terminal servers to use Session Directory, configure each terminal server via the Session Directory setting under Server Settings of the MMC Terminal Services Configuration snap-in. Alternatively, you can use the Group Policy setting under Computer Configuration, Administrative Templates, Windows Components, Terminal Services, Session Directory. Set the "Terminal Server IP Address Redirection" and "Join Session Directory" to Enabled; set "Session Directory Server" to the name of the session directory server and "Session Directory Cluster Name" to the name of the NLB terminal server cluster. The settings will take effect after Group Policy has refreshed. The only setting you might to check on the terminal servers is the NIC that users are redirected to (if you have multiple NICs), as the figure shows.