Kemp Technologies updates hardware. Load Balancers for RDP with or without Session Directory!

Kemp Technologies announced today that the newest software update for their entire line of load balancing appliances will make them all "RDP-aware," meaning that they can intelligently load balance between Terminal Servers and/or integrate with Session Directory.Kemp has been in the hardware load-balancing business for about five years.

Kemp Technologies announced today that the newest software update for their entire line of load balancing appliances will make them all "RDP-aware," meaning that they can intelligently load balance between Terminal Servers and/or integrate with Session Directory.

 Kemp has been in the hardware load-balancing business for about five years. I first wrote about them in 2005 in an article about load balancing Citrix Web Interface servers. We've been a customer of Kemp for probably three years now, having bought a pair of LM1500's for $2500 each to sit in front of the web servers that host

I talked to Tony Bourke, independent consultant and owner of, about the hardware load-balancing market. Tony said the industry is really splitting into two camps: the "premium" load balancers like those from Citrix (NetScaler), F5, Cisco, and others which often cost $100k+ once you get the redundancy and options you need, and the "value" market, including Kemp, Barracuda, and Coyote Point, where a full high-availability pair starts at around $5k.

The traditional sweet spot for the "value" load balancers

Kemp has always been able to generically support any TPC or UDP port / protocol combination. If you wanted to do connection load balancing based on more than a simple number of current network connections, you had to write a script that calculates the load of each host that's accessible via HTTP by the load balancers. (In other words, a script runs on each host and generates a number from 1 to 100, and then the load balancers check http://host1/myscript, http://host2/myscript, etc. to determine which server should receive new load.) It wasn't the most ideal situation, but it sure was flexible since you could use any perfmon counter, WMI interface, EXE, or anything else you could dream up to generate those numbers. (For we had a script that ran several checks or web sites and sample database queries. If everything came back as expected, it generated a load number. If any aspect failed, the script generated a value of "100" which told the Kemp that server was "full," thus preventing new connections to the broken server.)

Kemp's products have traditionally found their sweet spot in front of web servers, and really the only place they've had in Citrix environments has been to load balance Web Interface servers since Citrix's own load balancing features are more integrated into the product. Load balancing pure Terminal Servers, however, has never been too great out of the box. The only free solution in the past was to use Windows Network Load Balancing. (Ron and I wrote an article about this in 2004.)

