Understanding the Terminal Server Session Directory

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.

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.

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

This message was originally posted by an anonymous visitor on December 1, 2004
Any other third party solutions for plain TSs that would give us the same feature?
This message was originally posted by Brian Madden on December 1, 2004
Pretty much all of the third-party tools do this. (Citrix, Tarantella, WTS Gateway Pro, DAT, Jetro, etc.) Check out my article Doc# 99 for the full reviews.
Thanks for the article and the nice break down of the Session Directory. I have a question regarding clustering the Session Directory. Is it possible to cluster the Session Directory on two Terminal Services servers and have the same two servers connect to the Session Directory in the cluster?

When backing up the C:\ drive of several win2003 servers (using Veritas Netbackup 4.5) I get some problems - 5 files are missed by the backup as they are constantly in use.
Do I need to back-up c:\windows\system32\tssesdir ??
it would be nice/easy to exclude that folder from Netbackup. Hopefully this is OK to do as it sounds like the folder is full of dynamically created data that would be pointless to restore. Please confirm.

please reply to bob.lawrence@thomson.com - i don't read this website regularly and just came across it on a "tssesdir" search on google.

I seem to have some problems with Session Directory and the Netware client (v4.91), which is installed on both my terminal servers. 
The problem occurs when someone tries to reconnect to a disconnected session.  If the terminal server that recieves their login request is not the one they left the disconnected session on, then it totally fudges the login info that gets passed onto the server the client should be connecting to.  The result is a failed login message, and several default options being set at non-default settings.  For instance, workstation only will be checked.  There will also be a random login name from one of the other existing sessions dropped into the username field.  The windows part of the login is at this point defaulting to a local login rather than loggin into the domain.  Please email me at mail account name is david.sentelle email domain is cnbcbank.com.  (Not that this will confuse the spammers)
I have run across the same problem with Backup Exec 10, since upgrading to Windows 2003 Server. Is there anything I can do to stop receiving skipped file notifications or can I just exclude the directories safely?  Any assistance is greatly appreciated.
Please reply to dsobkowiak@johnstonmclamb.com and/or to this forum as I will be checking regularly now. Thanks again.

When backing up the C:\ drive of several win2003 servers (using Veritas Netbackup 4.5) I get some problems - 5 files are missed by the backup as they are constantly in use.
Do I need to back-up c:\windows\system32\tssesdir ??
it would be nice/easy to exclude that folder from Netbackup. Hopefully this is OK to do as it sounds like the folder is full of dynamically created data that would be pointless to restore. Please confirm.

please reply to bob.lawrence@thomson.com - i don't read this website regularly and just came across it on a "tssesdir" search on google.


Sorry for being so dense here but I've looked everywhere for the ADM template that controls terminal services but can not find it.  I assume that you need to add a template file to my AD DC so I can configure the policies for the terminal settings.  I've been able to lock down all the office and basic Windows settings that I need but the specifics for Terminal (like session directory) need a different ADM. 
All the settings you are looking for are in the default SYSTEM.ADM file.  Any policy has them.  Make sure your ADM files are at least the same version or newer for the OS/SP on your terminal servers.
Is it possible for remote users to get the same session ID everytime they connect to a single TS machine server 2003 without a session directory server? Is it possible to install a session directory server on the same server 2003 machine with TS in order to assign the same session IDs to the same user name? If yes what names should we enetr for a directory server and cluster? By the way I have spent a loot of time trying to provide the same session ID for TS users with no success. I would appreciate any suggestion on this matter.
I'm also looking for a way assign the same session id for a user everytime beacuse of some printer issues. Or a way to map printers over the INternet. Money is no mather here plese help me.
What exactly are the ramifications of this ?
"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."
Thank you in advance.
What kind of database is session directory?
How can I make a query to the database for the Session Directory?

ORIGINAL: sparol

What kind of database is session directory?
How can I make a query to the database for the Session Directory?


It's an ESE (aka JET Blue) database. ESE is a database engine developed and used a lot by Microsoft (for example in Active Directory and Exchange). As far as I know, there are no regular, free available query tools (like ODBC) for ESE available.
We plan to set up several servers in our network and provide terminal services.
We will set up a domain controller and 2 terminal servers. We pla to set up the terminal servers with NLB and have some questions about session directory.
You say in your article 279 that it Requires an external load-balancer.
Does this meen that you must set up the session directory on the domain controller? (I suppose this is the logical anyhow.)
Session directory requires enterprice edition.
Which of the servers do i need enterprice edition?
only the domain controller or only the terminal servers or both?


I created NLB cluster of terminal servers and configure terminal server session directory on domain controller. all works fine but when i started the terminal server to run in kiosk mode the session directory not maintain the session and user have more then one session on different terminal server. can any one help me in this regard, i shall be very thankful. sory for bad english. my email address is waseemqadri79@hotmail.com  

Since Session Directory was added toNLB, active TS user disconnected had to attempt the reconnection at least 3 to 10 times. Do you know what could be causing this?

I just signed into one of our 2003 sp2 computers (std ed) and it had the session directory service disabled.  I set it to manual, clicked start and it started.  Does this mean only the server that does the mapping needs to be Enterprise Edition or do all servers that participate in the session directory need to be Enterprise Ed? (did this just give me false hopes?) hotmail.com address: fr46duds

External load-balancer here means, Session Directory doesn't or cannot do the load balancing it requires software load balancers like WNLB or hardware load balancing solutions like F5 or Cisco. It's not recommended to setup session directory on a DC and yes it requires enterprise edition. This means the member server running SD will have to be enterprise edition while the TS servers could run Std Edition.

You have to set the "<strong>keep-alive sessions</strong>" policy under group policy


As far as i can tell only the TS servers need to be enterprise !


Terminal server session manager can it work without external load balancer. In Network load balance where we can setup Session manager.


We are planning to deployee Terminal server with network load balance. I have some doubt if possible kindly clear some body. 1.Terminal server load balancing with respect to Network traffic balance or with respect to Log in session?2. Terminal server load balacing if you not installing session manager what is the impact? 3. If primary server down what will happen to RDP connections.


In a  load balanced environment of termianl servers running session directory, what would happen if a user gets disconnected and then the server he was connected to becomes unavailable. Would he not be able to connect to the farm until some timout?


Clustering the Session Directory Service

We have two Terminal Servers being load balanced by an F5 load balancer. We brought up two other servers, both running the Session Directory Service. We have clusted the two Session Directory servers and the service on both boxes will not run when the Cluster service is running. We followed the procedure to create the Generic Resource outlined on this page and no luck. Has anyone done this before? If yes, what did you have to do to get it to work? I know the exe and DB for Session director lives on %system%\system32\tssesdir. Is there a way to move/run it over onto a shared resource between the two servers? (SAN storage). Help please! leiva1@llnl.gov