Home > Blogs > VMware ThinApp Blog

ThinApp and VMware User Environment Manager (UEM) integration

This blog post will explain how you can configure your ThinApp packages for integration with VMware UEM without using vb-script or any other black magic. When you have VMware UEM and ThinApp integrated users’ application settings flow seamlessly between both natively installed, published applications (Terminal Server/RDSH based) and ThinApp packaged applications. Using the integration you can centrally manage default and mandatory application settings also for ThinApp packages.

As most of you know, ThinApp decouples the application from the underlying Operating System. But what is also true is that ThinApp decouples user settings from the Operating System and the application as well. ThinApp packages stores runtime changes and user settings in its Sandbox.


VMware User Environment Manager (UEM) helps manage the users’ profiles and allow for a consistent experience across different devices and delivery methods such as physical, virtual and published applications. VMware UEM decouples the users’ settings, personalization and allow for application settings to be centrally managed.

VMware UEM

With above explanation you probably realize that there is a slight overlap between the ThinApp technology and the VMware UEM. Both can decouple users’ application settings. But VMware UEM is built for this purpose where ThinApp does this mostly as a side effect from virtualization and isolation. ThinApp can only decouple application settings using ThinApp packaged applications where VMware UEM can handle settings for ThinApp packaged applications, natively installed applications and published applications.
So my recommendation is therefore to leave VMware UEM to deal with what it is designed to do and use ThinApp to virtualize the application it self.

In order for this to work you will have to know a little bit of information about your application. And you must know your ThinApp 101, i.e. Isolation Modes. The principle is very simple – the ThinApp package should use Merged Isolation Mode on the locations where user settings are stored. Most of the time this is within the user’s Roaming Profile (%AppData%\ApplicationName) and/or in the user part of the registry (HKCU\Software\ApplicationName). By using Merged Isolation Mode the application’s settings will be stored natively and allow for VMware UEM management.

Let’s have a look at some examples.. I’ll start with Mozilla Firefox. Firefox stores all relevant user settings in the %AppData%\Mozilla folder. This is how my application profile looks like in VMware UEM:

FF application profile

My ThinApp project folder is therefore configured with Merged Isolation Mode on the %AppData% folder. In this example I’ve defined the root of %AppData% to use Merged Isolation Mode but you should be able to do %AppData%\Mozilla just as well. Make sure no content is present in the %AppData%\Mozilla folder. Any virtual elements will override anything native. Virtual elements cannot be managed using VMware UEM and this integration method.

FF ThinApp AppData

VMware UEM has a very nice feature called DirectFlex. This means the application’s settings are not downloaded until the application is actually launched by the user. This makes users’ login time much faster. Since the original executable name is most likely not the name of your ThinApp Entry Point you will have to configure DirectFlex to listen to both executable names. See my Mozilla Firefox example:

FF DirectFlex

Firefox.exe is the name of the natively installed Firefox and Mozilla Firefox.exe is the name of my ThinApp Entry Point. This way, settings will be applied across both natively and virtualized Mozilla Firefox upon launch of the application.

All VMware UEM features like backup, Profile Cleanup and Predefined Settings all work as expected for both native and ThinApp packaged applications.

Next let’s have a look at a slightly more complicated application, PaintDotNet. The reason it is a little more complicated is that this application stores the user’s settings in the registry rather than in %AppData%. But luckily the same principal applies..

First, this is how my VMware UEM application profile looks like:

PaintDotNet profile

When it comes to configure your ThinApp package you must make sure the HKCU\Software\Paint.NET registry location is using Merged Isolation Mode. No settings should be specified (any settings present within the virtual environment will override any native settings). So in my PaintDotNet Project folder I had to clean up the registry and change the Isolation Mode accordingly.

PaintDotNet ThinApp

And again I had to specify both the original executable name as well as the Entry Point’s name in DirectFlex:

PaintDotNet directflex

When it comes to learn where an application stores its settings VMware UEM comes with a great tool called the Application Profiler. Using the Application Profiler you simply launch the application, make some changes to its settings and then you have your Application Profile. Here’s a screen shot after running profiling of Mozilla Firefox:

VMware UEM Application Profiler

You must profile a natively installed version of the application. The VMware UEM Application Profiler cannot profile a virtualized application. You can learn more about the Application Profiler here; https://www.vmware.com/pdf/uem-860-app-profiler-admin-guide.pdf.


This blog post is written by Peter Bjork with the support and help from Hilko Lantinga (VMware EUC Consultant). Please do him a favor and follow him @HilkoLantinga. And I’ll force him to start post more frequently :).