In the past, you could also use a "generic" hardware load balancer from to load balance your Terminal Servers. You could configure them to listen to port 3389 and you could even install IIS on your servers to create some cool load balancing algorithms. This worked well except for one thing: If a user with an existing disconnected session reconnects, there is no way for the load balancers to know about that existing disconnected session, so the user is routed to the least-busy server. Maybe the user is lucky and that server happens to be the one with their disconnected session (meaning they'll be automatically reconnected). But chances are they'll be sent to a different server, thus starting a new session even though they already have an existing session.

Integration with Windows Server 2003 Session Directory

With the release of Windows Server 2003, Microsoft introduced the "Session Directory"--a simple Access database running on one of the Terminal Servers--that maintains a list of all active and disconnected sessions on all servers. The session directory can then interact with hardware load balancers via a "routing token." Essentially this means that the hardware load balancers know about the session directory, so once a new incoming user authenticates to a Terminal Server (but before the session is started), the load balancer can then check to see if that user has an existing session on another server. If so, the session is switched over to the other server.

Session directory worked well enough, except only the expensive load balancers supported it. With today's announcement from Kemp, they now fully support session directory, even in their entry-level $2500 appliance.

But it gets much cooler than this.

What about Windows Server 2008?

With Windows Server 2008, Microsoft is introducing an out-of-the-box load balancing feature called Terminal Server Session Broker. (Michel Roth wrote a great overview of this last year.) It turns out that the TS session broker in 2008 is almost identical to the session directory in 2003--the prime difference being that 2008's session broker can route incoming connections to the least-busy server in addition to routing users with pre-existing disconnected sessions back to the server running their session.

So with this new feature of 2008, why would someone need the new load-balancing features in Kemp's products? Why not just use 2008's built-in session directory?

It turns out that while the session broker is cool, there are some complexities in its configuration. The most fundamental challenge is that TS session broker runs on one specific server. (And all incoming client connections are pointed to that server so they can be routed to the proper Terminal Server.) While this works well, it's also a single point of failure! And how do you alleviate single points of failure? You build redundancy. So now we're talking about building two session brokers. But now you need a way to fail over between the two (unless you just want to tell your users to try one address first, and then try the other if that doesn't work). So to failover between these two, you need to configure Windows network load balancing (NLB). But what's wrong with NLB? It will still send traffic to a server as long as that server's IP stack is up and the NLB service is running. So even if your session broker service fails horribly, NLB will keep routing users to a down server. So how to you avoid that? You put a smart, Layer 7 application load balancer in front of your session brokers so that incoming user requests are always routed to a functioning session broker server.

Or, you could just skip all that session broker complexity and just use that same Layer 7 application load balancer in place of the session broker. This is where Kemp comes in.

Understanding Kemp's new Terminal Server load balancing capabilities

Remember, one of the new features of Kemp's update to their load balancers is that they support the routing tokens that allow them to communicate with the TS session directory (Windows 2003) or the TS session broker (Windows 2008). So that's cool.

But, in addition to working with the Windows features, a new feature from Kemp allows you to use Kemp's load balancers to completely replace the session broker / session directory. (In other words, the Kemp's become your load balancers and route users to their disconnected sessions without using the session broker or session directory at all.) This works because now Kemp has added RDP to the list of Layer 7 protocols that they fully support. At the bare minimum, this means that the Kemp load balancers can do Terminal Server health checking by testing whether a server can receive RDP connections.

Kemp also has a resource agent running on each Terminal Server. The load balancer contacts these agents (at a configurable interval) so that it knows which server is the most appropriate for new connections. Furthermore, they can track active and disconnected sessions for you, so you don't have to deal with the session directory at all.

Kemp's resource load balancing works the same way it always has, which means the load balancer will contact each server in the load balance group via HTTP (on any port) looking for a value between 0 and 100. What's new for Kemp is that they wrote a little EXE that you can run on your servers that actually generates that value. This EXE reads a text configuration file that tells it what perfmon counters to look for and how they should be weighted for the final calculation. (In other words, you can use any perfmon counter in any way for your load balancing algorithms. (And if you have different servers that you want to weight differently, then just put a different text configuration file on them.) All that little EXE agent does is spit out a 0 to 100 value, so really if you want to use some other method altogether for load-balancing, that's no problem.

The only catch is that the load balancer reads the value of the agent on each individual Terminal Server via HTTP. This means you need to run some kind of web server service on each of your Terminal Servers. If you're using the TS Web Access feature of Server 2008 then this won't be a problem since that needs to have IIS running on each of your Terminal Servers anyway. But if you're not, you'll need to add IIS to each of your servers. Since IIS will only be serving the small static load file to the Kemp's, you won't need any additional capabilities such as ASP or ASP.NET installed, but some people might be nervous about IIS anyway. If you fall in that camp, there are actually several little HTTP daemons you could use instead of IIS, such as lighttpd or cherokee. In fact, these are the same daemons that many of the more expensive monitoring tools bundle into their agents anyway.

To reiterate, all of these software updates are available for all of Kemp's existing load balancers. So even the $2500 one that we bought three years ago can now do everything mentioned here. Of course for redundancy, you'll want more than one hardware load balancer. You can configure two Kemps as a high-availability pair. The first one is active, and the second one is passive and just monitors the first one. If the active load balancer fails, the passive one assumes its IP address and everything continues without interruption. So this means that you can get a fully-redundant, Layer 7 Terminal Server application load balancer that can balance off of any perfmon counter, do TS health checking, and replace the session directory, for $5000.

One last note: Kemp has several models of load balancers, but they all run the same software. The various model numbers have different hardware specs, so each supports various load and use scenarios. Hmm.. I just remembered that the Kemps also offer SSL off-loading for web servers. I wonder if you could use that with RDP as well? I've never tried. I'll look into this and update this article later today.

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

In searching for information about the SSL thing, I just came across this YouTube video from Kemp demoing their TS Load Balancing features:  


I'd be willing to make a large bet that the guy in the video is wearing sandals :-)



Brian, there are some deviation from the reality in the article.

First, 2008 Session Broker doesn't need NLB to stop becoming a single point of failure. It needs clustering - the same way Session Directory. There is no need to go to NLB.

Second, budget hardware load-balancer trying to "read and understand" RDP protocol would fail if Front Authentication is enabled (Vista, XP SP3 clients and 2008 servers) because encryption is enabled early in the session. Their best bet is to use a user-name cookie which is of a limmitted lengths and is not garanteed to be unique for all user names - so you may enjoy intermittent failures for some users.

Often hw load balancers don't keep track of user sessions and if you come to server 1, than logged of and later log on again you will be directed to server 1 even if server 2 is much less buzy because load balancer doesn't really know if you still have a session on server 1 or not (until cash expired), so you essentially getting static user distribution between the servers instead of load-balancing. Would be nice to know what KEMP  really quering TS servers through WTS API or require to install their agent on every TS server? 


I don't agree with your statements.

First, my point was that if you want redundancy in your session broker, you need two session brokers. Honestly I think clustering is even more complex than NLB, since it adds shared storage and everything. So realy my point is that for redundancy you need extra hardware, and that is true whether it's clustering or NLB.

Second, the Kemp load balancers can read enough data in the initial cleartext exchange before the SSL is put in place to load balance and reconnect as needed, so that's not an issue. I don't see how the server authentication of RDP 6 would change that, but it might as I've not tested it with the Kemps.

Finally, you can configure the Kemp user cache timeout to be the same as whatever your disconnected session timeout is on your Terminal Servers. And how long this is is up to you. So if you want your users to always reconnect to a disconnected session, then you can do that no prob. And if you always want users to hit the least-loaded server, then you probably should not allow for disconnected sessions in your environment and you can configure the Kemp accordingly.

As for whether Kemp is querying the TS API, I have these details in the article. You can use their agent to create a load value based on any TS perfmon counter. That shows the load of each server. As for whether a server is online / offline, you can use the TS health checking function, which basically does a test RDP connection to make sure everything is working right. 


Given Presentation Server now includes a small Apache web server (that handles session reliability, STA, XML gateway and SSL relay connections) it should be possible to modify the default httpd.conf file so that your presentation servers can serve this load value without having to install IIS.





I think you would agree that redundant solution ALWAYS require some extra hardware. KEMP box is most likely a BSD 1U form factor PC, so you need to buy an extra KEMP box to elliminate a single point of failure.

But, I would agree with you, configuring MS cluster services is not an easy job. In WS08 they made it easier buy stop requiring to have dual-head SCSI shared drive, but MS still has a long way to go to make it "turn key" setup.

If KEMP is using initial clear text exchange, then they may run into trouble with long user names because from my look at protocol capture it is a cookie and long user names get truncated.


I have a question about KEMP helth checking function if you tried it - does it trigger creation of a temporary session? 

And probably more important - does it trigger TS DoS mechanism? 

I know F5 doesn't. 



We have web server in load balancing . But there are sessions in one server while load balancing is working fine in win 2000.

Inspite of giiven priority to another server session are on one server

Please help me


I'm the founder of  and as a competitor to KEMP Technologies, I was to put it bluntly 'gutted' when they integrated session directory and RDP cookies into their appliance. KEMP is focused on what they do and have a solid product, unlike Barracuda :-). However we are finally catching up and are just releasing our integrated RDP cookie handling and all the useful code is open source so if anyone wants to do it for free check our <a href=""> blog on RDP cookies with HAProxy.</a>