Notice: This article was written based on the Beta 3 release of Windows Server 2008. Features and facts about the Session Broker Load Balancing therefore could be subject to change as Windows Server 2008 moves towards RTM. You should be aware of this!

Session Directory versus Session Broker

The Load Balancing capabilities of Windows Server 2008 are tightly integrated with the Session Broker. The Session Broker was previously called the Session Directory. If you're thinking "isn't the Session Directory the feature that allowed for session reconnection?", then you're dead-on. Session Directory was introduced in Windows Server 2003 and it allows you to do Terminal Server session reconnection. This has not become a hugely popular feature though. This is for one main reason: Session Directory requires the Enterprise Edition of Windows Server 2003. For the record: this is not the case in Windows Server 2008. Session reconnection, as well as Load Balancing can be done with the Standard Edition of Windows Server 2008. They got it right this time, way to go Microsoft!

Setting Up Session Broker Load Balancing

Like I said earlier, the Load Balancing capabilities of Windows Server 2008 are built into the Session Broker feature of Windows Server 2008. There are four steps you have to take to create your own Load Balanced Terminal Server farm. Notice I used the word "farm" on purpose. Windows Server 2008 uses "farms" as a logical "grouping unit". Not as advanced as the concept of a Citrix farm but it's a decent start.

The four steps are:

1. Install the TS Session Broker role service on a Server
2. Populate the Session Directory Computers local group
3. Join the Terminal Servers to the Session Broker and make them participate in the Load Balancing (you could just do session reconnection and no Load Balancing)
4. Add DNS entries for all Terminal Servers in the same farm.

Step 1: Installing the Load Balancer Role on a Server

