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


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 ( 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 ( 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 website, because the 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, 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!

Wednesday, June 10, 2015

BriForum London 2015 video recordings online

On may 20th 2015, Benny Tritsch and I presented a session at BriForum 2015 in London on Azure RemoteApp. The video recording of that session is now online on It is however, only accessible for BriForum attendees. If you attended BriForum 2015 in London and could not attend our sessions, or if you are going to attend BriForum Denver next month, you can watch the recording here:

Tuesday, June 2, 2015

NEW RDS deployment model: Personal Session Desktops!

With Windows Server 2016 (at this moment still Technical Preview 2) a new RDS deployment model will be available. Currently in Windows Server 2012 R2 we have 2 deployment options. There is Session-Based Desktop Deployments which is based on the RD Session Host role where each user runs a session on a shared Server OS, the traditional Terminal Server model. And there is Virtual machine-Based Desktop Deployment which is based on the RD Virtualization Host role where each user runs a dedicated Virtual Machine (either Pooled or Personal) based on a Client OS, mostly called VDI.
Starting with Windows Server 2016 / Technical Preview 2 Microsoft is introducing Personal Session Desktops or Server Based Personal Desktop. Basically this is combining the 2 currently available deployments resulting in a VDI scenario without using a client OS. So essentially every user will get a dedicated RD Session Host server as their “desktop”. Why is this interesting? Azure! (or Cloud / DaaS in general), because currently you cannot enroll a VDI Solution in Azure because in Azure you cannot control the hypervisor and you cannot license a client VM for VDI scenario’s.
Also added in Windows Server 2016 is improvement on the Desktop Experience feature. If you’re not familiar with this, Desktop Experience is feature in the Windows Server OS that allows you to make the Server OS look & feel like a client OS, very commonly used in a existing RDS deployments. In Windows Server 2016 additional improvements have been added to the feature to make the Server OS look even more as a (Windows 10) Client OS.
So with Personal Session Desktops or Server Based Personal Desktop (not entirely sure what the exact naming will be) you will essentially be able to do “VDI” in Azure where every user will have a fully persistent desktop with options to allow user installed applications or maybe even local admin privileges.
Let’s take a look at how to set that up. In my Azure subscription I set up 4 servers for this test.
DC01     (Domain Controller)
RDCB01 (RD Connection Broker, RD Web Access)
RDSH01 (RD Session Host)
RDSH02 (RD Session Host)
The new Deployment model cannot be created using the Remote Desktop Management Services (RDMS) console as part of Server Manager. Not entirely sure, but most likely this will change after Technical Preview 2, but for now the new Deployment Type can only be created and managed using PowerShell. Be aware, that today, even if you have set up the deployment and created a Session Collection using PowerShell, it will not show up in the RDMS console.
After deploying the above servers (all based on Windows Server technical Preview 2) and setting up a basic Active Directory we can start to create the deployment. We open up a PowerShell prompt with elevated permissions.
First, we import the RemoteDesktop PowerShell module and configure some basic variables we’ll use later on. So we will define the 2 RD Session Host servers, 2 of our test users, a name for the Session Collection and the RD Connection Broker server.
import-module RemoteDesktop
$RDSH1 = ""
$RDSH2 = ""
$User1 = "rdsgurus\rdstest1"
$User2 = "rdsgurus\rdstest2"
$CollectionName = "RDSHPDCOLL"
$ConnectionBroker = ""
Next, before we can create the actual Session Collection based on Server Based Personal Desktops, we need to have a RDS deployment first. To do so we create a RDS Deployment using the following command
New-RDSessionDeployment -ConnectionBroker $ConnectionBroker -WebAccessServer $ConnectionBroker -SessionHost $RDSH1
Now we are ready to add any additional RD Session Host servers to the deployment. In this example we’ll add our second RDSH server
Add-RDServer -Server $RDSH2 -Role "RDS-RD-Server" -ConnectionBroker $ConnectionBroker
We are now ready to create the Server Based Personal Desktops Collection. We do this using the existing command New-RDSessionCollection in combination with the new  -PersonalSessionCollection switch and we’ll also add the switch -GrantAdministrativePrivilege which allows users to be granted local administrator permissions on their personal Session Host. The full command is as follows
New-RDSessionCollection -CollectionName $CollectionName -ConnectionBroker $ConnectionBroker -SessionHost $RDSH1,$RDSH2 -PersonalSessionCollection -GrantAdministrativePrivilege
The result of the command looks like this and indicates a new Personal Session Collection with 2 RDSH servers added.
CollectionName Size ResourceType  CollectionDescription
-------------          ----------------            ---------------------
RDSHPDCOLL       2                             Remote Desktop
NOTE: The switch –PersonalSessionCollection will be renamed to –PersonalUnmanaged in the final release of Windows Server 2016.
The next step is to assign a Personal Session Host to a specific user. You can think of this as Personal VDI in terms of Virtual Machine-Based deployment. We can achieve this using the following command
Set-RDPersonalSessionDesktopAssignment -CollectionName $CollectionName -ConnectionBroker $ConnectionBroker -User $User1 -Name $RDSH1
Set-RDPersonalSessionDesktopAssignment -CollectionName $CollectionName -ConnectionBroker $ConnectionBroker -User $User2 -Name $RDSH2
Let’s now view what has been created
Get-RDPersonalSessionDesktopAssignment -CollectionName $CollectionName
The output is as follows, indicating that we have a collection with where 2 RDSH servers have been assigned to 2 users.
CollectionName            DesktopName                           User  
--------------                   -----------                                  ----
RDSHPDCOLL                 RDSH01.RDSGURUS.COM            RDSGURUS\rdstest1
RDSHPDCOLL                 RDSH02.RDSGURUS.COM            RDSGURUS\rdstest2
Let’s now take a look at what that looks like in action. For that we browse to RD Web Access and logon as one if the test users, in this case rdstest1. Notice that since this is still Technical Preview, the RD Web Access interface still says Windows Server 2012 R2 J
After logging on we now have a dedicated Personal Session Host assigned to us. Based on the assignment we configured, still user will always be redirected to this RD Session Host.
And when launching the assigned desktop the RD Connection Broker direct us to our assigned Personal RD Session Host, which looks like Windows 10 based on the Desktop Experience feature.
Since we used the Switch GrantAdministrativePrivilege the broker added the user account to the local administrators group. This obviously allows the user to have full control over his ‘Desktop”, and supports user installed applications etc.

Conclusion; Yes this new deployment, or rather new type of Session Collection definitely creates more options. Maybe not as the primary solution for every user, but maybe for a small subset of your user base that still needs a persistent desktop, where the majority could for example use (Azure) RemoteApp? Either way, it is interesting though that Microsoft decided to work around their own licensing issue and in stead of fixing it for the client OS, decided to make it easier for the Server OS. :)

Few week ago Benny Tritsch and I also presented a session at BriForum 2015 in London, where we very briefly covered Server Based Personal Desktops, see the slide below.
For more info, Clark Nicholson RDS Product Team member presented a session at Ignite 2015 in which he, amongst other topics, also covered Server Based Personal Desktop. Check out the session here:

Monday, June 1, 2015

Remote Desktop Protocol 10, zoom option to support remoting into Windows 7 with hiDPI client

The Remote Desktop Protocol version 10.0, which is already available in Windows 10 Preview and Windows Server Technical Preview. If you open up the mstsc client you’ll see “Remote Desktop Protocol 10.0 supported”
A new feature of RDP 10.0 client is the option to zoom. If you’ve worked with RDP 8 you might be familiar with the option AutoSize with allowed you to switch between full screen and a sizeable window of you RDP session without having to logoff / logon. In RDP 10 to option to zoom is added.
The zoom option is a solution for a typical problem when using a hiDPI client to connect to an “older” version of Windows, for example Windows7. For example if you would be working in a Windows Surface with 2560x1440 you would generally set if to 150% DPI locally. If you would then open a RDP session to Windows7, that remote session does not automatically adjust its DPI setting to match the local DPI (where Windows 8 does). This results in a DPI of 100% and thus everything within the remote session look very small and less easy to read. With the zoom option to could overcome this. By setting a zoom level the RDP session will be stretched.
To enable the zoom option, click on the RDP icon of your RDP session (switch out of full screen mode). There you have the option to set a fixed zoom percentage.
For example, here is a session towards Windows 7 machine, left is normal more, right is 150% zoom mode.

Now because this is not done on the host side the result will not be crisp & clear. But the idea of this is to be a workable workaround when connecting to older operating systems. When connecting to Windows 8 and beyond, this is not an issue anymore because those session will be able to pick up on the local DPI setting and match that setting in the session.