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;
SyncMethod=SyncProvider
In this case settings are initially stored locally in the users profile, and are synced back to the Central Store if its available.
SyncMethod=None
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.
“…<Processes>
<Process>
<Filename>CALC.EXE</Filename>…”
“…<Processes>
<Process>
<Filename>WINWORD.EXE</Filename>…”
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>.
“…<Processes>
<ShellProcess/>..”
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..”
Source: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.
Last week the HTML5 client for Azure RemoteApp was announced on the public roadmap of Azure RemoteApp. More info also see here: 
