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
Thursday, June 30, 2016
Two weeks ago, the 30th edition of the Experts 2 Experts Virtualization Conference (E2EVC) took place in Leopardstown, Dublin. A great community driven conference, founded by Alex Cooper. If you’re not familiar with the event check out e2evc.com for more details.
Last month BriForum 2016 Europe took place in London. Also a great, vendor independent conference founded by Brian Madden. For more information on that event check out briforum.com.
Over the past 2 weeks we have received a lot of requests from people who were not able to attend these conferences, asking if we we’re going to share our slide deck. Although about half of our session was a live demo, we would like to share the contents of the deck and elaborate some more on the key areas of our sessions …
Continue reading here: http://www.rdsgurus.com/uncategorized/lets-talk-azure-remoteapp-use-cases/
Wednesday, June 15, 2016
Last week the 30th edition of the Experts 2 Experts Virtualization Conference (E2EVC) took place in Leopardstown, Dublin and was named the EPIC edition. This event is founded and hosted by Alex Cooper and his crew. If you’re not familiar with the event check out e2evc.com for more details. In many ways this is not your average IT event. To give you an idea, E2EVC was previously called PubForum :)! Alex does a great job in making this a great experience for everyone, short session time slots allow for many speakers to present their topics and E2EVC also arranges fun evening activities.
At this year’s Dublin 2016 edition I presented a session on Azure RemoteApp together with fellow RDS MVP Benny Tritsch. Our session was called “Azure RemoteApp – Past, Present & future”, the more important subtitle however was “Let’s talk ARA Use Cases!”. For this session we decided to not only present all of the awesome stuff of Azure RemoteApp but also cover the current limitations and pitfalls you need to be aware of when taking an Azure RemoteApp environment into production. We covered several real-life use cases based on our own experience and presented what we had learned from these projects. Based on these use cases we educated the audience on scenarios that are suited for Azure RemoteApp and also scenarios that are not suited or very challenging.
Because of our approach, the session became very interactive and we received many great questions! The session was very well received, we had a great time and after the session we received great feedback in person as well as on twitter.
Thanks to everyone who attended our session, we appreciate the interaction, questions and feedback! I would like to thank Alex Cooper & crew for hosting yet another great edition of the E2EVC event and also congratulate them with this 30th edition! (@PinkVegasMonkey also joined us in Dublin, be sure to follow him on twitter )
If you have questions on Azure RemoteApp or if you need assistance with a design, PoC or implementation, feel free to reach out to either Benny or me and also be sure to check out rdsgurus.com.
Monday, June 13, 2016
You may have read my previous blog post about the announcement of new PowerShell CmdLets to manage User Profile Disks (UPD )in Azure RemoteApp, if not here is the link: User Profile Disk management for Azure RemoteApp is here!
These new CmdLets enable you to manage the User Profile Disks yourself. This is great because prior to this you had to contact Azure Support for every management task you had to do related to UPD. Check out my previous blog post for more details on the new CmdLets Copy-AzureRemoteAppUserDisk and Remove-AzureRemoteAppUserDisk.
One of the things I did run into when testing, is that the Remove-AzureRemoteAppUserDisk CmdLet does not check if the user associated with the UPD is active or not! So please be aware of this when using this command.
This is what happens when you accidentally run the command without checking if the user is active or not. The UPD is removed successfully and the user ends up with unexpected behavior in his session when trying to access application that try to contact the users profile. Basically the session becomes unreliable. Highlighted in green is the Remove-AzureRemoteAppUserDisk CmdLet that runs successfully while the user session (on the right) is active. Highlighted in red are some confirms that User Profile Disk is gone.
I have reported this back to the Product Team, and they are planning to have this fixed. In the meantime, be sure to confirm that the associated user is logged off prior to deleting the UPD.
Here are 2 ways to tell what users are logged on;
1. Using PowerShell and run the following command
Get-AzureRemoteAppVM -CollectionName <name of the collection>
For example below you will see that the user rdstest is currently logged on (and jwbqpqto000t is the hostname of the RDSH server)
Tuesday, June 7, 2016
Two new great PowerShell commands are added to Azure RemoteApp! They allow for management of the User Profile Disk (UPD)! This is a very welcome update! Why? Previously, when you wanted to perform management on the UPD’s of an Azure RemoteApp collection you could not do that yourself. Instead you needed to contact Azure Support. With the new command that are you released you can manage UPD’s yourself! In order to use the two new commands, make sure you downloaded the latest version of Azure PowerShell.
Guide to check what Azure PowerShell current version you are running and how to access the latest version:
What are the two new commands?
Using this command you can copy a User Profile Disk, which was previously bound to a single Azure RemoteApp collection, from one collection to another! This is great and opens new possibilities for scenario’s where a specific user was added to a specific collection for example because of a specific application set that was published there and now needs to be moved Or, you can now move a UPD from for example a staging collection to a production collection! Awesome!
Copy-AzureRemoteAppUserDisk [-SourceCollectionName] <string> [-DestinationCollectionName] <string> [-UserUpn] <string> [-OverwriteExistingUserDisk] [<CommonParameters>]
Here is the command in action where I moved the UPD for firstname.lastname@example.org from collection hybrid to server2016tp5 (yes I tested a collection based Server 2016 Technical Preview, and no, that is not officially supported yet :).
If you try to copy an UPD to a collection where an UPD for that user already exists, the command is safely ignored and the UPD in the destination collection is not overwritten, which is good!
In order to overwrite it, simple remove the UPD in the destination collection first, for that see the command below.
This basically does what it says. Using this command, we can remove the User Profile Disk for a specific user in a specific collection. Consider a scenario where a User Profile Disk got corrupted for whatever reason, or you simply want to allow a user to start building a new profile from scratch. This is now possible!
Remove-AzureRemoteAppUserDisk [-CollectionName] <string> [-UserUpn] <string> [<CommonParameters>]
Here is the command in action when I removed the UPD for email@example.com
The command asks you to confirm by default which you can obviously overwrite if you wanted to.
After logging on with the user a new UPD will be created, you can notice this because the initial logon will take a little longer (because of the creation of the UPD) and all profile settings are set to default, you call tell by for example opening Internet Explorer as shown below.
These two new commands are a great new edition to the PowerShell Cmdlets for Azure RemoteApp!