Tuesday, July 14, 2015

RDS Deployment template available in Azure Resource Manager!

The RDS team did a great blog post on using the RDS Deployment template for Azure Resource Manager. Azure Resource Manager enables you to work with the resources joined as a group and allows you to deploy, update or delete all of the resources for your purpose in a single, coordinated operation. Using a Azure Resource Manager Template you can very easily setup a environment (in this case RDS) and deploy that as a group of resources. Azure Resource Manager is the Management API layer for the future Microsoft Cloud!

I took the RDS template for a test-drive, the result was pretty impressive. A full RDS deployment up & running!

This is what the template creates for you:

  • VNET
  • New storage account
  • Public IP resource
  • Load Balancer resource, including the correct ports opened 
  • VM for Active Directory and DNS server roles
  • VM for RD Gateway and RD Web Access server roles
  • VM for RD Connection Broker and RDS License server roles
  • VMs for RD Session Host (RDSH) servers.
  • A Basic ADDS deployment
  • A RDS Full Desktop Deployment, incl. RD Gateway, Licensing etc.


After the Azure Resource Manager template deployment finishes, you end up with a working RDS deployment, accessible from the outside, ready to do testing for a POC, testing customizations etc.


The only thing not configured is obviously SSL certificates. Which means you will end up with a self signed certificate. This can however be changes easily by providing the SSL certificate in the RDMS on the RD Connection Broker server.

Obviously this is not production ready, but what’s also cool about Azure Resource Manager Templates in general is that you can create your customized template, for example basing it on the one for RDS that’s being provided and start building your own template.


To open the template directly from you subscription click the icon below.


More information on the RDS template here: http://azure.microsoft.com/en-us/documentation/templates/rds-deployment/ 

Link to the RDS Team blog article: http://blogs.msdn.com/b/rds/archive/2015/07/13/azure-resource-manager-template-for-rds-deployment.aspx?utm_source=dlvr.it&utm_medium=linkedin

More overall information on Azure Resource manager:

Thursday, July 9, 2015

Adding Conditional Access & MFA to Azure RemoteApp

(Originally posted on rdgurus.com)

Because the Azure RemoteApp client authenticates against Azure Active Directory (AAD) we are also able to leverage Conditional Access and Multi Factor Authentication (MFA) based on AAD. The RDS Product team also recently announced this in the blog post Control access to Azure RemoteApp with Azure AD Conditional Access!

In this blog post I’ll guide you through the process of setting up MFA on Azure RemoteApp.

First of all, Conditional access requires Azure AD Premium (currently in preview). You can however set this up in a 30 day trial. To do that, open the Azure Portal browse to your AAD and choose the option “TRY AZURE ACTIVE DIRECTORY PREMIUM NOW”


Confirm the agreement belowimage

It take a few minutes to setup. Click the refresh link to be able to start using it.


Shortly followed by that, you should receive a confirmation email that the organization is ready for Azure AD Premium.


To configure MFA, reopen the Azure Portal, go to Active Directory open your AAD domain en choose Applications.


Now click on Microsoft Azure RemoteApp and go to the Configure tab. For this demo, we’ll select Enabled Access Rules, have it applied to all users, and select Require multi-factor authentication.


The next time we log on to the Azure RemoteApp client with an organization account from this AAD, we are presented with the following;


This is MFA kicking in. We click “Set it up now”. And without having to leave the Azure RemoteApp client, we’re being presented the ability to provide a phone number and verification type that we would like to use for this account. In this case I choose Phone Authentication, and provide my cell number. (we obviously only have to perform these steps once).


When we click Contact me, Azure MFA will call me on the number provided to verify the correct number.


The verification process is now completed and we are ready to use MFA for Azure RemoteApp.


When proceeding the logon in the Azure RemoteApp client we’re presented with the following screen indicating that we can expect a call to our provided phone number to perform the MFA !


And after that, we’re presented with the RemoteApps assigned to us based on the Azure RemoteApp Collection.


There are some other options in conditional Access policy worth mentioning. We can for example specify to only enforce MFA when people are connecting from outside of the corporate (trusted) locations, or even block access in those cases.


By clicking the link, we’re able to configure these trusted locations, configure whether or not we want to allow app passwords and even allow users to suspend multi factor authentication from remembered devices.


This blog post was originally posted here:

Thursday, June 25, 2015

On the roadmap: Assigning specific applications to specific users in Azure RemoteApp

imageOne of the current limitations to Azure RemoteApp compared to a RemoteApp deployment on premises is not having the ability to assign specific RemoteApps to specific uses (fine grained assigning). If a user is a added to a App collection he will see all the applications published to that Collection. This can be confusing to users because they will generally see more applications in the Azure RemoteApp client than the use, and there will most likely also be applications that they are not even authorized to start. Although seeing the application in the Remoteapp client does not mean that can start, it’s still a current limitation you need to be aware of.