The first thing you need to do is to install the Session Broker "Role Service". The term in "Role Service" is part of the new Server Manager in Windows Server 2008. Basically you have "Features" and "Roles". A role for a server is "Terminal Server". The Session Broker is a part of this role, a "Role service". This looks like this (after you've installed the Session Broker):

 You could add the role using the brand spanking new Server Manager, but you could also be fast about it and use the command line version of Server Manager (coincidently called ServerManagerCmd.exe) To install the Session Broker on a server just open elevated command prompt (yup, UAC is all over Windows Server 2008 as well - get used to it) and run this command: SERVERMANAGERCMD.EXE -INSTALL TS-SESSION-BROKER

Step 2: Populate the Session Directory Computers Group

After you installed the Session Broker on your server, you will find that there is a new local group on your server called "Session Directory Computers". Note that this not a typo by Microsoft. Due to security reasons this name will not change in the RTM Release of Windows Server 2008. It will stay "Session Directory Computers". If you installed the Session Broker role service onto a Domain Controller, this group will be a domain local group.

You need to add all the Terminal Servers that need to join the Session Broker in here. This can be quite a hassle to do by hand. Consider installing Terminal Services through a script and add the computer account to the Session Directory Computers group after the installation has finished. Alternatively, you could use the Restricted Groups feature in Group Policy. If you think you've gone nuts when you're looking for the Group Policy Snap-in or the Group Policy Management on a Domain Controller, relax. You're not alone... for some reason Microsoft installs Active Directory without any Group Policy management tools. You'll need to install them. Just run SERVERMANAGERCMD.EXE -INSTALL GPMC

The point is that the Terminal Server computer account needs to be in the Session Directory Computers group or it's a no-show.

Step3: Configure Terminal Servers To Join Session Broker

This is the most important step. This is where you actually tell the Terminal Servers to join the Session Broker and participate in Session Broker Load Balancing (joining the Session Directory Computers group in the previous step only allowed you to be able to join the Session Broker). You could do this on a per server level using the Terminal Services configuration tool TSCONFIG.MSC (it was renamed from TSCC.MSC in Windows Server 2003).

Notice the "relative weight of this server in the farm" option. Using this feature you can "influence" the session count the Session Broker monitors of this Terminal Server. A scenario when this comes in handy is when you have different hardware types in you farm. You would give the old servers a lower weight or the new servers a higher weight. The higher the weight, the (relatively) more session a server gets. You cannot set the weight by using Group Policy (which makes sense of course). For all the other settings Group Policy is the preferred method. There's five new Group Policy entries just for the Session Broker:

Join TS Session Broker You need to enable this policy setting. This policy setting specifies whether the Terminal Server should join a farm in TS Session Broker. If this policy setting is enabled, the terminal server joins the farm that is specified in the "TS Session Broker Farm Name" policy setting on the TS Session Broker server that is specified in the "TS Session Broker Name" policy setting. If you disable this policy setting , you cannot join the Terminal Server to the TS Session Broker using other tools (like TSCONFIG.msc).

TS Session Broker Farm Name
In this setting you need to specify the farm name you are using. This is not something you've entered before. You need to think of your farm name right here. This does not have to be an existing DNS name or AD object. This name is used to create a new farm in the Session Broker (that you will specify in another Group Policy). So if could very well be that you could have 5 "farms" within one Session Broker. It's considered a best practise however to use the same name to configure the farm name as you would do in DNS (see step 4).

Use IP address Redirection
Set this policy to "yes" if you want to be able to connect to disconnected sessions. This policy allow for session reconnection by using the IP address of the Terminal Server. You should only disable this policy setting if your network load-balancing solution supports the use of TS Session Broker routing tokens. This is because when you disable this policy the IP address of the terminal server is not sent to the client but the IP address is embedded in a token instead. In 95% of all cases you should set this policy to "yes", seeing as only a few hardware load balancer vendors support this feature (Cisco, F5, and Radware).

TS Session Broker Name
Here's where you specify the computer name of the Server running the Session Broker. Be sure and use the FQDN of the server. This is the name of the server on which you installed the Session Broker role in step 1.

TS Session Broker Load Balancing
A taste for the dramatic. Save the best for last. This setting configures whether or not the Terminal Servers this Group Policy applies to should participate in Load Balancing. Enabling this setting does not interfere with users connecting to their disconnected sessions.

Terminal Server Maintenance: "Draining"
Also debuting in Windows Server 2008 is the possibility to "drain" a Terminal Server. This way you can put a server into maintenance mode, by disabling new logons to it but allowing reconnection to existing disconnected sessions.

Step 4: Add DNS Entries For All Terminal Servers

This is the most important part of the Load Balancing feature of Windows Server 2008. You need to add a separate DNS entry for every Terminal Server that should be load balanced. The name of this DNS entry doesn't really matter as long as it's the same for all Terminal Servers. Remember though, it's considered a best practise however to use the same name as the farm name as in DNS. If you do assign different DNS entries you are essentially making separate groups of servers: silos. Refer to the following screenshot:

As you can see I've come up with the brilliant name "ts-farm" for my Terminal Server farm. You can also see that I have two Terminal Servers in my farm, similarly brilliantly named TS1 and TS2. The ts-farm is the actual DNS name your client will be connecting to. So setting up a connection to your Terminal Server farm would look like this:

How does the Session Broker Load Balancing Work?

The Session Broker Load Balancing in Windows Server 2008 is usually just refered to as Session Based Load Balancing, which is true. The load balancing is done based on the number of sessions. But there's actually a lot more than meets the eye in regards to the Session Broker Load Balancing than just counting the user sessions. The Session Broker Load Balancing also has built-in black hole protection (logon throttling) and a max-session count.

The black hole protection is pretty advanced (if you don't know what the Black Hole effect is, read this article by Jeroen van de Kamp and Daniel Nikolic). It has two ways of protecting a server against the Black Hole effect. One is by artificially making the load on a server higher during a logon to prevent a Teminal Server being overrun by new logins. The load will return back to normal when the logon processs is finished. Another way the black hole effect is circumvented is by the Session Broker itself. It can have a limit in outstanding connections to the same Terminal Server. So for example no more than eight concurrent user logons per server. Simple but effective.

The max-session count means that every server in the farm has determined a maximum amount of sessions that it can host. This prevents a degraded user experience for the users already connected to a Terminal Server should some Terminal Servers in the farm not be available. This is at the expense of new users not being able to set up a session at all of course. The max-session limit however is something you'll need to configure yourself: it's not automagicly calculated by Terminal Server. Actually, it's disabled by default and not configurable via the GUI. If you want to enable it, you need to set the UserSessionLimit key in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server to the maximum amount of sessions you want to allow on that server.

So how does the whole process work? Well, the easiest way to describe how the Session Broker Load Balancing works is by examining the steps that it takes to set up a successful connection. These are:

1. A Client connects to TS-farm.lh.lan. It gets returned the first IP address for this DNS entry (192.168.1.52) in our case.
2. If that server should be offline for some reason, the client tries to contact the second server. This continues until the client receives a proper response from the Terminal Server.
3. If the Terminal Server is joined to a Session Directory and has Load Balancing enabled, the Terminal Server queries the Session Directory.
4. It first checks to see if the user has any disconnected sessions. If the user has a disconnected session, the user is directed to the Terminal Server that hosts the disconnected session.
5. If not, it gets returned the least busy server based on the session count (connected and disconnected) of the farm. This takes into account the "weight" the specific Terminal Servers have and whether or not the server is being drained (i.e. is in maintenance mode)
6. The client gets redirected to this least busy server and establishes a connection. The steps above are represented in this animation (courtesy of Microsoft)

This way of connecting has some obvious issues. One of these is the "DNS-approach". If you do not have DNS Round Robin enabled, every connecting client will try the first Terminal Server first. This can put some severe strain on that first Terminal Server at peak login times. Make sure that Round Robin is enabled on the TS-farm.lh.lan records (DNS Round Robin is enabled by default on Windows Server 2003 and Windows Server 2008). If you feel that DNS Round Robin isn't really an enterprise-grade solution you could a "Dedicated Redirector". A Dedicated Redirector is a dedicated Terminal Server that does not host any applications but just queries the Session Directory on behalf of the clients. You could take that a step further and Load Balance two Dedicated Redirectors using a hardware load balancer or even NLB. Note that this needs some more configuration than meets the eye: you need to have clients connect to a DNS Alias instead of the host names of the Dedicated Redirectors or else you will run into server authentication issues.

Another question that comes to mind is: what happens when the Session Broker is down? Well when the Session Broker is down all Session Broker functionality is lost and all you have left is DNS Round Robin "Load Balancing". So if you want redundancy you'll have to cluster the Session Broker. Back in Windows Server 2003 this could be done by utilizing Windows Clustering. You can use the same techniques to cluster the Session Broker in Windows Server 2008.

What does it do?

What does it do? Well, the short version is like this: it does everything you would want it to do... basically. With Windows Server 2008 Session Broker Load Balancing you can do:

Session Reconnection
As said, the feature itself isn't new to Windows Server 2008 but it does get a second change by being included from the Standard Edition of Windows Server 2008 and up. In conjunction with the Load Balancing feature this makes for a real addition. After all, what is Load Balancing worth without Session Reconnection?

Session Based Load Balancing
This is of course is the real deal. The most important part is that the Load Balancing also works for Remote Programs! (Remote Programs are the Windows Server 2008 equivalent of Citrix' Published Applications- more on this in another article).

Terminal Server Draining
Terminal Server Draining is a great new feature that you can't really do in the current Citrix Presentation Server products (except for using assigning special Load Evaluators). I think Microsoft has paid attention to their customers and saw that there was a definite business need for a maintenance mode of some sort.

Session Sharing
Session Sharing is a very important part of any Load Balanced environment. It makes sure that as little separate Terminal Server sessions as possible are used. This has a lot of benefits. For example, it's faster because you don't have to go through the whole login process again and you're less likely to have profile issues.

Session Sharing does work in Windows Server 2008, but it does in a whole different way than you would probably expect. You might think that if you launch a second Remote Program, Windows first checks whether or not that Remote Program isn't available on the Terminal Server you are already connected to. Turns out it doesn't work that way. It's a little less elegant. The Session Broker is not aware of what Remote Program you are starting, it just directs you to the Terminal Server you already were connected to (actually it first checks to see if you have any disconnected sessions). Exceptions to this behavior apply when the legacy "initial application" setting is used (the Windows Server 2003 wannabee way to do "Remote Programs") or if the single-session-per-user policy is turned off. When such an exception occurs, the Session Broker just tries to launch another session to that same server unless the Terminal Server is in drain mode or has reached its maximal session count.

So in Windows Server 2008 Terminal Server, Microsoft basically assumes you have a single-silo environment (which means that all the same applications are installed onto all Terminal Servers). If have to create silos in your Terminal Server farms to cope with for example conflicting applications, Session Sharing won't work for you all the time.

What doesn't it do?

Al though the Windows Server 2008 Session Broker Load Balancing has a lot of cool features, it doesn't have them all.

Management Tools
The lack of proper Management tools is not of the weaker areas of Windows Server 2008 Terminal Server. Especially in that there are no centralized management tools. For example, there is no way to query the Session Broker to see what user load the different Terminal Servers have. The one thing that is kind of like "farm based" management, is the option in the Terminal Services Admin tool (tsadmin.msc) to import from a Session Broker. When you import from the Session Broker it displays all the Terminal Server joined to the Session Broker, sorted by farm.

Session Broker High Availability Options
Another thing that I missed was some kind of built-in option to make it easy to make the Session Broker high available. The DNS component of the Load Balancing mechanism in all its simplicity has enough (simple) redundancy options. The Session Broker however relies on Windows Clustering which is quite a hassle to set up.

Resource Based Load Balancing
As said before, Session Broker Load Balancing does Session Based Load Balancing, not resource based Load Balancing. This means that Session Broker Load Balancing in Windows Server 2008 works by taking a look at just the user load on a Terminal Server, including disconnected session (remember that it also has black hole protection (logon throttling) and a max-session count). If you want to take CPU usage, Memory usage, Disk usage and stuff like that into account, you're out of luck. I do not think that this is a big deal because in my opinion such resource based Load Balancing usually yields unpredictable loads. Resource based Load Balancing can be important though in environments where you have different types of hardware in your Terminal Server farms. In Windows Server 2008 you deal with this with the "weight" option in the Terminal Services configuration tool.

Oh, one thing to know is that you need a domain to use the Session Broker but I don't think that will be a huge issue in most environments...

Do I still need Citrix?

Here's the million dollar question. Again...(being in this business feels like watching a rerun of Jeopardy!). Do I still need Citrix? Well, you can basically tell from the "What doesn't it do" part of this article whether or not if you still need Citrix. It all depends on your environment. I think that the most important reason people buy Citrix Presentation Server Advanced Edition (or even the Enterprise Edition) is because of Citrix' Load Balancing capabilities (which are the best out there as far as I'm concerned) However, fact of the matter is that now Load Balancing is included in Windows Server 2008, less people are likely to buy Citrix just for Load Balancing. Make that a lot less people.

If you look at the other features that Citrix has over plain Windows Server 2008 Terminal Server, well then it all depends whether or not you actually use the features. Think about features like Resource Manager, Installation Manager, Application Isolation Environments, Application Streaming, Virtual IP, SpeedScreen, Session Reliability, Health Assistant, Configuration Logging, just to name a few. Do you use these features? And if you do, consider whether or not it is worth the added costs that Citrix introduces.

Conclusion

Session Broker Load Balancing is in my opinion a viable option to consider when doing a Windows Server 2008 Server Based Computing deployment. Even in Beta 3 the Session Broker with Load Balancing makes a good impression. It's easy to set up, provides decent backwards compatibility (important when using Thin Clients for example) and has a simple yet effective architecture. It's also very important that the Load Balancing works for Remote Programs. Furthermore, this initial version of Session Broker Load Balancing looks really mature with features like the black hole protection, max-session and the drain mode.

It looks like Microsoft just wanted to implement the most important features of Load Balancing in Terminal Server environments and just focus on making that a success. Well they did just that. This coincides nicely with the statement Microsoft has been making about Windows Server 2008 Terminal Server primarily being an easy point-and-click out-of-box solution for low to medium complexity environments and that one would need third-party software in high(er) complexity environments. I guess it then all depends on what percentage of all Windows based Server Based Computing environments turn out to be complex ...