Windows Terminal Services, Session Directory and ZXTM

Terminal Services Summary.

Microsoft Terminal Services are widely used by many organisations to enable users to access their desktop from any location, inside or outside the organisation. This critical application therefore needs to be managed in terms of resiliency and scaling.

Session Directory is Microsoft’s tool to add resiliency and scalability. This application is a database of user’s and their connections to the Terminal Server cluster. When a client approaches a member Terminal Server (TS), the TS communicates the fact to the Session Directory, if the client has an existing session on another TS then the session is redirected here. Otherwise the session connects to the TS and the user’s details are updated on the Session Directory.

This model is ok but does not scale very well, there is also no health monitoring to ensure availability of servers. Managing the TS in terms of load balancing is also not available.

The ZXTM Proposal.

ZXTM is the answer to these (and other) questions. The ZXTM can be configured to front the TS cluster, enabling all users to address the same point, simplifying the client management.

ZXTM will health monitor the TSs and load balance users across the available servers, in a predictable and configurable manner. This simplifies the management and allows servers to be added to the cluster with no changes being needed else where (eg DNS or client configs).

Configuring the Solution.

A Virtual Server is configured on the ZXTM in the usual way, listening on the port that the Terminal Servers are using for their RDP communications (typically this will be the default of TCP port 3389). A Pool is then created and associated with this Virtual Server, this Pool is populated with all the available TSs.

The TSs now need to be configured to use the Routing Token method of redirecting users to the correct TS within the cluster. This Routing Token is sent to the client when the TS needs to redirect the user because of the existence of an active session on another TS, this information comes via the Session Directory.

When the client then approaches the ZXTM with a Routing Token present, we need some TrafficScript to recognise and interpret this. We will use the persistence method “Named Node session persistence” on this Pool, then use the TrafficScript below to select the correct node based on the token:

# Retrieve RDP connection information

$body = request.get( request.getlength() );
$ip = request.getRemoteIP();

# Extract the token from the message

string.regexmatch( $body, "msts=(.*)\n" );
$token = string.trim( $1 );

# Calculate the IP byte values from the token

$x = lang.toInt( $token );
if( $x < 0 ) {
   # The first octet is between 128 and 255 inclusive.
   # ZXTM doesn't do unsigned ints, so we have to fake it.
   $a = 128;
   $x = $x + 1073741824;
   $x = $x + 1073741824; 
} else {
   # The first octet is between 0 and 127 inclusive.
   $a = 0;
}
$d = $x % 256; $x = $x / 256;
$c = $x % 256; $x = $x / 256;
$b = $x % 256;
$a = $a + ( $x / 256 );

# Build the Node name we will select

$node =( $d . "." . $c . "." . $b . "." . $a );
$node = ( $node . ":3389" );

# Select the correct node

connection.setPersistenceNode( $node );

Summary

At this point we now have a working solution. Clients approach the front-end of the ZXTM, if there is no token present in the packet they are load balanced across the available TSs. The TS communicates with the Session Directory and discovers the details of any existing session. If there is a session, the client is redirected by having a Routing Token set and the connection closed.

The client now approaches the ZXTM for the second time, as this time there is a token available, the above TrafficScript determines to which node the client should be sent. The client can now continue with this existing session.

Nick Bond [Zeus Systems Engineering] 03 July 2006