RD Connection Broker High Availability in

Windows Server 2012 with SQL Server 2012

Availability Groups
Introduction
The RD Connection Broker role service is a vital part of any native RDS deployment. It acts as the central
brain of an RDS deployment, providing new connections and reconnections to active sessions to one or
more RD session host session collections, VM pools and personal VMs. Because of this role service’s vital
role in the RDS deployment it’s a good idea to ensure RD Connection Broker provides uninterrupted
service.

In Windows 2008 R2, you could create an active-passive RD Connection Broker High Availability
database scenario, but it had a few pain points:

 It was active-passive (and could not scale out as needed)

 Because the setup used Failover Clustering, you had to conform to the hardware and software
requirements of a Failover Cluster in Windows Server 2008 R2.
 The setup was intricate and lengthy

Microsoft has addressed these pain points in Windows 2012. You can now create an active-active RD
Connection Broker high availability deployment with much less effort, and that also includes HA for the
RD Connection Broker database. In a series of posts the Microsoft RDV team showed you how to create
this full HA scenario.

Their first post showed you how to configure multiple RD Connection Brokers for HA including how to
use a common SQL database. Then in a second blog post the RDV team gave you three options for
making the RD Connection Broker SQL data highly available. The second post was a high-level look at
these options, so we decided to delve further and walk you through making RD Connection Broker in
Windows Server 2012 highly available and also making the with SQL Server database it uses highly
available by implementing SQL AlwaysOn Availability Groups.

You might ask yourself:

The RDV Team’s second blog post (link above) outlined using three options for SQL Server 2012 HA:

1. AlwaysOn Failover Cluster Instances

2. AlwaysOn Availability Groups
3. Database Mirroring

Why did you choose to write about the Availability Groups option instead of the other two?

To answer this we will give a quick summary of the three SQL Server 2012 HA options listed above and
then talk about why we chose to implement AlwaysOn Availability Groups.
  AlwaysOn Failover Cluster Instances (FCI) fails over whole SQL instances and can also work
across subnets to provide better site protection. An AlwaysOn Failover Cluster Instance requires
symmetrical shared disk storage (for example, a SAN or SMB 3.0 file share) between all nodes in
the WSFC cluster. An AlwaysOn FCI can be a part of an AlwaysOn Availability Group.
 AlwaysOn Availability Groups work at the database level. It can failover multiple databases,
allows for multiple secondary databases (for better redundancy) and does not require shared
disk storage.
 Database Mirroring is going to be deprecated over the next two releases of SQL and Microsoft
recommends using Availability Groups instead (read the Note at the top of this link for
confirmation).

Note: for more information about SQL Server 2012 AlwaysOn capabilities, see the reference links at the
end of this article.

We chose to use AlwaysOn Availability to make the RD Connection Broker SQL database highly available
because it is a new SQL 2012 capability that does not require symmetric shared storage.

We want to configure RD Connection Broker HA with SQL Server HA using the minimum amount of
servers needed to achieve HA for both the RD Connection Broker role service and the database. We can
do this using two servers – each will be an RD Connection Broker and also a SQL server as shown in
Figure 1 below.

RDCB.domain.local

RD Connection Broker SQL Server

HA
SQL Server RD Connection Broker

RDCB1 RDCB2

Figure 1: Each server will contain the RD Connection Broker role service and also a SQL 2012 instance to
house the RD Connection Broker data.

The RD Connection Brokers achieve HA by having two RD Connection Brokers (RDCB 1 and RDCB 2) using
a common SQL Server database (housed on RDCB1). The database is also highly available because it is
part of a SQL Server 2012 Availability Group comprised of RDCB 1 and RDCB 2.
Now we will show you how to configure RD Connection Broker for HA and then how to make the
database that RD Connection Broker uses highly available as well. Specifically, we will show you how to:

1. Configure or install any prerequisites on the two servers

2. Install SQL Server 2012 on each server for use in a RD Connection Broker high availability
deployment
3. Prepare your RD Connection Broker for HA
4. Add a second RD Connection Broker to the deployment
5. Configure SQL Server 2012 AlwaysOn Availability Groups
6. Test the configuration (simulate a downed server node)

Note: For this setup we assume that one server already has the RD Connection Broker configured.

General Pre-requisites
Before you configure RD Connection Broker HA with SQL HA, there are a few requirements that need to
be in place on both servers:

1. You must use an admin account to complete this implementation.

