Thursday, August 20, 2015

Microsoft Edge in Windows Server 2016 (Technical preview 3)

As you might have heard, Windows Server 2016 Technical Preview 3 is out and available in both Windows Azure IaaS, as well as in MSDN.

One of the new features in the Preview release is that Microsoft Edge (the new browser which is also available in Windows 10) is now also available in this preview release of Windows Server 2016.

This means that users that access a Remote Desktop Services deployment where a full desktop is deployed, can now also use Microsoft Edge is their remote session.

Below is an example where Microsoft Edge is used on a Remote Desktop Session Host deployed as part of a Session Based Desktop Deployment based on Windows Server 2016 Technical Preview 3.


For an overview of all new features related to RDS also see: What's New in Remote Desktop Services in Windows Server 2016 (Technical Preview 3)

For more information on Microsoft Edge visit:

Wednesday, August 19, 2015

What's New in Remote Desktop Services in Windows Server 2016 (Technical Preview 3)

As part a series of articles called “What's New in Windows Server 2016 Technical Preview 3” Microsoft has published an article containing a summary on what is new in Remote Desktop Services in Windows Server 2016.

  • Personal session desktops

Administrators can now deploy server-based personal desktops in Windows Server 2016. With personal session desktops, each user gets an assigned RD Session Host (RDSH) VM - the admin can optionally enable administrative rights for users. See Introducing Personal Session Desktops by Clark Nicholson for more information.

  • Support for Gen 2 VMs

You can now use Gen 2 VMs (virtual machines) with Remote Desktop. You can use Gen 2 VMs as template images for pooled/personal VM collections and personal session desktop collections. There's no additional configuration required, so deploy at will.

  • Pen remoting support

Pen devices - like those available with Surface Pro 3 devices - are now supported for use through Remote Desktop connections. Technically, you always could use the pens, but it was treated like a mouse. Now we treat pen devices as equal to your mouse, fingertip, and keyboard. David BĂ©langer has a great post covering how to use pen remoting.

  • Edge support in RDSH

You may have heard that we released a new Web browser - Microsoft Edge. Test Edge in Remote Desktop to see how it handles your apps and meets your needs.

  • OpenGL applications and guest VMs in Remote Desktop

RemoteFX vGPU support in Windows Server 2016 adds support for OpenGL applications and Windows Server 2016 guest VMs. Check out the RemoteFX vGPU information in the RDS blog to get more details and step-by-step instructions on how to test this support.

  • Windows Multipoint Services

Multipoint services is a low-cost, single-server multi-user solution that is easy to deploy and easy to manage. Multipoint is now part of Windows Server 2016 as an optional role, instead of a separate product. When you enable the Multipoint services role, we also install RDSH.

For more details on this new feature, particularly an FAQ, see Tanmay Bhagwat's post on MultiPoint Services on the RDS blog.

  • Client updates

We regularly update our Remote Desktop clients - see Microsoft Remote Desktop Clients for the latest details.

But, in particular, you should check out these:

Remote Desktop preview app for Windows 10 - You can get it from the Microsoft store on any device running Windows 10 or Windows Server 2016 Technical Preview.

Remote Desktop preview app for Mac - You can get it from iTunes.

New Azure RemoteApp feature: Link existing vnet to cloud collection

There is a new feature available in Azure RemoteApp! Linking an existing vnet to an Azure RemoteApp Deployment. We as MVP’s have been testing this in beta, and the feature is General Available today. The feature was previously only available for Hybrid Deployments. Also making this possible for Cloud Deployments will create a new set of scenarios if you’re already using other Azure services such as SQL or Azure IaaS without the need to setup a hybrid deployment with domain join and AD Sync services.

If you create a new Azure RemoteApp Deployment with vnet (also called hybrid deployment) you now have the option to select ‘no’ for join local domain. You might think, “wait wasn’t this all about a new feature for Cloud Deployments?” Yes it is! but what we are in fact doing here is setting up a Hybrid Deployment, but than without the domain join, essentially making this a “Cloud Deployment”. This also means that Cloud Deployment and Hybrid Deployment are now moving closer together. In fact, the only true difference between the 2 deployments is whether or not you join to a local domain. A next logical could be that these 2 deployments will eventually merge into one.


This will result in a step-by-step guide similar to the one you get when deploying the full Hybrid Collection, but in this case we obviously don’t have to configure the join local domain part.


After selecting the template image, the App Collection will start to provision immediately.


After the collection has been provisioned we’re able publish applications and add users similar to any other Azure Remoteapp deployment. When publishing cmd.exe as a test we’re able to confirm that we received an IP from the existing vNet and that we can access server resources, in this case a server running in Azure IaaS within the same vNet.


And here we are accessing a file share on that File Server, located in Azure IaaS


This is obviously a simple example, but you can imagine we could access any FileServer, Application Server, Database Server et cetera hosted in the vNet.

As explained in the introduction, this ability creates new opportunities to use Azure RemoteApp in specific scenarios to publish applications that require a server backend, but not necessarily a full environment with Active Directory and AD Sync in place.

The Microsoft RDS Team has confirmed that PowerShell support will soon follow!

The RDS Team also introduced this new feature here:

Wednesday, August 12, 2015

New Azure RemoteApp client supporting pinning to local Start Menu / Start Screen is now publicly available!

We have been waiting for this one!

In April We were given a first look at a new feature of the Azure RemoteApp client. Also see Azure RemoteApp: First look at pinning Azure RemoteApp shortcuts to the Start Screen! This allows pinning a RemoteApp to your local Start Screen and means that you no longer need to constantly switch to the Azure RemoteApp client to a launch a RemoteApp. In fact, after the initial sign in, you can even close the client and still launch a RemoteApp directly from the Start Screen.

Benny Tritsch and I had also performed a demo of this feature while it was still in private beta at the BriForum 2015 Conference in London last May, during our session called “Unfolding the Azure RemoteApp Magic

The feature is now publicly available! If you open the Azure RemoteApp client, the click once application will automatically update.


And after you log on, you will be presented with a note in the client stating “Find all your apps in the Start menu All apps list”


The RemoteApp applications are now available and ready to launch from the local Start Menu. In my case Windows10, but this is also supported for Windows 8 and Windows 7.


From here the shortcuts can be pinned to the Start Menu as desired.


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: 

Link to the RDS Team blog article:

More overall information on Azure Resource manager:

Thursday, July 9, 2015

Adding Conditional Access & MFA to Azure RemoteApp

(Originally posted on

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.