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.

 

"Session Directory Computers" group is empty

The "Session Directory Computers" group is empty, you must add the computer accounts of Terminal Servers into this group for the Session Directory service to work properly. 

 

There are two different modes for terminal services:
Remote Administration Mode -- this requires no licenses, it allows administrators to log in and perform maintainance tasks remotely.
Application Mode -- this allows users to log in remotely and do work. This requires a license server, and a license for each user that connects.

In win2k3, installing "Terminal Services" installs application mode, which is what you have done. I would try running it in remote administration mode, which can be found under My Computer properties, in the Remote tab. The only restriction is the number of users that can log in.

------------------------------------

 Try uninstalling terminal services licensing.

-------------------------------------

Remote administration mode was allready enabled when I had the terminal server installed. Anything else you can think of that might be the causing the problem? btw I uninstalled terminal services and the same thing still happens.
I also get a new warning message from TermServSessDir
The "Session Directory Computers" group is empty, you must add the computer accounts of Terminal Servers into this group for the Session Directory service to work properly.

I  still get the same thing. It started to log me on then it boots me right off.

-----------------------------------------

Are you running Active Directory on that box? If so, open up Active Directory Users and Computers from Administrative Tools and go to the Users OU. Find the group "Session Directory Computers", and add your computer to it. If you are not running AD, then I'm not sure. You can try adding your computer to the local group (in Computer Management / Local Users and Groups), but I don't think it'll let you outside of AD.   

-------------------------------------------

I am not running AD. I tried adding my computer to the local group like you said above but it wouldn't let me do it outside of AD. Anyway I fixed the problem. A simple Re-installation of remote desktop from the 2k3 cd fixed it. I installed sp1 for 2k3 a while ago and then I had about a month downtime with my comp while I rma'd my crappy koolance water cooled case. After that I got some danger den water block and I built my own watercooled rig. This is the first time I tried remote desktop since I installed sp1. Perhaps that messed something up?? Oh well Its fixed now. Thanks a lot for your time and your knowledge!!
P.S. looks like I spoke too soon, I used to be able to get in om my end now I can't, the same thing is happening, I alos have a friend who is running 2003 server and he is having the same problem with his. This is really ****ing ****ing me off. Does any one know if this is a common problem with 2003 server??
P.P.S Ok this time the problem is definetely fixed. It turned out being the NVIDIA display driver service. Once that was disabled, everything worked fine again. Totally wierd. Anyway Thanks a lot Electro and su root for your input!!

Terminal Services upgrade (tscupgrd.exe)

Windows 2003 server
Tscupgrd.exe and How it Can Affect You
After conferring with Microsoft, their position is “It’s by Design”. 
Their recommendation? Removing the key.

Then:  Remove the tscuninstall value from the Default User’s hive (ntuser.dat):

\Software\Microsoft\Windows\CurrentVersion\RunOnce

and also from:

HKEY_USERS\.Default\Software\Microsoft\Windows\CurrentVersion\RunOnce

Terminal Server user setting tool

SystemTools TScmd - Developed by SystemTools.  A command-line utility to set terminal server user settings.  All eighteen (18) terminal server settings can be set.  Includes documentation in readme.txt file.

tscupgrd.exe

Tscupgrd.exe and How it Can Affect You

DJ_Drunk:

05/23/09 12:43 PM, ID: 24459282

This behavior is By-design and normal since you are running TS in APP Mode. The purpose of Install mode is to enable the TS to run application for Multiple users.
When registry entries are made to HKEY_CURRENT_USER\Software they are echoed to the
Shadow key area.
For any new user, registry entries are copied form the Shadow key to the User's
Profile in registry (HKEY_CURRENT_USER).
This is to make sure that an application installed on the Terminal Server can run
under any users profile.

========================== 

Description on the TSCUINSTALL value in RUNONCE  key

=====================
Key:- Default user key HKEY_USERS\.DEFAULT\Software\Microsoft\Windows\RunOnce
Value Name:- tscuninstall
Value Type :- REG_EXPAND_SZ
Value Data:- %systemroot%\system32\tscupgrd.exe

This value is responsible for the following:-