2. Both servers must have static IP addresses
3. The SQL Server Native Client must be installed on both RD Connection Broker servers. In this
scenario we will install SQL Server on each RD Connection Broker server, so the native client will
be installed as part of the SQL installation. In other cases (ie. if you were using other servers for
SQL servers) the SQL Server Native Client must be installed and the version must match the
version of SQL Server (version number 11 is SQL Server 2012, version number 10 is SQL Server
2008).
4. Create a DNS Round Robin (DNS RR) record for each RD Connection Broker server with their
respective static IP address so that traffic will be distributed evenly to the two RD Connection
Broker Servers. DNS records will resemble Figure 2.

Figure 2: Create a DNS round robin host record for each of your RD Connection Brokers.

Note: Using DNS RR as a load balancing solution has its faults. DNS RR does not poll the RD
Connection Broker servers to check if they are up, so you will have down time if a server drops off
and you don’t remove the DNS entry. Because of this, we recommend using a hardware load
balancer or Windows Network Load Balancing (NLB).

5. Create a folder on each server to store the SQL database files. In this example we use C:\RDCB.
6. If you use RD Gateway and you control specific machine access using your RD RAP policy (i.e.
you did not select the option to allow access to all network machines) then you need to add the
DNS RR name of your RD Connection Broker servers to the RD RAP policy to allow clients to
connect to an RD Connection Broker using that DNS RR name.
7. Configure the firewall on both servers to allow access to SQL Server by opening a TCP port in the
firewall.
 8. Create two User accounts in Active Directory that will be used (later when we install SQL Server)
as logons for the SQL DB Engine Service and SQL Agent service accordingly.
9. Create a new Security Group (as shown in Figure 3) and add the two user accounts to it. (This
group will be used later when we setup the SQL Server Availability Group.)

Figure 3: Create a new Security Group in Active Directory and add your SQL service user Account
to it.

Installing and Configuring SQL Server 2012 for use with RD Connection Broker HA
Now we will walk through the required installation prerequisites for the SQL Server 2012 installation, we
will install SQL Server 2012 on each server, and give RD Connection Broker the required permissions on
the SQL Servers so that it can communicate with SQL Server.

SQL Server 2012 HA Prerequisites

First, the SQL Server Availability Group configuration requires the Enterprise edition of SQL Server 2012
(and the SQL Server edition must match the OS version). In our example we install the 64bit version of
SQL Server 2012 Enterprise.
Second, before you install SQL Server 2012, the following features need to be installed on each SQL
Server:

1. .NET Framework 3.5.1 – When you run the SQL Server Setup on Windows 2012, if .Net 3.5.1 is
not already installed, the installation will automatically download and install it so you will
need internet access on the servers (or install it before hand). If you are running Windows
2012 R2, this does not work unless you add the .Net 3.5 feature (don’t forget to point to the
source files) before running the SQL Server 2012 install.
2. Windows Server Failover Clustering (WSFC) – SQL Server 2012 AlwaysOn technology relies
upon the WSFC feature so you need to enable it. To do this (on both servers) you:
a. Open Server Manager and click the Add Roles and Features link. Click Next on and
the Before You Begin Screen.
b. Choose Role-based or feature-based installation and click Next.
c. on the next screen select the server from the server pool and click Next
d. On the Server Roles screen click Next.
e. On the Select Features screen check the box next to Failover Clustering. Click Add
Feature on the pop-up screen. Then click Next.
f. Confirm installation selections, check the box next to the option to “reboot the
installation server automatically if required” and click Install.

Install SQL Server 2012

You need to install SQL Server 2012 on both servers. We won’t walk through every screen shot of the
SQL Server installation, but here are a few tips you need to install SQL Server 2012 properly for this
scenario:

1. During the SQL Server setup specify the two SQL service accounts you created in Active
Directory for the SQL DB Engine Service and SQL Agent service accordingly. In this scenario these
accounts can be used for the SQL installation on both servers.
2. When you are installing SQL Server 2012 to implement AlwaysOn Availability Groups, you need
to choose the “New SQL Server standalone installation…” option.
3. The only two SQL Server components you need to install for this specific scenario are Database
Engine Services and Management Tools – Complete. This will cut down on the time and space it
takes to install SQL Server 2012.
4. In our lab we do not name our SQL instance (we accept the default). If you name your SQL
instance then it automatically uses dynamic ports. Here is how to set the port to 1433 if you
name your instance: http://technet.microsoft.com/en-us/library/ms177440.aspx.

SQL Server 2012 Post Installation Configuration

