Freigeben über

Windows Server 2008 R2 Highly Available (Clustered) Remote Desktop Connection Broker

  • Artikel

Hi Mark here again. I was working on W2K8 R2 RD Connection Broker today (this is an exotic topic as people don’t get lots of queries on it) and thought I could share few notes with you just in case you get to the same situation and wonder how things should work.

With Windows Server 2008 R2 failover clustering, Connection Broker is officially listed as one of the resources that could be made highly available (HA) within Microsoft Failover Cluster Manager (MSFC).

image

Now, here are the recommended steps for creating a clustered Connection Broker on Windows Server 2008 R2; 

  1. Install Failover cluster (MSFC) Feature
  2. Install RD Connection Broker role service under Remote Desktop Service Role (Steps 1 and 2 can be interchanged).
  3. Run through the “Configure Service or Application for HA” wizard in MSFC (to make RD Connection Broker service HA).
  4. In the MSFC UI, failover the service group to the 2nd node. Fail back the service to the original node.
  5. Complete the configurations (for example: Add RDV Hosts, RDSHs to the broker, create VM pools etc.) on each Broker node.

If you are a fan of scripting and PowerShell, you could use the PowerShell Script from the TechNet Scriptcenter that could help with this process;

PowerShell Script: Manage RD Connection Broker Cluster (Create, Add nodes)

https://gallery.technet.microsoft.com/ScriptCenter/en-us/5aca700b-7b70-4d06-9ae3-2cfb4fc027ca

 

Something you might notice is that if you fail over this highly available resource, it doesn’t show the connection settings on the other node immediately.

The RD Connection Broker uses an embedded database to store the session related information and passes those to RDSHost servers when they query the Connection Broker service.

On Windows Server 2008 R2, this DB is local to each broker node. Thus, each Broker node keeps its own local DB and only 1 Broker node can be active in the cluster at any given time.

When Broker service fails over to another node and the second node becomes the Active node, all the data will be repopulated in the local database. The primary Connection Broker (Active Node) rebuilds user session state (by querying user session information from RDSH (formerly known as Terminal Servers) Servers and VDI Agents. 
This could cause a minimal amount of downtime (while session information is being rebuilt on new active node) after the failover.

While there’s no official numbers for the down time after a HA connection broker failover but 100s of RDVHosts & RDSHs should be able to rejoin within couple of minutes.

And please keep in mind that Connection Broker isn’t a proxy server and all the existing sessions will continue to work fine during the database rebuild process.

Here’s the TechNet Step-by-Step Guide;

Deploying Remote Desktop Connection Broker with High Availability Step-by-Step Guide

https://technet.microsoft.com/en-us/library/ff686148(WS.10).aspx