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:

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.clip_image004

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.clip_image010

And adding a RD Gateway server to this deployment the same way.clip_image012

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.clip_image020

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!

More information on RDS on Azure IaaS
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 Recently they have also updated this for Windows Server 2016 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 ( 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, ( 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.clip_image006

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 Portalclip_image009

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.clip_image011

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.clip_image013

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!clip_image016

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

Using Remote Credential Guard to Protect Remote Desktop credentials

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.image

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:

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!

The news is officially out; Azure RemoteApp is being deprecated!

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

The timeline for the deprecation is as follows;
-          Public announcement                today
Microsoft will allow no new trials and existing trial collections can be converted to paid
collections within 30 days. Inactive trials will also be ended today.

-          End of Sale                                   10/1/2016
No new Azure RemoteApp deployments for Enterprise Agreements, Comsumption SKU’s will still
be possible.

-          Deprecation                                 8/31/2017
All usage of Azure RemoteApp ends

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:
Link to the official Citrix Statement:

Thursday, June 30, 2016

Let’s talk Azure RemoteApp use cases!

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 for more details.

3Last 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

5Over 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:

Wednesday, June 15, 2016

Azure RemoteApp session at E2EVC Dublin 2016 (the EPIC edition)

imageLast 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 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.

imageAt 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.

imageBecause 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 )

imageIf 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