The good news? Adding this functionality is now on the road map! It’s on the roadmap for the July-September 2015 iteration! As RDS MVP’s we have been providing feedback on this and discussing this a lot with the product team, and it’s also a heavily voted request on the user voice page for Azure RemoteApp!

Looking forward to this feature, this will definitely drive adoption to Azure RemoteApp! Another big step in the continuous development.

Wednesday, June 24, 2015

Azure RemoteApp Client Single Sign On using Azure Active Directory (AAD) and Windows 10

As you might know there currently is no Single Sign On towards the Azure RemoteApp client, based ion locally logged on credentials. When you install and open the Azure RemoteApp client you will be presented with the dialog below. This is an authentication against Azure Active Directory (Azure AD) and based on these credentials the Azure RemoteApp client will retrieve the RemoteApps that have been assigned to you.


Currently into preview in Azure AD is the option to allow users to Azure AD join their devices. If you enable this option, users can join a device to Azure AD and log on to that device using their Azure AD account (which is optionally synced from on premises AD).


To configure this on the Windows 10 client, (this option is only available on Windows 10 you go to Settings and then About. These you click Join Azure AD.


You specify the domain name of your Azure AD. In this case rdsgurus.com


You acknowledge the enrolment and click continue.


Next, specify the account you want to use to join this device. This account obviously has to exist in Azure AD. And this is the account that has been added to the Azure RemoteApp collection, configured in the same Azure AD domain.


Confirm this is the correct organization and click Join.


And that’s it. The Windows 10 device is now joined to your Azure AD.


We can confirm this by going to the AAD in the Azure Portal, browsing to the user and opening the devices tab. Here we’ll see an overview of all the devices that this user joined to AAD.


We’re now able to log on to the device using the corporate (AAD) account.


When opening the Azure RemoteApp client and clicking Get Started, the client automatically signs in with the Azure AD account that is used to log on to the local device!


Obviously, there still is the current limitation to Hybrid scenario’s of Azure RemoteApp where at this point there is no full Single Sign On experience towards actual RemoteApp. This means you will be prompted when opening the 1st RemoteApp (with the option to save those credentials to your local credential store). This is in on roadmap to fix.

But with this experiment, with Windows 10 as an AAD joined device, there is already one authentication prompt less! Now all we need to do is wait for Win10 to go GA! :)

Thursday, June 18, 2015

Managing your Azure RemoteApp application landscape using FSLogix Apps.


Microsoft Azure RemoteApp is all about delivering your Win32 ‘legacy applications’ from the cloud to any device, any location at any time. While RemoteApp technology itself is not new and has been shipping since Windows Server 2008, Azure, however, makes it a truly turnkey, and as a Service, solution. Basically you bring your applications and your identities, and Azure RemoteApp provides you with a GUI inside the Azure Portal to configure the delivery of those applications, including PowerShell support.
Currently you provide your custom application landscape by installing all your applications in a RD Session Host Template image. There are 2 ways to provide that Custom Template to Azure. First, you can create the image on premises and upload it entirely to Azure. Depending on you upload bandwidth and the size of your image, this can be a very time consuming task. My advice would be to use the latest option, which is creating the RD Session Host Template image in Azure IaaS. Azure Provides an IaaS template that is already prepared and optimized for Azure RemoteApp, and this saves you from having to upload an entire image for every application update you do. Microsoft providing a more containerized solution to provide custom applications to Azure RemoteApp, seems like the next future step.
Since we provide a single RD Session Host image for each Application Collection in Azure, every user will be presented with a session on a RD Session Host server based on the same image, including the same application landscape. Some of the challenges with this approach;

- Ensuring application license compliance, for example you may not have purchased a Visio License for every user

- A more granular control to for example Office add-ins, browser plugins, fonts et cetera

- Simply fully hiding an application based on authorization, rather than just preventing access 

Although you can go ahead and create lockdown policies to prevent access to certain applications leveraging for example AppLocker, this can be time consuming task. And also, out of the box Microsoft technologies like AppLocker deny access, resulting in error messages when a user tries to access them.
It should be no surprise that there are many 3rd party solutions out there that do application layering, application containerization, application virtualization etc.
In this blog post I’m describing my experience in adding FSLogix Apps to control the application landscape of Azure RemoteApp. If you’re not familiar with FSLogix Apps;
…FSLogix Apps is a software agent that enables virtual desktop administrators to massively reduce the number of Windows Gold images, easily manage per-user applications, optimize license costs while assuring compliance, and eliminate some of their biggest problems in VDI and RDSH…”
I’m describing three common scenarios which I tested where FSLogix adds real value to (Azure) RemoteApp.
But first let’s briefly cover some basic steps in Azure RemoteApp and cover the installation of FSLogix.