Once SQL Server 2012 is installed on both servers, you need to give RD Connection Broker permission to
communicate with SQL Server:

 The first RD Connection Broker needs the dbcreate permission in SQL Server in order to create
the new SQL database. (This permission can be removed after you prepare RD Connection
Broker for HA later in this article).
Both RD Connection Broker servers need dbowner permissions on the database in order to write to it.In
this specific scenario, where SQL Server is installed on the RD Connection Broker itself, the required
permissions are slightly different; when using a local SQL Server instance, RD Connection Broker
identifies itself with the ‘NT AUTHORITY\NETWORK SERVICE’ account (instead of the RD Connection
Broker Machine account).

The easiest way to make sure you have the correct permissions is to:

1. Add the ‘NT AUTHORITY\NETWORK SERVICE’ account as well as both RD Connection Broker
computer accounts to the Computer Management / Local Users and Groups / Groups / RDS
Management Servers local group on both servers as shown in Figure 4.

Figure 4: Add the ‘NT AUTHORITY\NETWORK SERVICE’ account as well as both RD Connection
Broker computer accounts to RDS Management Servers local group on both servers.

Note: Afterwards be sure to reboot both RD Connection Broker servers to ensure that the group
membership is in place.

2. On each SQL Server open SQL Management Studio and add a new security Login called
“BUILTIN\RDS Management Servers” as shown in Figure 5.
 Figure 5: Create a new SQL Login on both SQL Servers.

3. Select Server Roles and then check the boxes next to the “dbcreator” and “public” roles as
shown in Figure 6:
 Figure 6: Add the public and dbcreator server roles to the new BUILTIN \ RDS Management
Servers login.

Note: You cannot set the DB Owner permission at this point because the database does not exist yet. You
will do this later once the database is created.

Implementing RD Connection Broker for HA

Now it’s time to implement RD Connection Broker HA. You do this is two steps: first you prepare RD
Connection Broker for HA, and then you add a second RD Connection Broker server to the configuration.
These two steps are detailed below.
Preparing RD Connection Broker for HA
When you prepare RD Connection Broker for HA you are telling the first RD Connection Broker to create
a new database in SQL Server, and to move the RD Connection Broker data from the local internal
database to the new SQL Server database. Here’s how to do it:

On your management server open RDMS, and navigate to the Server Manager / Remote Desktop
Services / Overview screen. Then follow these steps:

1. In the Deployment Overview section right click RD Connection Broker and choose Configure
High Availability. This will start the Configure RD Connection Broker for High Availability wizard.

2. Click Next on the Before You Begin screen and then on the Configure High Availability screen
enter the following data (as shown in Figure 7) and click Next:
a. The database connection string in this format: DRIVER=SQL Server Native Client
11.0;SERVER=<Name of the first SQL Server which in this case is the same server as the
first RD Connection Broker server>;Trusted_Connection=YES;APP=Remote Desktop
Services Connection Broker;DATABASE=<The name you want to call the new database
that will be created without a file extension>
b. The name of the folder you pre-created to store the database files.
c. The DNS RR entry name that will be used by clients to connect to the RD Connection
Brokers. (You pre-created those DNS entries earlier in the Prerequisites section).
 Figure 7: Enter the Database Connection String, the database files storage location, and the DNS
round robin name.

3. On the Confirmation Screen click Configure.

Now that the database is created you need to give both servers db_owner permissions on the database
so they both can write to it. To do this:

1. Open SQL Server Management Studio on the first SQL server (which is also your first RD
Connection Broker server) and drill into Database / <your RD Connection Broker DB> / Security /
Users.
2. Right click on the user BUILTIN\RDS Management Servers and choose Properties.
3. Select Membership and check the box next to “db_owner” as shown in Figure 8. Then click OK.
Figure 8: Give the BUILTIN\RDS Management Servers user db_owner permissions for the RD Connection
Broker SQL database.

Adding a Second RD Connection Broker

Once both servers have db_owner permissions on the RD Connection Broker new SQL database, it’s
time to add the second RD Connection Broker. On your management server open Server Manager and
navigate to the RDMS Overview screen. Then follow these steps:

1. In the Deployment Overview section right click RD Connection Broker and choose “Add RD
Connection Broker Server”.
2. Click Next on the Before You Begin screen.
3. Select your second server from the server pool, add it to the Selected area and click Next.
4. Confirm the selection and then click Add.

Configure Certificates
Once the role service is installed on the second server, The View Progress screen will show the Status as
Succeeded. It will also tell you that you need to install SSL certificates on the new RD Connection Broker
server, as shown in Figure 9.

