If you have been following this blog over the past couple of weeks, you might have read about my previous articles on deploying RDS on Azure IaaS using ARM and JSON templates. To quickly reiterate those previous articles;
In a first article called “Full HA RDS 2016 deployment in Azure IaaS in < 30 minutes, Azure Resource Manager FTW!” I explained the differences between deployment mechanisms in the classic Azure Portal and the new Azure Portal and gave a brief introduction on what JSON is and how to use Visual Studio to build and deploy directly to Azure, based on JSON templates. I showed the end result of this deployment, a high available RDS deployment on Azure IaaS.
In a second article called “RDS on Azure IaaS using ARM & JSON part 2 – demo at Microsoft Ignite!” I showed some of the enhancements I had built on top the JSON templates. In this article I showed the ability to add publicly trusted SSL certificates, 2 Session Collections with a few sample RemoteApps, configurable Session Timeout settings and the use of 2 storage accounts. This article also contains a link to a session at Microsoft Ignite 2016 where the deployment of this JSON template was shown.
Last week I also separately published the 2 short video’s that show the deployment and the end result in action in an article called Video of Ignite session showing RDS on Azure IaaS deployment using ARM/JSON now online!
In this article I want share some of the additions that I have been adding to the ARM deployment.
Configure Licensing method
The previous version of the ARM deployment already added 2 RD Licensing servers to the deployment which are needed to install RDS CAL’s. What’s now also added is the ability to select the desired RDS Licensing method (per user or per device).
When the deployment is started, the desired licensing method can be selected from a dropdown list.
And after completion of the ARM deployment, the selected licensing method is successfully configured in Server Manager.
For setting the RD Licensing method I’m using a PowerShell command by expanding the already existing PowerShell Extension. In the first article I already briefly mentioned the PowerShell Extension option in ARM. It allows you to specify a PowerShell Script to perform actions within a Virtual Machine once it’s deployed. The screenshot below shows how to call a PowerShell Extension. For more information on how to set these up, also see: Windows VM Custom Script extensions with Azure Resource Manager templates
Add Custom RDSH Image
Previous ARM deployments have all been based on a standard Windows Server 2016 image for the RD Session Host Role. In most scenarios however, you would obviously want to deploy your own applications. To accommodate this, I added functionality to select a custom RD Session Host template image to be used for the RD Session Host servers. This allows you to preconfigure a RD Session Host template with custom applications and settings and provide that as a parameter to the ARM deployment.
As part of the previous ARM deployments I also created the necessary storage accounts prior to creating the Virtual Machines. However, if you want to deploy a virtual machine in ARM based on a custom image, that custom image needs to reside in the same storage account as the to be created virtual machine. Because of this (current) limitation we run into a Chicken and Egg problem. How can we make sure that the Custom Template Image is available in the storage account if that storage account is not created yet? There are basically 2 ways to solve this.
The first option is to copy the custom template image as during the ARM deployment. So, after creating the storage account and before creating the RD Session Host servers. The copy action can be performed using Azure PowerShell, so in order to be able to kick of that PowerShell command as part of ARM we need a “dummy” Virtual Machine and create a Custom PowerShell Extension on that. A good example how to perform this is can be found here: Create VM from a custom image in new storage account. Instead of the “dummy” server you can of course also “abuse” another virtual machine that you are also deploying as part of your ARM deployment and configure the Custom PowerShell Extension on that virtual machine. Also be aware that the copy job can add a significant amount of time to the ARM deployment. In my testing a Windows Server 2016 template with Office 2016 installed took about 15 minutes to complete.
The second option is a different and maybe less complex approach. Since we are creating a RD Session Host template, a storage account to host that template is already in place. Why not reuse that storage account to also host the deployed RD Session Host servers? In that case the custom template does not have to be copied and the ARM deployment only needs to be provided with the storage account name and the template name so it can reuse that storage account and deploy the RD Session Host servers in there.
For my ARM template I chose the second option. As part of the parameters the storage account name and the RD Session Host Custom Image can now be provided.
Using the image property of the Virtual Machine we can instruct ARM to use our Custom Template Image.
In this example I used a Custom Template Image based on Windows Server 2016 with Office 2016, Notepad++ and Paint.NET installed as the sample custom applications.
To be able to immediately publish the custom applications I added the following parameters to the ARM deployment. Again, the deployment uses the existing Custom extensions and leverages PowerShell to publish these applications during the ARM deployment
The end result for the end user is that the custom applications are available and accessible in for example RD Web Access as shown below.
Perform basic RD Web Access Branding & customization
To be able to add some very basic RD Web Access branding I added 2 parameters to the ARM deployment that allow you to specify the Workspace name and change the default logo in RD Web Access.
Again using the existing Custom PowerShell extension, these settings are now changed suing PowerShell Cmdlets and the changes are visible to the end user. Obviously these 2 items are not rocket science, but you can image we could extend this to brand the entire Web Access page if we wanted to including colors, fonts etc.
To summarize this article, using ARM and JSON we are now able to;
- Configure the desired Licensing method (User or Device CAL’s)
- Use a Custom Template Image for the RDSH role
- Publish Custom Applications
- Perform basic RD Web Access branding
If you have questions on how certain parts of this deployment have been performed, feel free to reach out to me! Stay tuned for more updates on this RDS deployment in Azure IaaS using ARM!