At this point I’m assuming a new VM is provisioned in Azure IaaS, based on the Windows Server Remote Desktop Session Host template in Azure. For a complete description on that see Now publicly available: Creating Azure RemoteApp templates using Azure IaaS!


After logging on the created VM in Azure I have installed several applications to be able to test drive FSLogix Apps. In this case I have installed

Microsoft Office 2013
Microsoft Visio 2013
Microsoft CRM 4.0 Outlook plugin
Java version 6u45
Java version 8u45 


FSLogix is known for its unique, extremely small footprint in their area. Basically the only thing you need is an agent on the RD Session Host and XML files to instantly configure your desired settings. The installation of the agent is literally 3 dialogs.



After the installation of the agent, you install the Rule Editors that allow for easy creation of the configuration files.


This is a common scenario where you install the CRM Outlook plugin on a RD Session Host but would like to have it be only available to certain users. Ultimately, making it fully invisible to others. To do this we open up the FSLogix Apps RuleEditor and create a new Rule and provide the name ‘Dynamics CRM 2015 for Microsoft Outlook’.
We then select ‘Microsoft Dynamics CRM 2015 for Microsoft Outlook’ from the installed programs that the editor discovered and click scan.
The editor will now scan folders, registry et cetera and create hiding rules for you. After that you can, if needed, add, remove or modify any rule.
At this point you can test the rule using the logged on user to instantly see the result and test the experience prior to assigning it specific users.
The next step is to assign the CRM Outlook plugin to specific users. You can do this be either applying the hiding to a specific user or group, or not apply it to a specific user or group. In this case I will set it to not apply to the GG_CRM_Outlook_Users group. But this can basically be any local or Active Directory User, Group or even a specific a process, network location, or Organizational Unit.
Note that since this a RD Session Host template, it’s not yet joined to the domain, we can however still enter the desired group name and domain, we just need to make sure that the naming is 100% correct, since the group name is obviously not checked at this point.
At this point the rule editor has created the necessary xml configuration files, by default in C:\Users\<username>\Documents\FSLogix Rule Sets but you can have them created anywhere you want.
The final step is to simply copy these files to the location where the FSLogix agent actively scans for new or updates configuration files. By default this is C:\Program Files\FSLogix\Apps\Rules.
The copy action itself can be done any way you want. You can manually copy the files in the Azure RemoteApp RD Session Host template prior to using it for Azure RemoteApp, however, the most flexible way would probably be to place the configuration files using a Computer GPO.
Because a Hybrid Deployment of Azure RemoteApp actually results in your RD Session Host servers being added to your (on-premises) Active Directory you can leverage GPO and create a copy action like below. Or optionally use any other management solution you’re currently using. Below is an example of such a GPO File Preference, in this case I’ve created two GPO File Preferences to copy both the .fxa and the .fxr file.


In order to be able to use this RD Session Host template as a template image for Azure RemoteApp we need to sysprep it. Because we’re using the optimized Azure RemoteApp template image in IaaS, we can perform this action by running the ValidateRemoteAppImage.ps1 script that is being placed on the desktop.
After the VM is shutdown, we capture it to be able to select it later on in the Azure RemoteApp Collection.


In this case I’m reusing a Azure RemoteApp collection which I created previously, and within that collection a select the newly created template image including the FSLogix agent.


After the Azure RemoteApp collection has been updated with the latest image, we’re ready to test. First lets log on with a user (rdstest84) who is a member of the GG_CRM_Outlook_Users group.
When we launch Outlook as a RemoteApp as this user, the CRM plugin dialog pops up that allows the user to further configure the plug in.
And Outlook is opened notice that the Microsoft Dynamic CRM plug in available in the Add-Ins dialog.
Now let’s perform the exact same steps using a user (rdstest83@rdsgurus.com) who is not a member of the group GG_CRM_Outlook_Users. When we open Outlook as a Azure RemoteApp, we are not prompted with the CRM plugin dialog, and when taking a look at the Add-Ins tab, the Microsoft Dynamic CRM plug in is completely invisible to the user.
This is great because we can now deliver Outlook with and without the Dynamic CRM Outlook plugin using the same RD Session Host Template image without having to virtualize or package any application, these applications all run on the base OS.


