Thoughts from the EPS Windows Server Performance Team
Useful Microsoft Blogs
It's Day Twenty-Four. Only three more days until Launch Day! Our Windows Server 2008 series continues today with an overview of Terminal Server Session Broker. Terminal Server Session Broker (TS Session Broker) is a role service in Windows Server 2008 that allows a user to reconnect to an existing session in a load-balanced Terminal Server farm. As with the Session Directory service on Windows Server 2003, TS Session Broker stores session state information that includes Session ID's and their associated user names, as well as the name of the server where each session resides. Installation of the TS Session Broker role service installs and starts the TS Session Broker service (tssdis.exe).
Windows Server 2008 introduces a new session management feature - TS Session Broker Load Balancing (SBLB). This feature enables you to distribute the session load between servers using DNS round robin. This solution is easier to deploy than Windows Network Load Balancing (NLB). To participate in TS Session Broker load balancing, the TS Session Broker Server and the Terminal Servers in the farm must be running Windows Server 2008 Standard, Enterprise or Datacenter Editions. Windows Server 2008 servers can join a Windows Server 2003 Session Directory farm. Issues around providing a consistent user experience between different server versions are apparent. However, from a brokering technology perspective, this is seamless to the end user. Windows 2003 Terminal Servers can also join a Windows Server 2008 Session Broker farm - however, in order to use the Session Broker Load Balancing feature, all of the servers in the farm must be running Windows Server 2008.
Let's briefly go over some of the architecture pieces of Terminal Server Session Broker - specifically the Jet Database on the Session Broker Server and the re-vectoring logic used by Terminal Servers participating in the Session Broker farm that ensures that a client is redirected to the proper node. The Session Broker stores session state information in a Jet database. This database (tsesdir.edb) is located on the machine running the TS Session Broker Service in the %systemroot%\system32\tssesdir. To change the location of the database, you will need to modify the location by using the registry. The appropriate registry key is: HKLM\System\CurrentControlSet\Services\Tssdis\Parameters. Select the WorkingDirectory value and modify the database location as needed. Once you specify a different path, you will need to restart the TS Session Broker service for the changes to take effect. Once the service is restarted the database is created in the path you specified in the registry. In addition, the tssdis.log file is also created in this folder.
The TSSesdir folder contains the following files:
Within the tssesdir.edb, the following fields exist:
Although there are a number of fields listed in the Session Broker database, not all of these parameters have to match in order to reconnect a user to their disconnected session. The UserName, Domain and application-type fields are the parameters that the Session Broker uses to determine if a request should be reconnected to a disconnected session. If a user connects with a different initial program specified in the RDP client, then they will not reconnect to their disconnected session.
Redirecting a user to their disconnected Terminal Server session, referred to as client re-vectoring, occurs in one of two ways depending on the configuration of the load balancing solution being used. In some configurations, the nodes are externally addressable using an internal node IP address. In other cases, only the cluster address is available externally - the internal node IP's are only available for communications between the nodes in the cluster. If the internal node IP addresses are available externally, the initial Terminal Server node can pass re-vectoring information to the client that includes the internal IP address of the alternate node. This enables the client to connect directly to the Terminal Server node, bypassing the load balancing infrastructure. This is known as IP Address Redirection. If the client cannot directly connect to a particular node, then the initial Terminal Server node provides the client with a routing token, known as a Session Broker cookie. This token is used in the reconnection to the cluster address to indicate to the load balancing solution that the client needs to be directed to a particular node. IP Address Redirection is the default method used by Terminal Servers participating in Session Broker, and is the only method supported by NLB on Windows Server 2003. If a third party load balancing solution is in use, and the node addressing is not available externally, Routing Token Redirection can be enabled.
OK - that wraps up Day Twenty-Four. Tomorrow we will go over Session Broker Load Balancing. Until next time ...
- CC Hameed
PingBack from http://www.ditii.com/2008/02/25/windows-server-2008-session-broker-load-balancing/
Hi, what's the typical size of this database depending on number of user, sessions, terminal servers.
I stopped the Session broker service, then moved the tssesdir folder to a mapped drive z:. Then I used the LINKD.exe tool to graft the %systemroot%\system32\tssesdir folder to z:\tssesdir. The command completes but the session broker service no longer starts. Any advice?
I got two terminal servers TS1 and TS2 and another Session Broker & Gateway Server TGW, all the servers are Windows 2008 64 bit servers with latest patches and updates. Internally every thing works fine but if any one trying to access external through internet after entering Logon crendentials it stucks at Welcome screen and returns can't be connected contact network administrator. I am sure nothing to do with firewall or the router because its not blocking any thing.
I checked Session Broker log it contacts the Terminal servers, ends some thing like "INFO: DeleteAllFakeServerSessions (ServID=8) deleted 0 stale fake session records". Did any one come across these issues.
Any help is appreciated.
I have the same problem :
"after entering Logon crendentials it stucks at Welcome screen and returns can't be connected contact network administrator"
Do you have a response ?
Yep - same issue here but it seems to happen after about half load on the servers. Really came into play (moreso) this week after we installed a 2008 R2 Terminal Server. (Total of 3 servers - 1 being R2 but was 2008.)
The 2 main servers are HP BL460's with Server 2008 x64 Enterprise.
How do i read the database tsesdir.edb 's information.