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:
- edb.chk
- edb.log
- edbtmp.log
- res1.log
- res2.log
- sddbtime.chk
- tmp.edb
- tssesdir.edb
Within the tssesdir.edb , the following fields exist:
| Session Broker DB Field | Description |
| source-server-ID | Name of the server that the session resides on |
| session-ID | Session ID - which is determined by the server on which the session originated |
| Username | Username of the user logged into the session |
| Domain | Domain to which the user belongs |
| TS-protocol | Protocol used to connect the session (RDP, ICA etc) |
| session-creation-date-and-time | Time and date the session was first created |
| disconnection-date-and-time | Time and date that the session was disconnected |
| application-type | A protocol-dependent identifier that differentiates between a desktop session or a single-app session |
| resolution-width | Resolution width - this could be set either at the server or client level |
| resolution-height | Resolution height - this could be set either at the server or client level |
| color-depth | Color depth of the session - this could be set either at the server or client level |
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 ...
| Share this post : |
|
|
|
|
|
EDIT (6/13): Removed the section on LINKD and updated the information with how to move the database to a different location using the Registry