A failover cluster is a group of independent computers that work together to increase the availability of applications and services. The clustered servers (called nodes) are connected by physical cables and by software. If one of the cluster nodes fails, another node begins to provide service (a process known as failover). Users experience a minimum of disruptions in service.

This guide describes the steps for configuring Remote Desktop Connection Broker (RD Connection Broker) in a failover cluster, as part of a configuration that provides users with access to personal virtual desktops or virtual machines in a virtual desktop pool through RemoteApp and Desktop Connection. To configure RD Connection Broker in this way, you start with a server that can act as an RD Session Host and RD Connection Broker, configure that server as a one-node failover cluster, then add additional servers (configured in the same way) to the cluster. This can increase the availability of the access you provide to users.

As you work with the configuration in this guide, you can also learn about failover clusters and familiarize yourself with the Failover Cluster Manager snap-in in Windows Server® 2008 R2 Enterprise or Windows Server 2008 R2 Datacenter.

Note

The failover cluster feature is not available in Windows Web Server 2008 R2 or Windows Server 2008 R2 Standard.

For information about the features and functionality in Remote Desktop Services and in failover clustering in Windows Server 2008 R2, see the following topics:

• What's New in Remote Desktop Services (http://go.microsoft.com/fwlink/?LinkId=185916)
• What's New in Failover Clusters in Windows Server 2008 R2 (http://go.microsoft.com/fwlink/?LinkId=147426).

Overview of Remote Desktop Services and virtual machine redirection in the context of a failover cluster

By using the steps in this guide, you can provide users access to personal virtual desktops or virtual machines in a virtual desktop pool, through RemoteApp and Desktop Connection. This is called virtual machine redirection. You can provide virtual machine redirection by configuring a server with specific role services and settings that are available through the Remote Desktop Services server role (as described in Role, role services, and feature requirements for a failover cluster that supports virtual machine redirection, later in this topic). Then, to increase the availability of the services that you are providing, you configure that server as a one-node failover cluster and add more servers (configured with the same role services and settings) to the failover cluster. If one of the servers fails or must be taken offline for maintenance, another server begins to provide service through a process known as failover.

The following illustration shows a failover cluster with a clustered instance of RD Connection Broker. Node 1 and Node 2 are connected by multiple networks. Node 1 has failed, and Node 2 has begun running the clustered instance of RD Connection Broker. Node 2 is also running RD Session Host, although not as part of a cluster. When Node 1 recovers from the failure, it will also be able to run RD Session Host. In other words, even if one node fails, RD Session Host and RD Connection Broker continue to be available.

Figure 1   Failover of clustered RD Connection Broker

Although it is not called out in the previous illustration, the clustered instance of RD Connection Broker stores important state information in registry keys that the Cluster service monitors and replicates between the cluster nodes. (This differs from some other clustered services or applications, which typically store such information in cluster storage.) Because the information is automatically replicated between nodes, when Node 2 begins running the clustered instance of RD Connection Broker, the state information it needs is already stored in the local registry on the node.

The following illustration shows the sequence of events that begins with the user requesting a connection to a virtual desktop, and ends with the virtual desktop being displayed on the client.

Figure 2   Servers providing a virtual desktop

1. The user requests a connection to a virtual desktop, either a personal virtual desktop or one from a virtual desktop pool.
2. The RD Gateway receives the request.
3. The RD Gateway sends the request to a virtual machine redirector (that is, RD Session Host running in virtual machine redirection mode). The virtual machine redirector informs RD Connection Broker, and then waits for the IP address of a virtual machine.
4. RD Connection Broker requests information about a virtual machine from the RD Virtualization Host.
5. RD Connection Broker receives information about a virtual machine and then provides that information to the virtual machine redirector.
6. The virtual machine redirector communicates through the RD Gateway, providing the client with the IP address and connection information for a virtual desktop.
7. The client connects to a virtual desktop.
8. The virtual desktop is displayed on the client.

The following illustration shows the same sequence of events occurring despite the failure of one node of the cluster. Because a second cluster node is still running, it can respond to client requests as they occur.

Figure 3   Servers providing a virtual desktop after a failure

From time to time, a user might attempt to connect with a clustered server just before it fails. In that case, when the server fails, the user will have to try again. On the next attempt, assuming that the connection attempt is made with a functioning server, it will succeed.

When you create a clustered instance of RD Connection Broker, you configure certain settings differently than you would for a standalone RD Connection Broker server. For a table of the differences, see Appendix A: Differences between a clustered RD Connection Broker and a standalone RD Connection Broker.

Hardware, software, and network infrastructure requirements for a failover cluster

Deploying Remote Desktop Connection Broker with High Availability Using Failover Clustering