Taking a closer look at RD Connection Broker High Availability in Windows Server 2012


Introduction


If you have been following the new features of Windows Server 2012, you’re probably already familiar with the new High Availability features of the RD Connection Broker role in Windows Server 2012. In this article we’ll be taking a closer look at the RD Connection Broker configuration and its database. As a quick recap, we’ll start by summing up the requirements and performing an actual High Availability configuration. Along the way, we’ll take a look at some of the pitfalls during the configuration. After that we’ll dive a little deeper in the configuration and explore the SQL database that gets centrally stored on a SQL Server instance by setting up the High Availability (HA).


Configuring RD Connection Broker HA


Configuring RD Connection Broker HA is divided into two separate steps.


The first step is to prepare the environment for HA. Without running in HA, the RD Connection Broker places its configuration on a SQL Server Express instance which is running locally on the RD Connection Broker server. The first step would obviously be to move that local database to a centrally running instance in order for multiple RD Connection Broker servers to start reading and writing content from and to the database. This is exactly what the first step does. The locally stored SQL Express database is moved to a central SQL Server instance. By completing this first step you create a RD Connection Broker HA ready environment.


The second step would then be to add one or more additional RD Connection Broker servers to create the actual High Availability.


Let’s take a look at the first step, preparing the RD Connection Broker HA. In order to successfully prepare for HA we need to comply with 4 requirements. Those 4 requirements are;



  1. We must have a SQL Server running that allows access from all RD Connection Broker servers, and this must also be at least SQL Server 2008 R2.
  2. All RD Connection Broker Servers involved in the HA setup need to be running the Microsoft SQL Server native client.
  3. All the RD Connection Brokers Servers involved in the HA setup need static IP addresses.
  4. A single DNS resource record for the RD Connection Brokers Servers involved must also exists.

We start the HA configuration by opening Server Manager, and opening the Remote Desktop Management Services (RDSM) console. On the overview page we right-click the RD Connection broker in the deployment overview and choose Configure High Availability.




Figure 1: Launch the RD Connection Broker HA prepare


We choose next on the Before You Begin page, which basically outlines the requirements for the HA setup. After that we are presented with a dialog below.




Figure 2:
RD Connection Broker HA properties


First, the setup needs to know where to store the database. Remember that this needs to be an SQL Server instance running at least SQL Server 2008 R2. Also, note that the first RD Connection Broker you have in the deployment needs at least DB Creator permissions. A way to do this would be to create a group in Active Directory, add all (or at least the first) RD Connection Broker server to that group and give that group DB Creator Permissions in SQL Server.




Figure 3:
SQL Server Permissions


The database connection string we need to specify in the setup must meet a very specific syntax. The syntax is as follows, the text in bold obviously needs to be replaced by the actual values.


DRIVER=SQL Server Native Client 11.0;SERVER=<SQL Server Name>;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=<DB Name>


The driver must meet the version on the SQL Server native Client you’re running on the RD Connection Broker. For SQL Server 2008 R2 this is 10.0, for SQL Server 2012 this is 11.0. The name of the SQL Server is obviously the hostname of the server running the SQL Server instance; this can be the hostname of the FQDN as long as it is resolvable. The name of the database can be anything you prefer.


When specifying the folder to store the databases note that this is obviously a folder on the SQL Server itself where you want the setup to store the .mdf and .ldf files.


The DNS round robin name is the name used to connect to the RD Connection Broker HA setup. This is the same DNS name created as part of the prerequisites phase.


Upon clicking next, the setup checks whether it can successfully connect to the specified SQL Server instance to be able to create the database. If the RD Connection Broker cannot successfully connect we are presented with the following error.




Figure 4:
HA Setup error


There are a number of causes that result in this error. Usually this error is related to one of the following causes:



  • The SQL Server Native client is not installed
  • A firewall is blocking SQL Access from the RD Connection Broker (port 1433)
  • The incorrect SQL Server Native Client version is specified
  • An incorrect SQL Server name is specified

If the connection is successful, the following dialog is shown.




Figure 5:
RD Connection Broker HA Confirm


Note that at this stage the following step is not checked yet;



  • If the RD Connection Broker server has the appropriate SQL (DB Creator) permissions

If we continue by clicking next on the Confirm dialog the following error can arise, and in the eventlog event 32776 is raised. This means that permissions in SQL Server are not in place, as previously specified as part of the prerequisites.




Figure 6:
RD Connection Broker HA SQL permissions error


If the configuration is successful the event log records a “Database Creation – Success”, event ID 32777 followed by a “Database Migration – Success”, event ID 32780.


A database is created and this owner is our first RD Connection Broker server called RDS01.



Figure 7: RD Connection Broker database properties


This makes our Deployment HA Ready, and the Deployment Overview will show “High Available Mode”.




Figure 8:
Deployment overview High Available Mode.


As mentioned before, making the deployment HA Ready was only step 1. Obviously having one RD Connection Broker server does not make it Highly Available yet. Step 2 is to add an additional RD Connection Broker. Compared to step 1, this is the easy part of the setup. We right-click the RD Connection Broker in the Deployment Overview and choose “Add RD Connection Broker Server”.


During the setup the following error can arise;




Figure 9:
Error adding additional RD Connection Broker


Usually this is a permission issue on SQL Server. Recall that one of the prerequisites was that all RD Connection Broker Databases needed permissions to the database. The first RD Connection Broker only needed DB Creator permissions to become owner of the database. For additional RD Connection Broker we need to add these permissions.


This can be done by adding a User Mapping to the group that contains RD Connection Broker servers so that the group has db_owner permissions.




Figure 10:
SQL Permissions


After these permissions are in place, we’re able to successfully add the additional RD Connection Broker resulting in a HA setup.


Taking a closer look at the database


Now that we have the HA setup running, let’s take a closer look at the database. The database that is created (theoretically moved from the SQL Express) contains several tables.


Before we continue I would like to state that modifying any data directly in the database is not supported by Microsoft and that I would not advise you to do so. This chapter is just intended to show you how information is stored in SQL by only doing Select (read) statements.


For example the table rds.ConnectionBroker contains all the RD Connection Broker of this environment and the last time alive signal was received.




Figure 11:
SQL table rds.ConnectionBroker


There are several tables that hold information about which servers run which RDS roles. The table rds.server contains all the servers involved in the RDS environment, including their server ID.




Figure 12:
SQL table rds.Server


This server ID is then used in a table per RDS Role, below as an example the rds.RoleRdsh table.




Figure 13:
SQL table rds.RoleRdsh


The table rds.PoolProperty contains the setting on a Session Collection level. Session Collections are identified by the PoolId.




Figure 14:
SQL table rds.PoolProperty


The table rds.DeploymentSetting contains the settings configured on a deployment level.




Figure 15:
SQL table rds.DeploymentSetting


Conclusion


In this article we’ve been taking a closer look at the RD Connection Broker, specifically in HA mode, in Windows Server 2012. We’ve been looking at the requirements, the setup and some possible pitfalls you may encounter. We’ve also been looking at the content of the database itself. Being able to store configuration data on a central SQL Server is definitely a big improvement compared to the local SQL Express. And although it is called RD Connection Broker High Availability, the HA part is a little bigger than just the RD Connection Broker. In fact, as we’ve seen, the complete RDMS configuration is inside the database.

2 thoughts on “Taking a closer look at RD Connection Broker High Availability in Windows Server 2012”

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top