Figure 9: The View Progress screen will alert you to the need to install SSL certificates on the newly
created RD Connection Broker server.
You may have already configured certificates when installed your first RD Connection Broker server. You
must run through the certificates configuration again now because the new server will not automatically
be configured with the certificates you already put in place on the first RD Connection Broker server.

Also, because you have configured RD Connection Broker HA, full desktop connections and RemoteApps
will point to the RD Connection Broker RR DNS name that you setup earlier (this is referred to as the
“client access name”). The RD Connection Broker will respond to requests by providing an SSL certificate
to prove its identity. The certificate it will respond with is the one you configured the server to use for
“Server Authentication” in RDMS / Deployment / Properties / Certificates. So, the subject name on the
certificate must reflect this new client access name.

Here’s where things can get complicated.

For domains that use a public sub-domain name for your internal network, for example,
“internal.domain.com” this is not an issue. Just make sure the RD Connection Broker server-
authentication certificate name matches name you use for the RR DNS name of your RD Connection
Broker HA setup (the “client access name”). You could also get a wildcard certificate e.g.
*.internal.domain.com, and use it for all your cert settings.

However, if you use an internal domain name for your internal domain (e.g. domain.local or
domain.internal) then you could get a certificate name – to – RR DNS name mismatch if your SSL
certificate subject name does not reflect the internal RR DNS name. You will receive a yellow warning
popup box telling you so, and asking you if you want to continue with the connection. To fix this you
need to make the certificate name match the RD Connection Broker HA client access name. There are
two requirements that make resolving this error a pain:

1. Public CAs soon will no longer create private domain certificates (ie. certificates ending in
“.local”, “.internal” etc.)
2. The client access name you provide must be resolvable in your internal domain DNS.

For domains use an internal domain name, these are your options (for better or worse) for making the
client access name match the certificate subject name:

1. For the next two years you can get a certificate with a Subject name that reflects your local
domain name (HA-client-access-name.domain.local). But after 1NOV15, you will have to find
another way because that certificate will expire and you will no longer be able to get an SSL
certificate containing an internal server name. For more information read:
https://www.cabforum.org/Baseline_Requirements_V1.pdf (top of page 9).

Note: This may not work with all public CAs because some public CAs are choosing to not issue
certificates with internal server names now. But as of today, some still do (for example, Verisign
still does).

2. If you maintain your own PKI infrastructure, you can issue a certificate that has a subject name
that reflects the RD Connection Broker RR-DNS name (for example: rdcb.domain.local). Install
the certificate in RDMS as the RD Connection Broker server-authentication certificate, and use
this name as the client access name. All clients accessing the deployment will have to trust your
CA certificate.
 3. Maintain a DNS zone file on your internal domain that reflects your external domain. Create RD
Connection Broker RR DNS entries in your external domain zone file that point to the RD
Connection Brokers’ internal network IP addresses, (for example: rdcb.domain.com). Then get a
certificate from a public CA that is either a wildcard certificate (*.domain.com) or that has a
subject name that is the RD Connection Broker RR DNS name and use it for RD Connection
Broker server authentication in RDMS. (You could also accomplish this by creating HOST file
entries on RD Gateway server, both RD Connection Broker servers and your RDMS server, but
we don’t recommend this for real live environments).

Tweaking RD Connection Broker High Availability Settings

Once you configure RD Connection Broker High Availability, the RDMS GUI does not allow you to change
the configuration; the interface becomes read-only. But you can change the DNS Round Robin name
that clients will connect to, with this command:
Set-RDClientAccessName [[-ConnectionBroker] <String>] [-ClientAccessName]
<String> [<CommonParameters>]

For example, because we maintain an external DNS zone file on our internal domain, we reconfigure our
ClientAccessName to match:

1. The RR DNS name that represents the cluster, and

2. The name that is listed on the SSL certificate that RD Connection Broker uses for Server
Authentication

To do so we run this command:

Set-RDClientAccessName -ConnectionBroker "ka.ash.local" -ClientAccessName "rds.virtualkristin.com"

About The “Active” RD Connection Broker in RDMS

When you make changes to the High Availability settings, make sure your command points to the
“active” RD Connection Broker where applicable.

The “active” RD Connection Broker server is the one that is listed right under the Deployment Overview
heading of the Server Manager\Remote Desktop Services\Overview page.

You can change the active RD Connection Broker by selecting “Tasks” -> “Set Active RD Connection
Broker Server”.

