Last modified:	Thursday, Mar 8, 2007	Article ID:	555
Related products:	Firmware v6.5.x (CE 4.2)

---

Procedures

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 Servers 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).

Thats 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, its 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.

 

Understanding the Terminal Server Session Directory

Author Information Ron Oglesby Brian Madden

December 1, 2004 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 wont 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. Its merely one of the three components that make up a load-balanced cluster of Terminal Servers. Terminal Servers host users?€™ sessions. A load-balancing mechanism routes users?€™ inbound connections. 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 Disadvantages of using Session Directory 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: 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. Requires at least the Enterprise edition of Windows 2003. Requires an external load-balancer. Allows users to reconnect to disconnected sessions. Allows you to enforce single-session only user policies.