In part 3, we installed and configured our Netscaler HA pair as well creating the LB virtual server needed here in this part for our connection brokers. Here in part 4, we’ll be setting up our SQL server, creating an HA connection broker farm, adding our second connection broker server and finally, creating the LB virtual server that our external clients will hit to connect to our RDS farm. Lets begin!
Part 4: Installation of SQL Server 2016, Connection Broker Farm and External LB ServerDo understand that what we will have accomplish here is basically moving the single point of failure from the connection broker server itself to the SQL server instead! If you don’t perform some kind of SQL mirroring or HA setup, your entire RDS infrastructure can come crashing down if at any point your SQL server is down. The problem is that most organizations can’t afford to do any sort of SQL mirroring. However, a very cheap and effective workaround if you are using vSphere and have the license for it, is to enable Fault Tolerance mode on that single SQL machine. This feature easily allows you to create a second and exact replica of the SQL server on a different physical host. If the primary goes down, the secondary steps right in and takes over.
SQL Server Preparations
The first thing we’re going to do here is installing SQL 2016 on our SQL server. The database created by the connection brokers later in the procedures will be used to store the information of client connections and other data when they connect to the farm. This is how each connection broker will know how and where to redirect a remote client back to their original session desktop when they disconnect and reconnect rather than dumping them to a new session host and losing their work. Without using a central database such as SQL, the database is stored locally on the server where the connection broker role was first installed. The steps we’ll be performing here will transfer the data on the current local database to SQL so that we can then add another connection broker to the farm for high availability. The load balancing portion will be done on the Netscaler.
I am using SQL 2016 Standard edition for this lab but I’ve also successfully used SQL Server 2012 Standard edition as well. On my cbsql.lab.local server, these are my installation options. The rest I have left at default and have specified my lab\administrator domain account as the SQL administrator.
I’m not sure when this happened but with SQL 2016, the SQL Management Tools is a separate download/install. In the SQL Installation Center, clicking on the install link will open Internet Explorer. You will then need to download the management tools separately. In my case, this would be SSMS 17.4. Problem is, on a server, by default you won’t be allowed to download files in IE. You need to change the security settings by going to Internet Options –> Security –> Custom Level –> Enable File Download.
Once downloaded, the install is basically a one button affair.
Before opening SSMS, we first need to create a security group that will have both connection broker computer accounts as members. This group is then used to grant access to the SQL server itself as well as to the database that will be created in a bit. In my case, the security group will be called ‘rd_brokers’.
Now we can open up SSMS and connect to our default instance. Drill down to Security –> Logins. Right-click on it and select ‘New Login’. Make sure to first select Groups in the Object Types to search for and also to search in your Active Directory location rather than on the local OS. Browse/select the security group we just made above. Next, in Server Roles, grant the role of ‘dbcreator’ in addition to public.
In the SQL server firewall, we need to make an exception for the binary executable. With a default installation, the location would be: ‘C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Binn’. The executable name is ‘sqlservr’.
Creating Connection Broker HA Farm
With our SQL server prepped, we turn our attention back to our two connection brokers. On each, we will need to install the SQL connectivity tools before we will be able to create/connect to the database. Mount the SQL installation ISO on each server and install the tools as shown below. Leave everything else as default.
Last step is to reboot our two connection broker servers. Since we’ve added their computer accounts to the new security group and added the SQL tools, they may not necessarily have the SID applied so you could attempt a logout/login rather than a restart but I prefer the latter to be safe. Once that’s done, we are ready to create our HA farm!
Back on our RDS management server’s Deployment Overview section, right-click the RD Connection Broker icon and select ‘Configure High Availability’. Select the ‘Dedicated Database Server’ option when asked. Finally, on the High Availability page, type in the DNS name you’ve used to map to the IP address of our LB virtual server we’ve created on the Netscaler in the previous article. In my scenario, this would be rdcb.lab.local.
In the ‘Connection string’ field, type in:
DRIVER=SQL Server Native Client 11.0;SERVER=CBSQL;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=CBFARM
You’ll want to obviously substitute the value of CBSQL and CBFARM to values that match your lab environment. You can optionally specify a different folder for the database to be placed in but I just left it blank for the default. Do note that this folder location will reside on your SQL server and not on your connection broker servers. Click Next to proceed.
At this point, the wizard should go to the Confirmation screen. If it does not, you’ll most likely get an error message. Double-check to make sure that the database connection string has no typos and that the servers have been rebooted. Another thing to check is making sure the SQL executable has been allowed in the Windows Firewall on the SQL server itself. If you followed my steps to the dot, you shouldn’t have any issues.I actually got a warning message each time regarding how the DNS name was not resolvable even though it should be. I’m not sure if this is due to the wizard looking for two DNS records for round robin or not but I was able to proceed without any issues.
What we want to do now is head back to SSMS and give our connection broker security group database owner permission on the actual database itself. Under Logins, right-click your security group login –> Properties –> User Mapping. Select the newly created database and under role membership, select ‘db_owner’.
The next step is to add our second connection broker server to the farm. In Deployment Overview, right-click RD Connection Broker icon and select ‘Add RD Connection Broker Server’. Add your second server in the list, confirm it and proceed.Once the connection broker role has been installed on the second server, head back into your Netscaler and look at the RDP service. The RDP service binded to your second server should now show a state of UP because port 3389 is now open due to the installation of the connection broker role.
The last step is to bind a certificate to the two connection broker role services. Head to Edit Deployment Properties –> Certificates and select RD Connection Broker – Enable Sign On. Click on the ‘Create new certificate’ button and fill out the details. This will generate a self-signed SSL certificate for us to us. Hit Apply and then bind the same certificate for the RD Connection Broker – Publishing role. If you’ve followed my tutorial, you should now have an untrusted certificate for each of the connection broker roles and a trusted certificate for the web access and gateway roles.
Creating External LB Virtual Server
At this point, we are finally done with the RDS setup portion! Now we focus on providing external access to our users by creating a LB virtual server similar to what we did for our connection broker role in the previous article. So, login to your primary Netscaler node to begin.
Since we’ve already created our two servers in the last article, we don’t need to perform that step here. We will need to bind a different service/monitor so head over to Services pane and click Add. Give it a service name of your choosing, select one of your existing server, select Protocol of ANY with Port of *.The reason we are creating such a wide open service is due to RDS being able to work off of both TCP port 443 and UDP 3391. The latter is optional but highly recommended because it can provide a much better remote desktop experience, especially for remote users with a slow WAN connection.
Because we didn’t choose a specific port number, Netscaler wouldn’t know how to monitor and probe the actual back-end server to see if it is capable of handling requests. Therefore, we need to create our own custom TCP monitor. Click on the Monitor link. By default, you’ll see the ping-default monitor binded. Click on the Add Binding button and then the + button. Give the monitor a name. I chose ‘custom_https’. Then select Type. In the list, select TCP. Open Advanced Parameters section and in the ‘Destination Port’ field, use 443. Click the Create button and then the Bind button. Perform these similar steps for your second server but reusing the custom monitor you’ve just created.
You should have something similar as shown below:
Now head over to Virtual Servers pane to add a new LB virtual server. Give a custom name, Protocol of ANY, IP address of your chosen VIP and with Port of * and hit OK.
Now click on the Service Binding link and select to bind our two newly created services to this virtual server. Finally, select the Persistence advanced setting link on the right side and change it from OTHERS to SOURCEIP.For some reason, I had to switch to SOURCEIP persistence mode because my lab just wasn’t working with the Android Microsoft RDP Client app. It would not connect at all to my farm! I had no other issues with Apple IOS and PC devices.
You should then have something like this in the end. Remember to save your running configuration once you are done!
Finally, your last step is to port forward ports TCP 443 and UDP 3391 on your router to the IP that was mapped to your external LB virtual server on the Netscaler created above.
Our lab is pretty much complete at this point! In our last article of this series, we’ll test the connection to our RDS farm with various devices as well as the LB/HA component of the Netscaler and gateway/web access/connection broker servers.