Remote Desktop Server farms explained (Part 2)

If you would like to be notified of when Freek Berson releases the next part in this article series please sign up to our VirtualizationAdmin.com Real Time Article Update newsletter.

If you would like to read the first part in this article series please go to Remote Desktop Server farms explained (Part 1).

Introduction

This article continues where we left off in Part 1. In Part 1, we walked through the different types of load balancing solutions which can be used in order to distribute users over multiple servers in a Remote Desktop Services farm. We mentioned that there are four types of load balancing solutions. There is RR DNS, software (e.g. NLB), hardware and the RD Connection Broker. On multiple occasions in the article, we mentioned that the first three types could also be combined with the RD Connection Broker. In this second part, we will see why and how the RD Connection Broker serves a central role.

Purpose of the RD Connection Broker

The RD Connection Broker in Windows Server 2008 R2 serves different purposes and can be used for Virtual Desktop Infrastructure (VDI) as well as Session Virtualization (RDS). As this article is all about RDS farms, we will of course be focusing on Session Virtualization.

The RD Connection Broker for RDS serves the following main purposes:

• Determining the best RD Session Host server to connect to – this is based on the amount of current sessions per RD Session Host Server as a form of load balancing.
• Reconnecting a user to an existing session, in case there is one – this is called reconnecting to disconnected sessions.
• Being a resource for RD Web Access to deliver information about what Remote Apps are available on RD Session Host Servers that are a member of the broker.

Initial connection

As we mentioned in the part 1 of this article series, the RD Connection Broker can do a form of load balancing, but there has to be a connection to one of the RD Session Host servers first. We call this the initial connection. In the next paragraph, we will see how this process works, but it is important to understand that when using the RD Connection Broker you still need a load balancing mechanism to provide that initial connection. The previous article explained the options for this initial connection.

The RD Connection Broker Process

Let us think of the following scenario. We have three RD Session Host servers running Windows Server 2008 R2 and we have an initial load balancing mechanism in place. In addition, let us, for the easiness of the scenario, assume that we chose RR DNS. We have set up a separate server running the RD Connection Broker and we want to make use of the RD Connection Broker role to its full extend. We have added all three RD Session Host servers to the Session Broker Computers group on the RD Connection Broker. We have enabled the load balancing feature (we’ll see later on why) and we have created a GPO to restrict users to one session.

1. A user launches an RDP session with a DNS RR entry specified as the destination host.
2. The DNS RR mechanism will return an IP address of one of the three RD Session Hosts (note, that there is neither load balancing here nor checking whether the returned IP address is even reachable).
3. For the easiness of the scenario, let us assume that the IP address returned by the DNS RR mechanism is valid and reachable. The user will authenticate to the RD Session Host server. We now have an initial connection. Do notice however that this is not just yet a full connection, meaning it is not an actual session (yet) in which the user can interact. We call the server that accepted this initial connection the redirector.
4. The RD Session Host server will, as it knows it’s part of an Broker farm, pass the RDP information to the RD Connection Broker
5. At first, the RD Connection Broker will determine if the user account that made the connection has a disconnected session on one of the three RD Session Host Servers. The RD Connection Broker will do so based on the information inside an internal database owned by the RD Connection Broker role. If there is a disconnected session, the RD Connection Broker will return the IP-address of the RD Session Host Server containing the users session.
6. If there is no disconnected session, the RD Connection Broker will choose a destination server, and this will be the server that holds the fewest sessions. (This is the RD Connection Broker load balancing feature).
7. The RD Connection Broker will return the IP address of the destination RD Session Host Server (based on the processes in step 6 and 7) to the RD Session Host that made the request (the redirector).
8. The redirector in turn will send this IP address to the client back to the client.
9. The client will silently disconnect from the RD Session Host (the redirector) and will reconnect to the RD Session Host server using that IP address. Assuming of course that reconnection is needed, also see the following clarification.

To clarify this a little more:

Your session will only be redirected to a different RD Session Host when one the following conditions are true:

1. You have an existing session on a RD Session Host server that is not the RD Session Host server your initial load balancing mechanism sends you to.
2. You do not have an existing session on a RD Session Host server, you have RD Connection Broker load balancing enabled and the RD Session Host Server that you initially connect to is not the RD Session Host server with the least load (as decided by the RD Connection Broker).

In addition, if you do not have an existing session on a RD Session Host server and you have RD Connection Broker load balancing disabled your session will not be redirected.

As explained in Part 1, the server hosting the initial connection can also be dedicated to just this task. If you install a RD Session Host server in the Dedicated Redirector mode, you can use that RD Session Host server to serve as the initial connection. A RD Session Host server running in Dedicated Redirector mode will not actively host any sessions but will consult the RD Connection Broker to be able to return an IP address of a RD Session Host. As we mentioned in Part I this server is actually a server running in Drain mode (a maintenance mode). Which explains why a server in Drain Mode does not accept any new connections, it simply consults the RD Connection Broker and returns an IP address of a RD Session Host Server that is active and able to serve new sessions.

In case you are interested, there is a way how to read the data inside the RD Connection Broker database. Follow this link for more information.

Conclusion

As you can see the RD Connection Broker plays a central role in Remote Desktop Services and it is used to reconnect disconnected sessions and it can optionally perform load balancing. The RD Connection Broker plays a crucial role in having a successful Remote Desktop Services environment.

If you would like to be notified of when Freek Berson releases the next part in this article series please sign up to our VirtualizationAdmin.com Real Time Article Update newsletter.

If you would like to read the first part in this article series please go to Remote Desktop Server farms explained (Part 1).