This week I made some really nice progress in achieving my end goal: ‘an automated Cloud Only Remote Desktop Services deployment’. This series consists of multiple blogposts, each blogpost covers a section which describes in detail how to configure the used technology. In the first blogpost of the series I described that this series is based on a CloudOnly deployment of RDS 2016 with as much PaaS services as possible and using Azure ARM templates for deploying the resources. The good news is that with all the progress made this week I’ve a working deployment which creates all the resources, configures Storage Spaces Direct as high available storage solution and a high available Remote Desktop Services environment.

Let’s start with summarizing what’s is described in the other blogposts of this series:

• Part 1 – Describes the deployment of Azure AD Domain Services together with the Virtual Networks and the VNET peering between them. The reason for VNET peering is explained in this post;
• Part 2 – Describes the deployment of the Azure Resources needed for the High Available deployment of Windows Server 2016 Remote Desktop Services;
• Part 3 – Describes the deployment of Windows Server 2016 Storage Spaces Direct including Clustering with a Cloud Witness;
• Part 4 – Describes the sections of the configuration which is needed for a high available Remote Desktop Services environment.
• Part 5 – First public release of the solution on my Github account (planned for the 22^nd of November)

The reason why I release the total solution on the 22^nd of November is that, on that day I will present a Remote Desktop Service 2016 session together with Danny van Dam on ExpertsLive (Dutch IT Pro Event). In this session I will demo the solution and later that day I will post the solution on my Github repo. So what have I done this week to make the solution work J:

1. I changed the initial configuration of the servers. First I used Group Policies to configure WinRM, CredSSP authentication and the Firewall. During the tests of the deployment I could not trust on the timing when the Group Policies were applied on the servers. This was resulting in very unstable deployments. So I put that configuration inside a ‘Custom Script Extension’ which runs on every server after the domain join extension. The following is configured on each server:
   
   

2. The second addition I made to the script was the configuration of the RD Connection Broker high-availability. Based on the parameters of the ARM template I composed the Connection string to the Azure SQL database. The following code will configure the RD Connection Broker high availability and installs the second RD Connection Broker:
3. The third addition to the script was the installation of the ‘secondary’ roles through the Remote Desktop cmdlet ‘Add-RDServer’.
4. The fourth addition is the installation of the certificates. I placed the certificate in a Azure Storage account which is protected with a storage key. In the ‘Custom Script Extension’ you can configure the storage key so that the resources are download from this protected location. With this I doesn’t have to publish the certificate on a public source. The following code installs the certificate on the environment:
5. The fifth addition is the creation of the Session Collection and enabling the User Profile Disk mechanism with the SOFS share hosted on the deployed Storage Spaces Direct cluster. The share send to the script from the ARM template as parameter:
6. The last addition is about configuring the RD Gateway policies so that users can connect through the RD Gateway to the RD Session Hosts. Out-of-the-box the 2^nd RD connection broker is not added to the RAP policy and also the RD Session Hosts are not added to the RD Gateway. Out-of-the-Box there is also a RAP that allows the Domain Users to connect to all Domain Computers through the RD Gateway. As best practice I advise to delete this ‘standard’ rule. This script covers all these actions (based on this original blogpost:

With all of the above additions the deployment is fully automated and working. After the deployment you’re able to connect through the AzureAD Application Proxy to the RDS environment from the outside world and from the internal network directly through the RD Web Access. The solution which I will publish on the 22^nd of November will contain templates for the following deployments:

• High Available RDS deployment using platform images connecting to an existing AD and using the Azure AD Application proxy for remote publishing
• High Available RDS deployment using platform images connecting to an existing AD with the RD Web Access and RD Gateway published to the Internet
• High Available RDS deployment using custom images connecting to an existing AD and using the Azure AD Application proxy for remote publishing
• High Available RDS deployment using custom images connecting to an existing AD with the RD Web Access and RD Gateway published to the Internet

The coming weeks I will test the deployments and without any big issues I will publish it on the 22^nd of November on my Github: https://github.com/arjanvroege.