Using the word “active” here is confusing phrasing (but Microsoft uses it so we will explain it). Aren’t
both RD Connection Brokers active in a high availability scenario? The answer is yes. When Microsoft
refers to the “active” RD Connection Broker in RDMS, it is the one that is actively communicating with
your management server (RDMS) – there can be only one active server in this capacity. In other words,
in a high availability scenario, both RD Connection Broker servers are “active” in terms of handling user
changes, but only one “actively” communicates with RDMS.
Setting up SQL Server High Availability Groups for RDCB
Now that we have RD Connection Broker HA setup, we’ll set up a SQL Server High Availability Group to
make the RD Connection Broker SQL database highly available. To do this you:

1. Create a Windows Server Failover Cluster

2. Make some configuration changes in SQL Server
3. Create the Availability Group

Let’s look in detail at each of these steps.

Create a Windows Server Failover Cluster

A pre-requisite of creating a SQL Server 2012 Availability Group is that the SQL Servers must be part of a
Windows Server Failover Cluster (WSFC). You need to create the WSFC and add both nodes (SQL
Servers) to it:

1. Open Control Panel, Administrative Tools, Failover Cluster Manager. Click Validate a
Configuration, and enter the names of the servers running SQL Server.
2. After the validation finishes make sure you read through Report that gets created. If you notice
errors that prevent you from continuing, fix them and rerun the validation.
3. When you’re satisfied with the result, click “Create the cluster now using the validated nodes”.
4. During the setup you will provide a cluster name and corresponding IP address. The DNS name
get automatically registered in the AD DNS. After the wizard finishes you will see a summary of
the installation (shown in Figure 10).

Figure 10: Once the Failover Cluster wizard completes, you will see a Summary screen. At this point it
will show 0 clustered roles and two nodes.

SQL Server Pre-Configuration for Availability Groups

To create a SQL Server Availability Group, you need to make the following configuration changes on
both SQL Servers. Follow these steps:

1. Open the SQL Server Configuration Manager. Select SQL Server Network Configuration, click
Protocols for MSSQLSERVER, and double-click TCP/IP. Make sure that “Enabled” is set to Yes.
2. Click SQL Server Services in the left pane, then select SQL Server in the right pane, right click and
select Properties. Go to the AlwaysOn High Availability tab and select Enable AlwaysOn
Availability Groups as shown in Figure 11.

Figure 11: Enable AlwaysOn Availability Groups on both SQL Servers.

3. Restart the SQL Server service to let the configuration changes to take effect.
4. On both SQL Servers, open SQL Server Management Studio and create a New Login in the
Security section. Browse Active Directory for the name of the Security Group you made earlier.
Add the Sysadmin Server role to this group (shown in Figure 12).

Figure 12: Create a new Login on both SQL Servers and name it the same name as the Active
Directory Security group you created earlier.

5. Create a new folder on a shared network location. This share will be used to initialize replicas
with backups and restores. Give the AD Security group containing your SQL server service
accounts read and write NTFS permissions and full control share permissions.
6. Perform a full backup of the RD Connection Broker database using SQL Server Manager GUI or
CLI. Do not skip this step. It is required to complete the New Availability Group wizard.
Create the Availability Group
You are now ready to start configuring a SQL Server Availability Group. Follow these steps:

1. On the SQL Server currently running the RD Connection Broker database, open SQL Server
Management and drill down to the AlwaysOn High Availability section. Right click Availability
Groups and select New Availability Group Wizard.
2. Click Next on the next screen. Enter a name for the Availability group and click Next.
3. Check the box next to the RD Connection Broker database and click Next.
4. Click Add Replica and enter the second SQL Server as shown in Figure 13 and click Connect.

Figure 13: Specify the second SQL Server to host a secondary replica.

5. For both servers, check the boxes next to Automatic Failover and Synchronous Commit. For
now, leave the Readable Secondary option set to default setting “No”, which means you cannot
read the database of the secondary server.
6. Select the Listener tab (shown in Figure 14) and enter a DNS name that will represent the
availability group listener and a corresponding IP address. RDMS will use this name/IP address to
communicate with the SQL Server Availability Group. Unless you modified the default port,
enter port 1433. An entry will be created in DNS as part of running this wizard. Click Next.
 7. Figure 14: Enter the DNS name and port number you want to use for communication between
the Availability Group and RDMS.Click Next to start the Availability Group Validation. All
categories should return a “Success” result. Then click Next.

Note: If you run into issues creating the Availability Group Listener, make sure that the account
you are logged in with has the “Create Computer Objects” permission on the default Computers
container in Active Directory User and Computers. For further help, read “Troubleshooting
AlwaysOn Availability Group Listener Creation in SQL Server 2012”.