This example is also a very common use case I see a lot. Although you as an admin might not be concerned that everyone has access Microsoft Visio (or any other application) if you’re responsible for ensuring application license compliance, you are! In this scenario we will only allow access to Microsoft Visio for a specific group of users (GG_Viso2013_Users).
To do this we open up the FSLogix Apps RuleEditor and create a new Rule, similar to way we performed this in example 1, and provide the name ‘Dynamics CRM 2015 for Microsoft Outlook’. We then select the application ‘Microsoft Visio Professional 2013’ en click scan.
Similar as in example 1, the editor will now scan folders, registry et cetera and create hiding rules for you. After that, you can, if add, remove or modify any rules as needed. For Visio I had to remove some path and registry items that the scan picked up that were not Visio specific but rather Microsoft Office general.
The next step is to assign the CRM Outlook plugin to specific users. You can do this be either applying the hiding to a specific user or group, or not apply it to a specific user or group. In this case I will set it to not apply to the GG_Viso2013_Users group.
Again I’ve created two GPO File Preferences to copy both the .fxa and the .fxr file, but you can use any desired method to get the files in folder that is scanned by the FSLogix Agent.


After the two files have been copied by the GPO, we’re ready to test. First lets log on with a user (rdstest84) who is a member of the GG_CRM_Visio_Users group. With this user we are able to Launch Visio as a Azure RemoteApp. Also, we can see Visio as a installed program when we open up the control panel as this user.
Now let’s perform the exact same steps using a user (rdstest83@rdsgurus.com) who is not a member of the group GG_CRM_Visio_Users. When we try to open Visio as a RemoteApp the system won’t us, and we’re presented with the following error.
And also, we open Control Panel as this user and take a look at the installed programs, Microsoft Visio is not there.
This mean that FXLogix not only denied access to Visio, but complete hides Microsoft Visio for the user, which is great because this makes it very transparent.
There is one caveat there which is related to Azure RemoteApp rather than FSLogix. Currently Azure RemoteApp does not support fine grained assigning of RemoteApps. This means that every user who has access to a App Collection will see every application within that collection. In case of this scenario, using FSLogix we’ve completely hidden Visio for users who are not a member of the specified group. They do not see references to Visio anywhere…except for the Azure RemoteApp client. Since we currently cannot show RemoteApps based on for example group membership Visio will still show up there, although the user is unable to launch it. Hopefully this is something that Microsoft will change in the future. But despite this caveat, FSLogix is able to fully block any access to Visio which means we’re ensuring application license compliance.


Another common example is Java. Many Line of Business (Web) Applications require java to be installed. As an administrator, ultimately you would want a single Java runtime, updated to the latest version. Unfortunately, the reality is different, since not every web application fully works with the latest version of Java. FSLogix offers functionality that allow you to run the latest runtime of Java and make an exception for a specific (web) application, based on the URL, and only allow that URL to use a specified older version on Java.
To demonstrate this I’ve installed 2 versions of Java in the RD Session Host template used by Azure RemoteApp. Java 8 Update 45 and Java 6 Update 45.
To be able to make the exception for a specific URL, we use the FSLogix Java Rule Editor. The interface is again really simple. We create a new Java rule with the type set to URL. We then specify the specific URL we want to run using an older version of Java. For this demo I actually specified the java.com website, because the java.com website contains an option to show the java version that is used. That allows me to confirm the exception. Upon saving this configuration, 2 files are created, an .XML and an .XMLP file.
Similar to the other 2 scenario’s I use a GPO Computer File Preference to copy the files to the folder that is being actively monitored by the FSLogix agent. As soon as the files are there, the FSLogix agent picks up the change and the configuration is made active.


To test this we open the Azure RemoteApp Client and open Internet Explorer as a RemoteApp. Within Internet Explorer we browse to the URL specified to use the older version of Java (Version6 U45). In this case, Java.com and we browse to section that allows us to verify the Java Version we are using.
After clicking Verify Java version we’re presented with the screen below, indicating that we are in fact using the older version of Java! This confirms that the Java rule is correctly working.
To fully prove this, we remove the 2 java rule files from the FSLogix Folder, close and reopen the Internet Explorer Remote App, and here’s the verification we’re now using the latest version of Java!
So using FSLogix we’re able to use the latest version of Java for every (web) application while still being able to support that single application that requires an older version of Java.


FSLogix Apps is very powerful yet extremely simple solution. It provides solutions for very common scenarios related to managing the application landscape within a RDS or VDI solution. In this case I’ve only covered 3 scenario’s, but there are obviously many more. Also note the scenario’s above were not strictly bound to RemoteApps in Azure but rather RemoteApps in general and thus can also be applied in on premises environments. What I wanted to point out in this blog post is that FSLogix has the same added value to Azure RemoteApp scenario’s and provides an easy solution for a lot of very common scenarios without making things over complex. That’s why I think Azure RemoteApp and FS Logix Apps are a great match!