The entire session is now available on demand and I can encourage anyone to check out this session: https://myignite.microsoft.com/videos/2793
I also uploaded the two short demo videos of my ARM/JSON section so you can view them separately here:
PART1
This part demo’s the status of the Azure Portal Prior to kicking of the ARM/JSON deployment, it then kicks of the deployments and shows parts of the result inside Visual Studio.
PART2
This part demo’s the end result of the ARM/JSON deployment. It shows the end result inside Visual Studio as well the end results in both RD Web Access and Server Manager
For more information on these JSON templates also see these two previous posts:
- Full HA RDS 2016 deployment in Azure IaaS in < 30 minutes, Azure Resource Manager FTW!
- RDS on Azure IaaS using ARM & JSON part 2 – demo at Microsoft Ignite!
I’m planning to extend the JSON template to allow even further customization of the RDS environment and will share my progress here.
Monday, October 3, 2016
Video of Ignite session showing RDS on Azure IaaS deployment using ARM/JSON now online!
Friday, September 30, 2016
Remote Desktop Services in Windows Server 2016 - planning poster!
How cool is this? The Remote Desktop Services team have created a poster on RDS in Windows Server 2016!
Download URL: http://aka.ms/rdposter
RDS on Windows Server 2016 - documentation updates
Some examples (source: rdsgurus.com/../new-documentation.)
Upgrade your RDS deployment to Windows Server 2016.
Deploy a Storage Spaces Direct scale-out file server for UPD storage in Azure
Deploy a Remote Desktop Connection Broker cluster
Desktop hosting logical architecture
Understanding the desktop hosting environment
Azure services and considerations for desktop hosting
For more articles visit https://technet.microsoft.com/en-us/windows-server-docs/compute/remote-desktop-services/host-desktops-and-apps-in-remote-desktop-services
As we’ve heard earlier this week, Windows Server 2016 is now RTM, the evaluation version is available for download and we can expect it to hit general availability half October. Exciting times are ahead of us!
Wednesday, September 28, 2016
RDS on Azure IaaS using ARM & JSON part 2 – demo at Microsoft Ignite!
In one of my previous blog posts I described performing an entire High Available RDS deployment in Azure IaaS using Azure Resource Manager (ARM) and JSON. In that blog post I described the differences between deployment mechanisms in the classic Azure Portal and the new Azure Portal. I 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. Also see Full HA RDS 2016 deployment in Azure IaaS in < 30 minutes, Azure Resource Manager FTW! In the mean time I have been expanding and improving this JSON deployment.
During the Microsoft Ignite event on September 30, fellow RDS MVP Benny Tritsch will be presenting a session called Get an independent insider’s view of desktop virtualization and session remoting. In this session he will also be showing some of my results of this deployment. If you are at Ignite be sure to join this session, it contains a lot of awesome content coming from various community members! The recording of the session will also become available online.
A few examples of what I have been adding to the deployment:
- I’ve added the ability to configure SSL for all of the RDS roles based on either self-signed certificates or publically trusted certificates. The deployment takes care of configuring SSL for all of the roles to allow for a smooth user experience when accessing the environment using public DNS names.
- As part of the deployment 2 Session Collections are created, based on provided parameters and a few example RemoteApps are also published to get immediately get started with the environment.
- The deployment now also allows you to configure various session timeout settings to further customize the session collections.
- The deployment now creates 2 separate storage accounts and spreads the High available RDS roles across these storage accounts to be fully compliant with High availability common practices in Azure IaaS.
In an upcoming blog post I’ll spend some more time on other features like User Profile Disk, RDSH Custom Images, RD Licensing and possibly other features!
Friday, September 23, 2016
Microsoft Mechanics video on RDS for Windows Server 2016
Microsoft has released a Mechanics video on Remote Desktop Services in Windows Server 2016.
”…We are getting close to the launch of RDS in Windows Server 2016!
As a preview to the great new capabilities coming in the latest update of your trusted desktop and app virtualization platform, we have released a new MS Mechanics video showcasing some of our greatest innovations in this release. Scott Manchester, Principal Group Program Manager on the Remote Desktop Services team, and our tech evangelist Simon May talk about and demonstrate the powerful new innovations in RDS for Windows Server 2016 across three key areas…”
Source en more information: https://blogs.technet.microsoft.com/enterprisemobility/2016/09/22/new-ms-mechanics-video-with-the-latest-updates-to-rds-for-windows-server-2016/
Thursday, September 15, 2016
New default RD Gateway Resource Authorization Policies in Windows Server 2016
Remote Desktop Services is referred to by Microsoft as one of the “top 10” capability of the Windows Server 2016 release that is going to reach General Availability within a few weeks. Also see this blog post and video Ten reasons you’ll love Windows Server 2016 #4: Remote Desktop Services. The three key pillars of improvement are shown in the diagram below.
While test driving the Technology Preview 5 version I ran into a small new feature as part of the process of adding an RD Gateway server to a Remote Desktop Services Deployment using RDMS.
Since Windows Server 2012, Server Manager can be used to perform scenario based deployments of Remote Desktop Services. As part of this scenario based deployment, an RDS deployment is created consisting of an RD Connection Broker, RD Web Access and RD Session Host. This confirmation of what is created using the wizard is shown below.
After this initial deployment we are able to add additional servers and also add the RD Gateway role.
As part of the process of adding an RD Gateway server to a 2012 R2 deployment, two default policies are also added to the RD Gateway.
- A default Connection Authorization Policy (CAP) is added that simply allows access to the RD Gateway for the group Domain Users. This is to make sure that you can start using RD Gateway immediately, however in production environments I advise to modify this CAP to only allow access by a specific (Active Directory) group of users. This is not changed with Windows Server 2016.
- A default Resource Authorization Policy (RAP) is added that allows access through RD Gateway towards all computer objects of the domain (via the Domain Computers group). Again, this is added to allow easy setup and in production environments I advise to modify this RAP to only allow access to specific resources of your RDS deployment. Below is what this default RAP looks like.
Starting from Windows Server 2012, the RD Connection Broker became the default initial connection hander. This means that any user connecting to an RDS Deployment always makes an RDP connection to the RD Connection Broker first. The RD Connection Broker decides what’s the best RD Session Host to connect to, resulting in a second RDP connection from user to that RD Session Host server. Although this process is completely transparent for the end user, it does mean that the user must be able to access the RD Connection Broker via RDP. For RD Gateway usage, this means that the RD Connection Brokers must be added to the RD RAP as a resource.
The above scenario is where in the future, RDS on Windows Server 2016 helps out. We do the same scenario based deployment of RDS in Windows Server 2016 (TP5), as shown below.
And adding a RD Gateway server to this deployment the same way.
The deployments now adds an additional RD RAP out of the box called RDG_RDConnectionBrokers
This RD RAP provides access to an RD Gateway Managed Group of computers (called RDG_RDCBComputers) which is populated with the RD Connection Broker Server that is part of your deployment.
This is very helpful because adding the RD Connection Broker to the RD RAP, after removing / changing the RDG_AllDomainComputers RAP, is a task I see commonly forgotten in several environments.
But what about scenario’s where the RD Connection Broker is in High Availability (HA) mode or scenario’s with a single RD Connection Broker where the broker FQDN name was changed by using the Set-RDPublishedName.ps1 In those cases it’s even more tricky because the broker FQDN is not a member of the Domain Computers group, it’s not even a Kerberos object in AD.
When adding an RD Gateway to an RDS 2016 deployment where HA in in place, the wizard also takes case of this. In those case an additional RD RAP (RDG_HighAvailabilityBroker_DNS_RR) is added that provides access to an RD Gateway Managed group called RDG_DNSRoundRobin that holds the RD Connection Broker FQDN as shown below.
This matches the RD Connection Broker HA FQDN as configured in RDMS.
It’s a relatively small addition to the scenario based deployment of RDS on Windows Server 2016, but very helpful to provide smoother setup of the RD Gateway role in such environments.
Windows Server 2016 will hit General Availability during Microsoft Ignite in less than two weeks. I’m looking forward to the launch!
Thursday, August 18, 2016
Full HA RDS 2016 deployment in Azure IaaS in < 30 minutes, Azure Resource Manager FTW!
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?
You can feed ARM by something that is called a JSON (JavaScript Object Notation) template. JSON is a syntax for storing and exchanging data in lightweight data-interchange format and an easier-to-use alternative to XML. Basically you create a JSON template with the Azure objects you want to have created, provide that to ARM and ARM will provision everything for you in the most optimal way. The end result is an x amount of Azure Objects grouped together in an Azure Resource Group.
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!
Conclusion
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
- …