8. On the Summary screen click Finish to let the wizard create the Availability Group.

Once the wizard is finished, SQL Server Manager should now show that an Availability Group has
been created containing two Replicas, the RD Connection Broker database and the Availability
Group Listener (shown in Figure 15).

Figure 15: The Availability Group will show its replicas, the database, and the listener.

Now open the Failover Cluster Manager on either SQL Server. The configuration will now have a new
Role that is named after your Availability Group. It was created automatically when you created the
Availability Group in SQL Server (shown in Figure 16).
Figure 16: When you create the SQL Server Availability Group a Failover Cluster Role is automatically
created.

Configure RDMS to start using the Availability Group Listener

Now that the SQL Server Availability Group is up and running you have to allow automatic & manual
failover. Do this by updating the RDMS High Availability Settings database connection string to point to
the SQL Server Availability Group Listener instead of a single SQL Server. Use this PowerShell
commandlet to update the database connection string:

Set-RDDatabaseConnectionString [-DatabaseConnectionString] <String> [[-ConnectionBroker] <String>

] [ <CommonParameters>]

The command looks like this:

Set-RDDatabaseConnectionString -ConnectionBroker <Name of the “active” RD Connection Broker in

RDMS> -DatabaseConnectionString "DRIVER=SQL Server Native Client 11.0;SERVER=<Name of the
Availability Group Listener>;Trusted_Connection=YES;APP=Remote Desktop Services Connection
Broker;DATABASE=<Name of the RD Connection Broker database>"

The command we ran in our test lab looked like this:

Set-RDDatabaseConnectionString -ConnectionBroker ka.ash.local -DatabaseConnectionString

"DRIVER=SQL Server Native Client 11.0;SERVER=rdcb-avl;Trusted_Connection=YES;APP=Remote Desktop
Services Connection Broker;DATABASE=RDCB"

If no output is returned by the commandlet this means that the change was successful. Close and re-
open RDMS on your management server to see the change as shown in Figure 17.
Figure 17: The updated database connection string will appear in the Deployment Properties, High
Availability Settings section once you close and re-open Server Manager on your management server. It
will now point to the SQL Server Availability Group Listener instead of an individual SQL Server

Testing
It’s easy to test this configuration. To initiate an automatic failover, disconnect the NIC on the primary
RD Connection Broker / SQL server. You will see the node get removed from the failover cluster
membership in Failover Cluster Manager (as shown in Figure 18), but client connections continue
successfully.

Figure 18: When you test this High Availability configuration by disabling the NIC from the first RD
Connection Broker / SQL server, you will see that server get removed from the active failover cluster
membership.
Summary
Because of the vital role RD Connection Broker plays in a native RDS deployment, its important to
maintain uptime not only for the role service, but for the RD Connection Broker database as well. In this
article we showed you that with two servers you can create an active-active RD Connection Broker HA
environment that includes the database being highly available as well. We walked you through all
prerequisite steps you need to perform to get started with this setup. Then we showed you how to
install SQL Server 2012 specifically for use with RD Connection Broker High Availability. We talked about
how to prep you RD Connection Broker for HA and how to add a second server to the deployment. Then
we made the RD Connection Broker database highly available by configuring a SQL Server 2012
AlwaysOn Availability Group. Finally, we tested the setup by simulating a downed server and initiating
client connections. For more information or troubleshooting advice review the documents listed below.

Important Articles
 RD Connection Broker High Availability in Windows Server 2012
 Configure Remote Desktop Connection Broker in Windows Server 2012 with SQL Server 2012
High Availability
 AlwaysOn FAQ for SQL Server 2012
 Microsoft SQL Server AlwaysOn Solutions Guide for High Availability and Disaster Recovery
 Prerequisites, Restrictions, and Recommendations for AlwaysOn Availability Groups (SQL Server)
 Windows Server Failover Clustering (WSFC) with SQL Server
 AlwaysOn Failover Cluster Instances (SQL Server)
 Microsoft SQL Server AlwaysOn Solutions Guide for High Availability and Disaster Recovery
 Remote Desktop Cmdlets in Windows PowerShell
 PowerShell Command: Set-RDConnectionBrokerHighAvailability
 PowerShell Command: Set-RDClientAccessName
 PowerShell Command: Set-RDDatabaseConnectionString
 Troubleshooting AlwaysOn availability group listener creation in SQL Server 2012
 Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, v.1.0