Thursday, October 1, 2015

Remote Desktop Services MVP - 5th year!

I received the email today, my MVP award in the category Remote Desktop Services is renewed for yet another year!

This is my 5th MVP Award in a row, honored! Thanks Microsoft!

Microsoft MVP Banner

Dear Freek Berson,
Congratulations! We are pleased to present you with the 2015 Microsoft® MVP Award! This award is given to exceptional technical community leaders who actively share their high quality, real world expertise with others. We appreciate your outstanding contributions in Remote Desktop Services technical communities during the past year.

Friday, September 11, 2015

New preconfigured RDSH image available for Azure RemoteApp & RDS on Azure IaaS to include Office 365 ProPlus installation

Starting from March 17 2015 Azure RemoteApp started to support using Azure IaaS to create a Azure RemoteApp template image. For details on that see: Now publicly available: Creating Azure RemoteApp templates using Azure IaaS!

Later, Microsoft also created an base RDSH Template image in Azure IaaS called “Windows Server Remote Desktop Session Host Windows Server 2012 R2”. This image already contains all off the requirements for a Azure RemoteApp template image, and could also be used for RDS in Azure IaaS scenario’s. An ideal starting point for both scenarios.

Recently, Microsoft announced the availability of another base template image called “Windows Server Remote Desktop Session Host with Microsoft Office 365 ProPlus”.

This image is also optimized for Azure RemoteApp and Azure IaaS, and inside this template image Microsoft has installed Office 365 ProPlus including the necessary Shared Activation configuration. If you’re looking at deploying Office 365 ProPlus inside Azure RemoteApp or RDS in Azure IaaS, this new template image is the best starting point!


Wednesday, September 9, 2015

Caution when using User Experience Virtualization (UE-V) with Microsoft RemoteApp

I recently ran into some interesting results when using Microsoft User Experience Virtualization (UE-V) with Microsoft Remote Desktop Services, in particular using RemoteApp technology.

For those who don’t know, UE-V is a Microsoft Profile Management solution first introduced a couple of years ago. Prior to UE-V the only Microsoft solution to roam user settings has always been Roaming Profiles. With Roaming Profiles Technology, part of the users profile is copied centrally during logoff and applied during logon and allows users to roam application settings and other preferences across multiple computers, and multiple RD Session Host servers in case of an RDS environment. Roaming Profiles have been there for a long time, and I think we all know the challenges with Roaming Profiles (Slow logons, Profile Corruption etc.) which are still applicable today. This is why there are many vendors (Citrix, VMWare, Dell, AppSense, RES etc.) that offer User Profile Management solutions or have included it in their overall Desktop Virtualization management solutions.

With the introduction of UE-V, Microsoft announced a new method to roam settings across devices and sessions. The concept behind it is great, you can now roam specific user settings and preferences (configured by creating UE-V Templates) across multiple devices without having to roam the complete profile. And also, many of the application settings & preferences can be stored centrally upon other triggers than logoff, for example on application close. This means you can roam settings across devices without logging off. Despite the great concept of UE-V, the development cycle of the product seems slow. All configuration still needs to be done by GPO, PowerShell and creating XML template files. There is no central GUI, no direct integration with the existing Microsoft Consoles like Server Manager. And although there is an active community that creates & shares new XML template files, Microsoft does not provide that many (updates to) their template files as I would like to see. Definitely enough room for overall improvement in that space.

Recently I have done some testing with UE-V and Remote Desktop Services, in particular RemoteApp. A little background, UE-V can work in 2 different modes, configured using the SyncProvider settings, basically the difference is as follows;

In this case settings are initially stored locally in the users profile, and are synced back to the Central Store if its available.

In this case settings are not stored locally in the users profile but directly synched to the Central Store.

Because of this, the Microsoft recommended common practice for RDS and VDI scenarios is to use SyncMethod=None because this will avoid settings stored locally and since we can assume the RDS or VDI environment is “always on” in a sense that it can reach the Central Store, we really don’t have to let UE-V cache settings locally.

