Blog

While designing a TS farm for one of my clients I recently got to know too much about the Windows 2003 Terminal Services Session Directory. Windows 2008 renamed this to Terminal Services Session Broker.  This little service basically tracks which user is logged onto which terminal server within a TS farm. Without this session directory, users’ sessions can get orphaned, resulting in wasted resource consumption.

In summary the basic configuration is to have multiple TS servers in a farm. These servers can be load balanced using DNS round robin, hardware load balancers (e.g. Alteons), software load balancers (e.g. HAProxy – very good software BTW!!) or Windows NLB. Each of the TS servers are configured with the TS session directory.

When a user connects to the TS, the TS checks for an existing session for the user by contacting the TSSD. If the user does not have a session, the TS allocates a session and allows the user to attempt to logon. If an existing session if found within the farm, the TS issues a RDP redirect (the RDP client needs to be XP or more recent to support this) to the server with the existing session.

This is all good and well, but what happens with the TSSD is unavailable (e.g. during patching or other maintenance windows)?

• Contrary to some documents, users can still logon to the TS servers with the TSSD being unavailable.
• Some documents indicate that the TSSD database is cleared when the TSSD service is restarted. This is not the case either. The TSSD service stores the existing sessions in a jet db under %systemroot%system32tssesdir and will reload the database if it is deemed fresh enough. (I never did find out the definition of “fresh enough”). The tssdis.log file (which needs to be enabled) shows this behaviour.
• MS documents also indicate there is no way to move this database (well for Windows 2003 anyway).

The problem arises when users logon or logoff from the TS servers while the TSSD is unavailable as the TSSD database will have no record of the users’ sessions – again potentially resulting in orphaned sessions.

 The Microsoft documented method to overcome this is to cluster the TSSD service. That sounds good, but what about the TSSD database being under c:windowssystem32? Well the long and the short of it is that the TSSD is cluster aware. However, MS fail to mention that by running the TSSD on server with MSCS installed the TSSD service assumes it will be clustered and expects to be in a cluster service group. The next assumption is makes is that it can use the disk resource in the service group.

In short, the TSSD service can be clustered. When part of the cluster the TSSD service transparently moves its jet database onto one of the shared drives within the service group to provide a HA TSSD service. There is a MS document describing the addition of the TSSD into a cluster but it does not mention that the database is simply silently moved.

The setup document is at http://www.microsoft.com/windowsserver2003/techinfo/overview/sessiondirectory.mspx

(Apparently within Windows 2008 the location of the TSSB database can be changed by altering HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTssdisParameters)

A decent article explaining the TSSD concept more fully is available at http://www.brianmadden.com/blogs/brianmadden/archive/2004/11/30/understanding-the-terminal-server-session-directory.aspx Note that no mention of the tssesdir directory being moved, when clustered, is made however.