(1) Deletes short-cuts on the desktop with the target "mstsc.exe".
(2) Deletes the "Terminal Services Client" and "Terminal Server Client" entries
from the Start Menu.
(3) Deletes the client files from Program Files.
(4) Removes registry key that do not contain user settings.
(5) Uninstalls the TSAC MSI files using MSI routines.
(6) Run mstsc.exe /migrate to migrate settings from the registry into RDP files.

Thus the purpose of having TSCUPGRD.EXE in Runonce is to migrate any old Terminal
Services client settings to the newer RDP Client and uninstall Terminal Services Client.

TS error - winlogon failed

Troubleshooting

Logon problems
For a user to log on to a Terminal Server, the following permissions and rights must be granted:

• Allow log on through Terminal Services
  This user right is by default granted to Administrators and members of the local Remote Desktop Users group on the server.
• Permission to use the rdp-tcp connection
  The local Remote Desktop Users group has by default "User access" permission on the rdp-tcp connection.
• Allow logon to Terminal Server checkbox, in the properties of the user account in AD.
  By default, this checkbox is checked for all users.

So on a standard installation of a Terminal Server, you only have to add your users or user groups to the local Remote Desktop Users group on the Terminal Server.

If your TS is also a Domain Controller (not recommended!), then you must do the following:

1. add the users to the built-in domain local Remote Desktop Users group in AD
2. enable the following setting in the Default Domain Controller Policy:

   Computer Configuration - Windows Settings - Security Settings - Local Policies - User rights Assignment 
   "Allow log on through Terminal Services"
   

   and add the Remote Desktop Users group to the list of allowed users
3. add the Remote Desktop Users group to the permission list of the rdp-tcp connection

Modifying the permissions on the rdp-tcp connection can be done in Terminal Services Configuration, or programmatically:

• 290720 - How to Add a User to Terminal Services RDP Permissions by Using WMI (2003)
• 259129 - How to modify or query the RDP connection permissions for Terminal Services (W2K)

Error messages - permission problems

Here are some common error messages which users get when they haven't been granted the correct permissions and user rights:

• "The local policy of this system does not permit you to logon interactively"
  2003: The user account is not a member of the local Remote Desktop Users group. See 289289
  SBS2003: The Remote Desktop Users group does not have the "Allow log on through Terminal Services" right - see 886620
  W2K: The user does not have the "Log On Locally" right in the servers security policy.
• "You do not have access to logon to this session"
  2003: The user account is not a member of the local Remote Desktop Users group.
  W2K: The user doesn't have the necessary permissions on the rdp-tcp connection. This happens when you remove the User group from the properties of RDP-tcp
• "The requested session access is denied."
  Vista: The user account is not a member of the local Remote Desktop Users group
  See 954369
• "Your interactive logon privilege has been disabled"
  The user does not have the "Allow Logon to terminal server" check box selected on the Terminal Services Profile tab of their account.
  2003: The user account is denied Read permissions to the Active Directory directory service. This right is by default denied to the Guest account. See 815266
• "The desktop you are trying to open is currently available only to administrators", followed by
  "You do not have access to logon to this session"
  2003 + Citrix PS3.0 only: Installing Citrix PS 3.0 on a Windows 2003 creates a new RDP-TCP listener. The default properties of this listener allow only the launching of published applications. See 931353 and CTX104106
• "To log on to this remote computer, you must have Terminal Server User Access permissions...."
  2003 + Citrix PS4.0 only: Installing Citrix PS 4.0 on a Windows 2003 creates a new RDP-TCP listener. The default properties of this listener allow only the launching of published applications. See CTX109925

Error messages - misc. problems

• "An error occurred in the licensing protocol"
  Vista: not enough permissions on the local registry to store the client license
  See 187614
• "The remote computer disconnected the session because of an error in licensing protocol"
  XP: Terminal Services service is not started; invalid stored license
  See 921045
• "Because of a security error, the client could not connect to the remote computer"
  W2K + 2003: corrupted certificate on the Terminal Server
  See 329896
• "Because of a security error, the client could not connect to the terminal server"
  W2K: invalid certificate on the Terminal Server
  XP: invalid stored license
  See 323597
