Disaster recovery options for the RD Connection Broker 2012 (HA)

 

Introduction

As you probably know the RD Connection Broker in a VDI / RDS deployment plays a very central and important (if not crucial) role on Windows Server 2012. Most of the deployment configuration is stored in the RD Connection database. And when put in High Availability mode this database is stored on a central SQL Server where multiple RD Connection Broker servers can read and write to it. For more info on setting up RD Connection Broker HA see: How to configure High Availability for RD Connection Broker on Windows 8.

Since the role of the RD Connection Broker is so important, a big improvement has been made in the ability to create an active-active highly available (HA) solution. However, since all RD Connection Brokers in a HA solution use the same central SQL Server database, this database (and the instance it’s running on) suddenly become your Single Point of Failure. To overcome this, it’s important to also take a close look at options to setup a High Available SQL Server environment for your RD Connection Brokers. Besides that, regular backups of your RD Connection Broker database are obviously also strongly advised and will save you a lot of trouble in case of a serious SQL Server outage.

In case you do have to recover from a loss of the RD Connection Broker Database, there are several ways to perform this recovery based on what exactly got lost. In this article we will discuss several recovery scenarios.

In any of the scenarios that we will be describing, the result from a RD Connection Broker perspective is the same. The RD Connection Broker servers are unable to connect to the database. Upon opening the Remote Desktop Management Service (RDMS) as part of Server Manager we will see the following error.

Image
Figure 1: RDMS error message

On all RD Connection Broker servers that are part of the deployment we will notice that the RDMS service is stopped

Image
Figure 2: RDMS service stopped

And all RD Connection Broker servers that are part of the deployment will show the following error in the event log, event ID 2048.

Image
Figure 3: Event ID 2048

Recovery scenarios

Let’s look at the different recovery scenarios.

1.      Recover just the RD Connection Broker Database

In case the RD Connection Broker database itself for some reason has been lost (corrupted, accidentally removed, etc.) and a backup of the database still exists, recovery is relatively easy and you will most likely be able to retrieve all configuration settings.

First check that the RDMS service on all RD Connection Broker servers is stopped. Then restore the RDMS database from a backup. In this case I used the SQL Server Manager, but this can obviously be any SQL backup solution.

Image
Figure 4:
Restore RDMS database

Now start the RDMS services again on all RD Connection Brokers. If we now reopen (or refresh) the RDMS console inside the server manager the deployment should be visible and fully restored.

2.      Recover the RD Connection Broker’s SQL Server instance

In case the SQL Server instance is completely lost but you still have a backup of the database several configuration settings are needed but you will most likely still be able to retrieve all configuration settings. First the SQL Server instance itself must be rebuilt. Since we are going to be restoring the original database make sure you rebuild the SQL server with the same version and that the name of the server and SQL instance is the same as before. The basic installation of SQL Server 2012 goes beyond the scope of the article. From this point we’re assuming that SQL Server is running again.

Make sure you set the correct permissions for the RD Connection Broker server to be able to create the database. In this case I used an AD security group containing the RD Connection Broker servers and added that as a security principal in SQL Server.

Also make sure that the SQL Server is accessible for the RD Connection Broker Servers on TCP port 1433.

Also check that the RDMS service on all RD Connection Broker servers is stopped. We now restore the database in SQL Server. Based on your backup mechanism and the version of SQL Server you’re running, the steps needed may vary. In this case I’m attaching a copy of the .mdf and corresponding .ldf file.

Image
Figure 5:
Restoring the RDMS database

Next, make sure that the database still has the correct permissions set for the group containing your RD Session Host servers.

Image
Figure 6:
Permissions on restored database

We now start the RDMS service again on all RD Connection Broker Servers.

Image
Figure 7:
start RDMS services

If we now reopen (or refresh) the RDMS console inside the server manager the deployment should be visible and fully restored.

Image
Figure 8:
RDMS restored

