Thursday, August 18, 2016
Remote Desktop Services (RDS) deployment on the Azure Infrastructure as a Service (IaaS) platform is becoming more common. The announcement of the deprecation of Azure RemoteApp, the turn-key solution on Azure to publish classic Windows applications, also made RDS on Azure IaaS one of the migration options going forward. Microsoft has also published various whitepapers that provide guidance to implement RDS 2012 R2 on Azure IaaS http://aka.ms/rdsonazure. Recently they have also updated this for Windows Server 2016 http://aka.ms/rdsonazure2016 which will be released this September of this year.
Automated deployments in the classic Azure Portal
I decided to take a closer look at the deployment itself, more specifically an automated deployment. RDS can obviously be deployed manually in Azure IaaS by creating new Virtual Machines, Virtual Networks, load balancers etc. Based on the classic Azure Portal (http://manage.windowsazure.com) this is what you would typically do. Optionally you could use Azure PowerShell to automate that process.
Automated deployments in the new Azure Portal
The new Azure Portal, codename Ibiza, (http://portal.azure.com) is all about Azure Resource Manager (ARM). ARM introduces a completely new way of thinking about your resources. Instead of creating individual resources, you start by thinking about the entire solution, a resource group, which contains all the resources you need for your solution. You manage and deploy a resource group as a sort of a logical unit, which helps identify all the resources a solution uses. Another benefit of ARM is that it allows you to retrieve billing and monitoring information for all the resources within a resource group and manage the access to those resources as a set rather than individually.
Besides the benefit of having all resources in logical units called Resource Groups, another huge benefit of ARM is the deployment itself. Sure you can create a Resource Group manually using the Portal or use Azure PowerShell. Typically, however, an Azure PowerShell script is sequential, you create a PowerShell script to automate the commands needed to create objects in Azure. When you run such a script those PowerShell commands are fired off sequentially creating your deployment. ARM provides the opportunity to have Azure create that same deployment for you in the most optimal way. For example, by defining dependencies ARM knows it must create a virtual NIC prior to the Virtual Machine and can for example create 10 Virtual Machines at the same time. This significantly improves the overall deployment time for any Azure deployment.
Where does JSON come into play?
Introduction into JSON Azure Templates
There are various editors out there to create JSON Templates, in my case I choose Virtual Studio Enterprise 15 because it has awesome integration with the Azure Portal as you can start and monitor your deployments directly from Virtual Studio. Make sure you install the Azure SDK for this as well.
If you want to get started with JSON templates for Azure I can recommend to read the article Authoring Azure Resource Manager templates. It describes the JSON format and the template structure as well.
After getting familiar with the JSON template structure I recommend to look at several JSON template examples for Azure to sort of get the idea on how objects in Azure can be build. The Azure Quickstart Templates is great place to start, I based parts of my deployment on examples I found there too.
After installing the Azure SDK, you will see a new option in Visual Studio to create a new Azure Resource Group.
When you select this template you immediately see the power of the combination Azure SDK and Visual Studio! Directly from Visual Studio you can create predefined objects for Azure. If you want to start from scratch, you can select the option Blank Template.
Even after the creation of the (blank) project you can easily add Azure Objects from within Visual Studio using the Add New Resource option.
JSON & ARM in action to deploy RDS on Azure IaaS!
What is described in the previous paragraphs is exactly what I have been working on for RDS on Azure IaaS. The goal was to create an automated RDS deployment in Azure IaaS using JSON Templates. As a starting point for the execution of this JSON template I assume that the following exists
- An active Azure Subscription
- A Virtual machine with a basic Active Directory deployment
- A Virtual Network containing a Subnet
To simply the process and focus on RDS for the most, I basically assume that the fictive customer already has deployed other resources to Azure, which is actually very common these days. However, adding the deployment of the resources outlined in the bullet list above is obviously no problem as well.
The screenshot below shows the described starting point in the Azure Portal
So, what does my JSON template create inside the Azure Resource Group show above?
- A Storage account
- 2 Virtual Machines with the RD Connection Broker and RD Licensing role
- 2 Virtual Machines with the RD Gateway & RD Web Access role
- 2 Virtual Machines with the RD Session Host role
- Each Virtual Machine is created with a NIC and a fixed IP address
- Each Virtual Machine is joined to the Active Directory Domain
- 3 Availability sets are created and each set of 2 VM’s is added to an Availability Set
- A load balancer including the configuration to load balance RD Web Access & RD Gateway
- A public IP address for external access or RD Web Access & RD Gateway
- An Azure SQL Server
- An SQL Server database for the RD Connection Broker Role
- An RDS Deployment with all the RDS roles added to that deployment
- RD Connection Broker is configured as HA and the database is placed on Azure SQL
- The entire template leverages Azure Key Vault
As mentioned before you can trigger ARM to start building the resources you defined in your JSON Template directly from Visual Studio. To do so, select the Deploy option and provide the parameters to connect to the correct subscription and Resource Group.
Basically what Visual Studio does is launch the PowerShell command to initiate ARM to process your JSON template. This means that you can also use PowerShell yourself to initiate ARM by running the script Deploy-AzureResourceGroup.ps1. However, you can track the deployment directly from Visual Studio as well because Visual Studio polls the ARM deployment and shows you the status changes! Below you see the first 2 minutes of the deployment where availability sets, NICs, Virtual Machines etc. are starting to be created.
Upon completing, and again this only takes < 30 minutes, refreshing the Resource group in the Azure Portal shows the created deployment
After opening Server Manager, we can see that an entire HA deployment of RDS has been deployed and is accessible from the outside as well!
Obviously ARM on it’s own can only deploy resources and configurations in Azure itself. So how does ARM add those servers to the domain, deploy the roles and perform the RDS deployment within the machines itself? For this to work, custom extensions are needed inside your JSON template. By using extensions, you can push DSC configurations to the deployed servers to perform actions inside the machines. And you can also use extensions to launch PowerShell scripts inside the Virtual Machines. In my case I’m using custom extensions to have DSC add the servers to the domain and launch various custom extensions to run PowerShell scripts to perform the RDS deployment, perform HA settings etc. A very powerful combination! I’m planning to dive a little deeper into the specifics of custom extensions in an upcoming blog post.
What’s also great about JSON Templates is that you can define parameter files. So I could run the exact same JSON Template against to 2 different Azure Subscriptions and use 2 separate parameter files to define specific settings for those 2 subscriptions. To give you an example, using the parameter file below I’m defining that I’m using Server 2016 (TP5) as the Server SKU. If I wanted the entire deployment to run Server 2012 R2, I would only have to change that single parameter here. And also, I define the credentials that my SQL Server uses inside the template file. Obviously not in plain text, but by using Azure Key Vault to store & retrieve credentials safely. General advice; use Azure Key Vault when dealing with passwords in ARM deployments!
Azure Resource Manager fundamentally changes any deployment on Azure! As far as I’m concerned, ARM should be the standard for any Azure deployment going forward! For this example, it helped to create an entire Remote Desktop Services deployment in less than half an hour! The JSON Template used also becomes your documentation, it specifies exactly how the deployment was performed, and allows standardization to the max!
Some additions that I’ve already planned for this JSON template are:
- Add the creation of a parametrized RemoteApp Collection
- Configure Deployment properties like SSL certificates & RD Licensing
- Configure specific collection settings like i.e. session timeouts, redirection options etc.
- Automate the creation of GPO’s to perform lockdown of the RDS environment
- Provide the option to use a custom template image for the RDSH environment
Wednesday, August 17, 2016
Remote Credential Guard, introduced with Windows 10 version 1607 allows to you protect your credentials over a Remote Desktop connection towards a domain joined server or client.
This is designed for scenarios where both client & server are joined to the same domain or a trust relationship between the domains must exist.
Scenarios as defined by Microsoft:
- Administrator credentials are highly privileged and must be protected. By using Remote Credential Guard to connect, you can be assured that your credentials are not passed over the network to the target device.
- Helpdesk employees in your organization must connect to domain-joined devices that could be compromised. With Remote Credential Guard, the helpdesk employee can use RDP to connect to the target device without compromising their credentials to malware.
It can be enabled on the client by configuring the GPO setting Restrict delegation of credentials to remote servers to Require Remote Credential Guard located in Configuration -> Administrative Templates -> System -> Credentials Delegation.
If you don’t use GPO (but seriously who doesn't) you can use the new switch of the mstsc command by running mstsc.exe /remoteGuard.
Source & more details: https://technet.microsoft.com/en-us/itpro/windows/keep-secure/remote-credential-guard
Friday, August 12, 2016
Azure RemoteApp is being deprecated, Microsoft partnering up with Citrix to create the next iteration on Azure in spirit of Azure RemoteApp!
In Q2 of 2014 Microsoft launched the Azure RemoteApp service, a turnkey solution that allowed publishing traditional Windows applications in the Cloud without having to setup a complex RDS backend infrastructure. The idea had great potential and initially Microsoft had an impressive fast continuous update cycle for the service. Many improvements and features were added in the one and a half years that followed.
The last 6 months however it became clear that Microsoft’s focus changed. Updates to the service on the public roadmap were being pushed forward and features that everyone was waiting for like e.g. Azure Resource Manager and user specific targeting unfortunately never even made it.
At previous conferences this year in May (BriForum London) and in June (E2EVC in Dublin) Benny Tritsch and I presented a session on Azure RemoteApp. That session was called “Azure RemoteApp – Past, Present & future”, the more important subtitle however was “Let’s talk ARA Use Cases”. During these sessions we covered the best practices, current limitations and pitfalls you need to be aware. Basically we tried to answer the question “What does it really mean to take an Azure RemoteApp Collection into production?”. Our conclusion in those sessions was that Azure RemoteApp could work in smaller use cases and we explained why we believed Azure RemoteApp was not enterprise ready. Download the full slide deck here: Azure RemoteApp Past, Present & Future – Slide Deck
Other news in this area was the announcement that Brad Anderson (Microsoft Corporate VP) and Bill Burley (Citrix Corporate VP and GM) made at Synergy in May of this year. Together Microsoft and Citrix announced the commitment of building a new Service to run XenApp and XenDesktop dedicated on Azure.
It became clear that Microsoft had tightened their existing partnership with Citrix creating a platform to host RemoteApps & Desktop on Azure using Citrix Technology. In the same announcement Citrix also confirmed Azure will be their preferred Cloud. As much as I liked the Azure RemoteApp concept, again it had great potential, it does make sense to join forces with Citrix and have them create the next iteration in the spirit of Azure RemoteApp. The decision also aligns with Microsoft’s strategy to position RDS as a platform going forward. Citrix will develop their solution in spirit of Azure RemoteApp, combining the simplicity of Azure RemoteApp the scalability of Azure with the enterprise-ready capabilities of Citrix XenApp.
Looking at migration options away from Azure RemoteApp, there are basically 3 options;
- The new Citrix solution on Azure (although GA is not expected before Q1 of 2017)
- RDS Deployed on Azure IaaS
- Hosted RDS solutions in private clouds and data centers
For Microsoft this will also mean a stronger focus on the RDS protocol and optimizing even more to run on various cloud solutions with Azure IaaS obviously being the most important one.
Again, it’s sad to see Azure RemoteApp go, but I really think Microsoft and Citrix made a good strategic move and I’m sure we’ll see many of the good things of Azure RemoteApp in the Next iteration Citrix will build for Azure.
If you have any questions on the deprecation, the implications or the ways to migrate to the platforms described above, feel free to reach out to me.
Interesting times in our industry ahead!
Link to the official Microsoft Statement: https://blogs.technet.microsoft.com/enterprisemobility/2016/08/12/application-remoting-and-the-cloud/
Link to the official Citrix Statement: https://www.citrix.com/blogs/?p=174224925