Besides the SyncMethod, UE-V defines 2 types of settings. In an environment where SyncMethod is set to None, Asynchronous settings are settings that can be stored & applied during the session, at logon, logoff, Lock, UnLock etc. Synchronous settings are settings that can only be stored during Logoff, and can only be applied during LogOn.

So, back to my environment, a Remote Desktop Desktop deployment based on Windows Server 2012 R2, where RemoteApps have been published (no Full Desktop). In this environment I roam several Application Settings & other preferences across Multiple Session Collection serving multiple RD Session Host Servers, using UE-V. I used the default Template files that Microsoft Provides for Office2013, Calculator, Desktop Settings and Roaming Credentials. And UE-V is configured with SyncMethod=None.

The settings in the templates MicrosoftOffice2013Win32.xml and MicrosoftCalculator.xml are Asynchronous settings, which means they can be saved to the Central Store during application close, and can be applied during application launch. When taking a closer look at these 2 templates, you’ll notice the <Process> tag and underneath the <Filename> tag where you’ll see a reference to the application in question.



When publishing these applications, applied settings are successfully stored in the Central Store upon closing the application, and successfully applied upon opening the application. Which means that these settings can now successfully roam across Multiple Session Collection severing multiple RD Session Host Servers. So far so good!

The other two templates DesktopSettings2013.xml and RoamingCredentialSettings.xml are Synchronous settings,which means that they are stored on the Central Store during Logoff and applied during Logon. Taking a look at the template we see the reference to <ShellProcess/> rather than <Filename>.


In this scenario I’m particularly interested in storing Windows credentials. And here’s why. In this Scenario I’m running Office 2013 Click To Run to be able to provide the Full Office experience as RemoteApps, connected to Office 365. When opening Outlook on the RD Session Host for the first time a user will need to authenticate against Office 365 and in some scenario’s, also provide authentication to activate Office (based on shared activation). This results in 2 credentials being stored in the Credential Manager. I obviously don’t want to force users to provide those credentials at every logon, so the RoamingCredentialSettings.xml offers the solution here. Storing & applying Windows Credentials using RoamingCredentialSettings.xml works fine for both a Client OS as well as Server OS in case of Remote Desktop Services.

Here’s comes the catch;

When using UE-V on Remote Desktop Services, Synchronous OS settings only work when using a Full Desktop, Synchronous OS settings don’t work when using Published RemoteApps!

I have been working Microsoft Support on this issue, and asked them following question:

“…Is storing synchronous settings (RoamingCredentialSettings and DesktopSettings) supported / even possible in a Microsoft RDSH scenario when using Published RemoteApps (instead of Full Desktop)? I ask this because there is an important difference between RemoteApp and Full Desktop related to the Shell, which in turn is related to storing synchronous settings.
I quote:
“…Rdpshell.exe is the shell, the RemoteApp equivalent of Explorer.exe. It keeps track of changes to application windows (for example, opening and closing) and sends them to the client-side components so that the application window visible to the client behaves exactly like the application window in the invisible shell..”
Windows Server 2008 R2 Remote Desktop Services Resource
by Christa Anderson & Kristin Griffin.

Microsoft support then reached out to the MDOP Product team in the US, and they came back with the following confirmation.

UE-V is designed to only synchronize asynchronous OS settings in remote app sessions on session disconnect. The customer’s conclusion is right on target. Synchronous OS settings are tied to a full desktop, which uses explorer.exe as the shell rather than RdpShell.exe.

I was unable to find any Microsoft Documentation on this, so decided to share this here. Be aware of this when using RemoteApps and UE-V. In those scenario’s UE-V will only be triggered to store asynchronous settings. All Synchronous OS settings, including i.e. Desktop Settings & Windows Credentials won’t work in that scenario.

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.