• "The terminal server has ended the connection"
  W2K with SRP1: invalid certificate on the Terminal Server
  See 323497
• "The remote computer has ended the connection"
  XP with SP2: DFS client is disabled
  See 898713
• "No authority could be contacted for authentication"
  Vista client to Vista host in 2003 domain: Kerberos service account problem
  See 939820
• "The system could not log you on"
  RDP 6.0 client to XP SP2 host: smart card login problem
  See 939682
• "The remote session was disconnected because another user has connected to the session"
  2008: autologon enabled
  See 947714
• "Your system administrator does not allow the use of default credentials..."
  Vista RDP client with Single Sign-On enabled
  See Problems using default credentials with Vista RDP clients with Single Sign-on Enabled
• "The logon attempt failed"
  Vista RDP client with saved credentials
  See 954397 and Problems using saved credentials with Vista RDP clients and above
• "Winlogon has encountered a problem and needs to close"
  2003: when many users connect at the same time
  See 953675
• "Server is not found in the network"
  2008: when many users connect at the same time
  See 954398
• "Autoreconnect failed to reconnect user to session because authentication failed. (0x0)"
  All OS: autoreconnect enabled and a time-out limit on disconnected sessions can cause this error message.
  A temporary network interruption can cause the remote session on the server to be put into the "disconnected" state, and the time-out limit causes it to end after the limit is exceeded.
  When the user tries to start working again in the session, the rdp client tries to reconnect and fails, producing the above error message as well as EventID 1042 in the EventLog.
• "... Remote Desktop cannot verify the identity of the computer..."
  Vista and Windows 7 client to 2003 / 2000 TS: downlevel RD Session Hosts cannot provide their identity
  See RDP7_to_RDP6

Misc. logon problems

• 2258492 - You notice that the check box "Deny this user permissions to logon to a Remote Desktop Session Host Server" behaves differently in Windows 2003 and Windows 2008
• 982010 - You may be unable to log on a terminal server that has the DisableWindowsUpdateAccess user policy set
• 922044 - A Windows Server 2003 Service Pack 1-based terminal server cannot accept new incoming Terminal Service connections
• 828664 - An access violation error occurs if your Terminal Services information is corrupted
• 914048 - Event IDs 1000 and 1004 may be logged in the Application event log, and Windows Server 2003 Terminal Server client connections and logon tries may sometimes fail, when you try to connect to a remote computer
• 931353 - Error message when you use RDP to connect to a Windows Server 2003-based computer that is running Terminal Server and Citrix MetaFrame Presentation Server 3.0: "The desktop you are trying to open is currently available only to administrators"
• 939820 - Error message when you try to use Remote Desktop Connection to connect to another Windows Vista-based computer in Windows Vista: "No authority could be contacted for authentication"
• 947714 - You cannot create a remote desktop session as an administrator when Autologon is enabled in Windows Server 2008
• 951028 - You are prompted two times for credentials when you use the Remote Desktop Client to connect to a Windows 2000 Terminal Server from Window Vista or from Windows Server 2008
• 954393 - Local credentials are used to log on to a Windows Server 2008-based computer instead of credentials that you entered on a Terminal Services client
• 938449 - Event ID 5719 is logged when you start a computer on a domain, and the computer is running Windows Server 2003, Windows XP, or Windows 2000

Windows Terminal Services Forum

=====================

Terminal Server Profile Path Woes

During a migration process I came accross this odd problem.

I could not change a Terminal Server Profile Path for a couple of hundred users.

I searched the microsoft site but I could not find anything that would help me quick.

Yes I did find this link http://technet.microsoft.com/en-us/library/cc783578.aspx

But my client did not have grouppolicies in place and I did not want to use the "Terminal Services Extension"

I found several partly usefull scripts I combined the best of them in the script below. I really hope you will find this usefull.

Read More at link
=========================

# Start Registry Editor (Regedt32.exe).
# Locate the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA
# Locate the following entry:
Value name: RestrictAnonymous
Data type: REG_DWORD
Value: 1
# Change the value to 0.