3.      Rebuild all RD Connection Brokers

In case the SQL Server database is completely lost and there is no useable backup of the database then configuration that was stored in the database is obviously lost. In this case you will need to rebuild the RD Connection Broker database from scratch and therefor also re-install at least the RD Connection Broker roles.

The first step is to remove the RD Connection broker roles from all servers that were running the RD Connection Broker role and were part of the deployment. However before we do that, if you have no documentation of what was configured, what you can do is take a look at the registry of the RD Connection Broker. That should still show parts of the configuration. You can create a backup of this part of the registry so that at a later stage use this information to manually recreate part of the configuration. For example you can see information of previously published Remote Apps.

Image
Figure 9:
RD Connection Broker registry

Let’s continue by removing the RD Connection broker roles now. We can do this centrally from a management server if all servers are added to the server manager or by individually logging on to each RD Connection Broker server.

Image
Figure 10:
Removing the RD Connection Broker roles

We now obviously need to rebuild the SQL Server. The process of installing Windows Server 2012 and the basic installation of SQL Server 2012 goes beyond the scope of the article. From this point on we’ll assume that Windows Server 2012 has been installed and a basic installation of SQL Server 2012 has been performed.

Make sure you set the correct permissions for the RD Connection Broker server to be able to create the database. In this case I used an AD security group containing the RD Connection Broker servers and added that as a security principal in SQL Server with the dbcreator role.

Image
Figure 11:
Adding SQL permissions for the RD Connection Broker databases

Also make sure that the SQL Server is accessible for the RD Connection Broker Servers on TCP port 1433.

We’re now ready to reinstall our Session-Based Desktop deployment. We go back to our management server and perform the Scenario Based deployment by selecting Remote Desktop Services installation from the Add Roles and features wizard. We won’t go over all the details in the wizard but make sure you select the exact same settings as your previous deployment. Which means we select the same (first) server to run the RD Connection Broker Role, the same (first) server to run the RD Web Access role and the same servers to run the RD Session Host roles.

Image
Figure 12:
Rerunning the deployment

When the wizard finishes the deployment is complete. Not that the only role we really re-installed is the RD Connection Broker role. The wizard detects that the other roles are already installed and will only add those servers to the deployment. Upon completion of the wizard the RDMS becomes operational again, and we’re able to manage our deployment again using the server manager. However, every setting that was configured through the RDMS is obviously gone since we’re now working on a new, clean database. Therefore we will be presented with a default deployment containing just our RD Connection Broker, RD Web Access and RD Session Host servers.

Image
Figure 13: Default Deployment

This means that from this point you would have to reconfigure Remote Apps, Session Settings, Certificates, etc. Note that part of this configuration you could manually restore by looking at the registry settings that were backed up earlier. Also note that this deployment now uses a SQL Server Express database on the RD Connection Broker we selected. This means that the High Availability configuration also needs to be performed again. There are however, two roles that are not affected by this action and those are the RD Gateway and the RD Licensing role. Those two roles are not configured using the RDMS but via separate MMC snap-ins on the server itself. So information like i.e. RD CAP, RD RAP and RDS CAL configuration is retained.

This last scenario is of course the most complicated one since we have to manually reconfigure every setting in the RDMS. Depending on the size of the environment and the number of customizations and changes performed after the initial deployment, the time to reconfigure this back to the way it was may vary.

Conclusion

As mentioned in the introduction of this article, the RD Connection Broker role plays a very important part in RDS/VDI environments in Windows Server 2012. Therefore, making the SQL database highly available is crucial to not let it become a single point of failure. If creating some form of SQL Server High Availability is not an option in your environment at least make sure you create backups of the SQL database regularly. As we have seen disaster recovery of your RD Connection Broker data (and thereby RDMS data) is possible but how fast and how accurate the restore is highly depends on your SQL HA and backup solutions.

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

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

Scroll to Top