A closer look at Session Broker load balancing in Windows Server 2008

Notice: This article was written based on the Beta 3 release of Windows Server 2008.

(This article has also been published on the author's website - http://www.thincomputing.net)

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:

Step 2: Populate the Directory Computers 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.

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.

Step3: Configure Terminal Servers To Join Session Broker

TS Session Broker Farm Name

Use IP address Redirection

TS Session Broker Name

TS Session Broker Load Balancing

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). 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). 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). 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. 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

continued >>>

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 ( 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.


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 …

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Great article.  Fantastic descriptions and overview.  I do disagree with one aspect of it:  Resource based load balancing.  In my opinion, this is one of the best features Citrix has had over other load balancers (Big IP, Nortel, Session TS LB, etc.) for years.  If configured correctly using the load evaluators, this will be the truest form of LB that your farm of TS servers can support.  Session LB is great for Web Servers (round robin DNS) but not for deploying virtualized Windows 32, 16-bit applications.  This is a mid-tier to enterprise wide farm deployment opinion.  For a true SMB shop, I agree that session based load balancing would be the way to go and you don't need the extra bells and whistles.  Unless, if you really wanted to ante up and pay for Access Essentials.

The main features appealing to Citrix for us will now be in Windows Server 2008.  While Citrix's resource-based load balancing is great, with the amount of users we have, its not worth the $1 million spend just to get it.

Heck, for that, we could hire several FTEs and have their whole job be to babysit Terminal Server weights on the load balancer and we'd still save a ton of cash every year.

Our only challenge will be getting some rather old software to work in Windows Server 2008.

Citrix keeps adding more and more features we don't need - and while I'm sure some companies need them, we don't need 90% of them.  Windows Server 2008 is almost a complete package unto itself. 





I would not confuse session-based LB with round-robin DNS.  Round-robin is "random" load distribution, not even load balancing.

Round robin doesn't work that great for TS work-load, but Session Broker load-balancing IS NOT ROUND-ROBIN DNS!

If you have 70 users on the box using similar set of applications session-based load balancing will be very close to any other "resource-based" load-balancing metric. A lot of Citrix customers runs with session-based load balancing.

Resource-based load balancing has some other advantages like "blackhole" prevention, which is important for example in case of  sudden significant loss of farm capacity (ex - switch failure leading to "loss" of several servers, users from theses servers connect back to the farm and overload all existing servers - all farm is down).

Session Broker load balancing also implements logon throttling and "maximum session" limit per server to coupe with such a disasters, but it is harder to configure (WMI scripting required)


From my experience (and those of others) I tend to see that session based load balancing (indeed not to be confused with Round Robin) at the end of the day yields a better spread of the load. I feel this is especially true in environments where there's an obvious peak in Logons, like offices for example. One reason could be the Load that the logon process itself yields. The biggest culprit would however be a human one I guess. Think about it: ALL people usually do the same things when they are starting their working day: drink coffee, check email, drink more coffee, surf web, drink even more coffee, check the intranet and so on..... It's only after that, that they start to really "use" the system. So one does 80 MB Word Documents and tries to rival E=MC2 using excel combined with surfing 5 websites and searching trough a 500 MB Inbox while his neighbouring session does.... well nothing except for outlook. This means that approximately every user yields the same load during their first hour of work or so. In the office scenario this means that 75% are logged on in that time frame. After that hour or so, the system gets its "real load" by users starting to do their actual work. So now the resource based load balancing will make the right decisions but it's too late now.... the users are already logged on.
What's your experience on this?

Depending on what you call the black hole effect, resourced based load balancing will not help you out. Session Broker load balancing does indeed implement logon throttling (in multiple ways) but as far as I can see this is enabled by default and doesn't need any explicit configuring. The Max session count is indeed something you need to configure in the registry.


For those interested, I'm (slowly but surely) doing a series of posts on my blog regarding load balancing. In one post I specifically discuss session-based load balancing.



Even though Session Based Load Balancing might sound attractive, there is one thing missing in your article and that is that Microsoft's scope for this technology is an environment of two to five identically installed servers.  Also the impact of the complete lack of central management is much much larger than your article seems to suggest. Stop comparing apples and oranges when it comes to Windows 2008 vs Citrix Presentation Server. It just doesnt work that way.



Citrix has been doing everything that MS is trying to do, for more than4 years now.

1. Citrix's Server User Load Rule, which is part of the default Evaluator, is what Microsoft is now calling Session based load balancing.

2. Citrix's IMA Service runs on every server, so the single point of failure that exists with the Session Broker, is not the case with Citrix. Your load balancing will work just fine when a Citrix Presentation Server goes down.

3. Citrix's load balancing based on metrics such as CPU, Memeory usage, Disk I/O etc seem to be far more realistic and advanced than baby sitting Term Services servers with weights.

4. The "drain" feature sounds cool, and certianly something that will benefit both Citrix and Microsoft since its a core Windows Server command.

Citrix seems to be well ahead, and MS is playing a catch-up game. Plus Citrix seems to be making more and more improvements to LB in their forthcoming releases... (http://citrixcommunity.com/blogs/presentation_server/archive/2007/04/12/Load-Balancing-Ideas.aspx)

I think there is a significant misconception here: Microsoft is definitely not playing catch-up with Citrix. If Microsoft really wanted to take over the SBC market they could do it in a heartbeat. They don't want to take it over because they consider it to be a niche market. What Microsoft is doing is raising the bar on the basic, entry-level solution provided by Windows Terminal Services itself. This will ultimately enable lots of organizations that have not used SBC in the past to get into the game.

Also, regarding the specific points you raised:

1. You can have multiple Session Brokers in a single farm, so no single point of failure

2. Citrix may support other metrics, but their default load evaluator is session based. I'm guessing many (most?) installations just stick with the default.

3. The "drain" feature relies on using the Session Broker. I doubt people will use the Session Broker in tandem with Citrix because they will get in each other's way.

There is a reason no one goes to your blog.  All you do is rip on Citrix.  Stop.  Be real and truthful.
First, people do go to my blog, quite a number actually. Second, you and anyone else are free not to go there if it offends you, though to the best of my knowledge I've never made any derogatory statements about anybody, including Citrix. Third, if I've stated anything that is factually incorrect you are welcome to point it our here, there or anywhere. Forth, I work at Ericom Software and we compete with Citrix, I've never made that a secret. Finally, it is my blog so I can write whatever I want in it.

The official statement by Microsoft (as they told me) on target environments is "an easy point-and-click out-of-box solution for low to medium complexity environments". It's no secret that the Kaisers of this world would have difficulties pulling it off with just 2008 Terminal Server ....

I think that the lack of central management tools indeed is severe, but I highly doubt it will be that severe in the two to five server environments you are mentioning. Lets take an example: an average five servers farm with about 250 CCU. I think there's plenty of shops out there how are willing WS08 Terminal Server a go if it saves then....well you do the math. It's about what the business is willing to pay for, no what features we as techies think should be in there.

I think that there are going to be lots of plain 2008 Terminal Server farm beyond five servers farms. It all depends on the complexity, not on the numbers. It's like I said: I guess it all depends on what percentage of all Windows based Server Based Computing environments turn out to be complex …

Dan is absolutely hitting the proverbial nail on the head. You don't seriously think that Microsoft could not have made "Microsoft Presentation Server"? Microsoft, like every company, is out there too make a buck and Citrix sells Citrix licenses as well as TSCALs. It would be a stupid thing for MS to push Citrix out of the market (currently at least...) I totally agree with Dan in that Terminal Server 2008 will just make SBC a more (financially) viable concept with companies.
BTW I find it a bit amusing that:1. I'm told nobody goes to my blog by someone with absolutely no data, while I have the excellent Google Analytics to prove to opposite

2. I'm lectured to be "real and truthful" by someone who doesn't even post under his own name

What a weird thing to say Guest... I read Dan's blog.. It's pretty good actually.
It seems clear to me the MS purposely chooses to release Server 2008 TS with less functionality than Citrix.  I actually think it is great that MS has done this because it forces Citrix to diversify its product offerings and to be highly creative (I am certain that Citrix has been aware of the new features being added to the product for a while and that has to at least be one of the drivers for their product catalogue growing so rapidly).  I do not think it is a real threat to Citrix's dominance in this space because the administrative overhead that this solution requires would make it impossible to manage in a large deployment unless you had some major scripting talent on staff to automate the build / administrative process's/tasks.

Both your responses were weak.  Just because Citrix is a competitor to yours, don't use your blog as an advertisement for your own products.  A blogs purpose, in my opinion, is to be real and truthful.

". . .it is my blog so I can write whatever I want. . ."

You were the kid you took your ball home because you were never picked to play ball on either team.



The "drain" functionality has existed in Citrix for quite some time now.  Simply configure a load balancing rule based on IP and User Load.  Set the IP rule to only allow access from the IP of your admin machine (so you don't lock yourself out), and deny everyone else.  It's something Citrix admins have been doing for years now.  It's nice to see it in the base OS finally. 


I believe the biggest point missed here is that Citrix wrote terminal services for Microsoft and Microsoft is indeed playin catchup.  This is a fact and was a result of the Picasso project.  In this project Citrix again was going to license the OS from Microsoft just like it did with Winframe and write Multiwin in to the kernel just like it did with Winframe.  Microsoft seeing the potentail revenue loss with this had the forsite not to license this to Citrix, however contracted Citrix (and still does) to write the terminal services piece of their OS.

Although the features in 2008 version are very cool and will be an alternative to Citrix for very small deployments this is no way near enterprise deployment scale due to lack of central administration.   For larger deployments you can look at other competing products that basically give you the same functionality / features, but at the end of the day your going to use what you like and makes sense for your businsess or customer



Session Broker Drain feature allows users to connect to their existing sessions (and gracefully close their application) regardless from which physical client they are connecting. Plus, it works automatically for all the users who have existing sessions on this particular server - no need to modify hundreeds of load-balancing rules.

Citrix is a very strong offering. There is no need to "defend" it by oversimplifying what WS08 does.I don't think there is a competition between Honda Civic (or Chevy Cobalt) and BMW 3 -series. Microsoft is targeting different buyers :-)


I have really struggled to find a good FAQ on Active directory and information related to win 2000, win 2003 and win 2008. I have created one and its available at http://activedirectoryfaq.blogspot.com

I am sure its will be a good read for you.

Yes, Citirx did indeed write the code that Microsoft licenses as Terminal Server. However, Microsoft is NOT playing catch up, and is currently making moves that could potentially shut down Citrix. Citrix is an overpriced solution (and I use that term very lightly) that only adds 15% additional functionality to Terminal Services (as told by a Citrix installer). If you look at Windows Server 2008 RC0, there is not only the features described above, but they are getting wholeheartedly into server virtualization via their Veridian hypervisor.

Citix is scrambling for their proverbial butts, thus the recent announcement of them aquiring XenWorks. What is XenWorks? OS virtualization technology. Six years ago, a person could have made a case for Citrix, but NOT today. Either use Windows Server 2008 for application sharing (when it is available), or go full board with OS virtualization via VMWare ESX, or if you can stand to wait, Micorosoft Windows Server 2008.

That's my 2 cents.

It's cool either way...an improvement at least. Let's all be friends...hold hands...

My manager actually brought up a great use for TS that I had long since dismissed 'cause of 10 yrs of pure citrixing...or psing..or xenapping..or whatever citrix decided to call it today.

If you do have a few apps that works well in TS only mode and can accommodate a good group of folks for their jobs. Heck, why not. As long as it works. And money is saved - something any employer can appreciate (and maybe even reward) And, if the improvements improve, I'm all for it. Ironically, for the first time in ten years, my brand new 4.5 farm with 4.6 WebInt is not load balancing correctly right now. A challenge that excites me to find the answer to. Lot of bugs they got in this PresServXenApp thingy....

One more thing...(i never write in these things so on a roll i guess)...I wonder how many hours Citrix has wasted of us hard working admins due to poor management - poor decisions. That's my beef. And it's enough for me to go to another solution if it where feasible. Hate when someone else’s lack of consideration causes pain down the line. i.e.; poor documentation, lack of consistency, lack of knowledgebase articles addressing widely effecting issues - and lack of understanding from what point of view to write these when they do get "around" to it. For ten years been trying to look on the bright side, saying.." I'd rather have a great product with crappy documentation that the other way around!"

Thanks Brian for having this here. Appreciate all you folks that contribute. The nice, considerate, positive ones I appreciate the most though, I must admit.


used to be ctx admin at fortune 40 co. - thousands of users...now take care of smaller 300 user base...less stress! Same Citrix mess ups. But Citrix "be very, very good to me."

If pure 2008 TS works for you then go for it. I would like to add that Ericom provides a free add-on to 2008 TS that addresses some if its limitations. You can read more about it here or register to the joint Microsoft / Ericom TechNet Webcast.

Hi Dan In your first point here you’ve stated that you can have multiple Session Brokers within one single farm, how do you go about implementing them?  Do you implement them in a cluster, or in a load balance, or by using DNS round robin? I cannot find any articles on the web to support this statement, only that you can have multiple TS boxes in a load balance using one Windows 2008 Session Broker. Looking forward to hear from you?


Hi DanYou've said here that you can have multiple Session Brokers in a single farm, how would I go about to implement these multiple SB's?The only documentation I can find on the web is where you have multiple Windows 2008 Terminal Servers in a terminal server farm with only one Session Broker handling the load balance.Any assistance or links to sites explaining how to implement multiple SB’s will help?


Hi, Sorry, but I'm not an expert on TS Session Broker. I based this statement on what I've been told by Microsoft PMs. If you need more information about TS Session Broker then search the msdn or post on the TS support forums. Maybe somebody here will be able to provide more information.


the tinMan


Hi, Does anyone know if SBLB require 2008-based AD or if it works with a 2003-based AD?I get an error that says: "This terminal server cannot participate in TS Session Broker load balancing because the server is configured to use a Microsoft Windows Server 2003-based Session Directory server" but the only server that is 2003-based is the AD server.Do I need to upgrade that aswell to make it work?


Question and Not sure where to post this but  does anymore know if I would get better 2008 TS Performance with several smaller Vitural Terminal Server spread across 3 Hosts, or have 3 physical Beefy Boxes?