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:
- Redirect users to their disconnected sessions
- Evenly balance the load among servers in the farm
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
| Share this post : |  |  |  |  |  |  |  |  |