Thoughts from the EPS Windows Server Performance Team
Useful Microsoft Blogs
Good Morning AskPerf! Welcome to Day Fifteen of our Launch Series. There is only one more week to go! If you remember Windows Server 2003 R2 then you probably also remember that Terminal Services (as it was called then) didn’t change much from Windows Server 2003. The same cannot be said for Remote Desktop Services in Windows Server 2008 R2 when compared to Windows Server 2008. Today’s post is a brief one where we’ll be taking a look at an overview of Remote Desktop Connection Broker - not only at what is new, but how it is different from its predecessors. In part 2, we will dive in to the specifics of how to configure and put Connection Broker to work for you in your business.
First, let’s look at a little history of Windows Terminal Services. Since Windows Server 2003, we have had the ability within Terminal Services to be deployed as a farm where multiple servers were pooled together as a single resource. This provided the ability to scale out and increase the number of users that could access applications over Terminal Services by distributing them amongst several servers instead connecting hundreds of users to a single server. If you added in Microsoft Network Load balancing then you could also balance the load across servers in the farm. This deployment presented some problems though, for example when user sessions were disconnected. How did we make sure the user is returned to their previous session when they do not know which server they were connected to in the first place? The solution was Session Directory, and in Windows Server 2003 this was implemented in the Terminal Server Session Directory service. It was called Session Directory because that is basically what it was, a directory (or database) of sessions for each user in the farm. The only job Session Directory had in Windows Server 2003 was to redirect a user to a disconnected session. Load balancing was accomplished with Network Load Balancing or a hardware device like BIG-IP.
In Windows Server 2008, Session Directory was extended to include load balancing support that was previously only available with hardware devices from companies like Cisco and f5, or software like Microsoft Windows Network Load Balancing. The feature was renamed to Session Broker and has two main functions:
Session Broker was able to add basic load balancing functionality by leveraging the already existing database of sessions in the farm and using that to make a basic load balancing decision. The topology for Session Directory / Session Broker on Window Server 2003 and Windows Server 2008 looks like this:
The best things about RD Connection Broker in Windows Server 2008 R2 are not what was changed, but rather what was added. RD Connection Broker still supports the same disconnected session redirection and load balancing features of its predecessors, while adding support for pooling RemoteApps from multiple servers and brokering connections to virtual desktops that can be either personalized for each user or assigned to users from a pool of available virtualized desktops. This is main reason for the name change, as this service now brokers more than just sessions, it brokers connections to applications and desktops that are deployed via Remote Desktop Services and Hyper-V.
The real power of RD Connection Broker is when it is used with Hyper-V and the Remote Desktop Virtualization Host to deploy entire desktops to users, where that desktop is no longer a session on a Terminal Server but a virtual machine. Working with the RD Virtualization Host, RD Connection Broker now also manages all of these connections and allows for redirection to a standard Remote Desktop session, a RemoteApp session, a personalized virtual desktop, or a connection to a virtual machine pool. We’re not going to go into too much detail about Remote Desktop Services Virtualization in this post – you’ll have to wait until the day after tomorrow for that! However, in a nutshell, RD Virtualization Host uses Remote Desktop Connection Broker to determine where the user is redirected.
That’s it for today – a brief post as I mentioned, but the information here relates to the next couple of posts. I’ll be back tomorrow with Part Two of this post. Take care!
- Don Geddes
I have a multiple physical host 2008 R2 Hyper-virtualized TS farm with several session brokers (virtualized as well) and a connection broker (VM) as well. What is happening is that around noon the Session Brokers suddenly lose their connection to the Connection Broker and then a minute later reconnect. However in the process of disconnecting and reconnecting, the Connection Broker now no longer has the appropriate connection information for the clients that were logged on to the TS. The clients are still connected via the TS to the Session Broker but because the Session Broker lost connection to the Connection Broker it seems that those users who disconnected and would ordinarily get their session back - we have a 2 hour time out - are no longer being redirected to their existing session. This only happens at noon which coincides with the time that people go for lunch and disconnect their sessions en masse - at other times of day when there is a more intermittent disconnection situation- a person here and there disconnects from their session but there is no 'mass disconnection' there is no issue - the users when the reconnect go back to the session they left. I would appreciate any thoughts as to what might be the cause of this/how we might isolate the problem? Is there some kind of maximum disconnection issues with Connection Broker? Your attention to this is appreciated in advance.
There's no known issue with Session broker disconnects - clients do not maintain a persistent connection to the Broker any way - it's merely a repository for the session information.
What makes you think the clients are being 'disconnected' from the broker?
If the client sessions are being disconnected, its almost always a networking issue - check for out of date network card drivers, the latest VM additions, recent changes to networking hardware (switches, routers, load balancers, cables etc). A network trace from both the Session host the client is trying to connect to and the client will usually reveal something.
Not reconnecting to existing sessions is an entirely different beast. It sounds like either the sessions are being reset after the users disconnect or the session broker is not working at all - scrutinize the configuration.
As for fixes - Microsoft maintains a list of the most current fixes for Remote Desktop Servers here:
Available Updates for Remote Desktop Services (Terminal Services) on Windows Server 2008 R2 SP1