Jul 10, 2017 - 0 Comments - Virtual Vibes -

Roaming Windows Application Settings with VMware UEM

I have recently been working a lot with VMware User Environment Manager (UEM), formally known as Immidio Flex+. If Ivanti’s Desktop Now powered by AppSense is too complex and Microsoft’s UE-V is too simple then UEM surely sits squarely in-between the two! It has a very light weight infrastructure and still maintains a good level of control when addressing user experience across Windows applications whether they are App-V delivered or otherwise. In this post I want to walk you through the high level process of capturing and deploying application settings which you want to roam for your users.

Step One – Use the VMware UEM Application Profiler

While UEM gives you the ability to directly create and configure settings within it’s management console, the profiler is a separate tool available to assist you in this process. It works very much like the UE-V Generator I have previously talked about. Just hit Start Session and identify your locally installed application:

You can select items from your start menu or browse manually to your application on disk:

Once you click okay the application will automatically be invoked. At this point you can go ahead and interact with your app to trigger any personalisation actions that will allow UEM to pick up where your application writes to:

Once you are done, click stop analysis and you will be a presented with any locations that have been picked up:

The profiler has many options to help you optimize your capture, expect a post deep diving into this soon! Once you hit save on your config you can expect something like this:

The .ico is used to populate the console with an icon once you import the config, The .ini file contains all the settings locations you have captured and any deployment configuration you specify later and lastly you will find a .flag file which is used for VMware UEM registration.

Optionally if when you save your configuration you can include the actual settings on the machine referred to as Predefined Settings these will be saved as a .zip file and allow you to dictate the initial settings a user will get for a given application rather than just locations to roam. This can be especially useful if you want to use UEM to configure an application to a golden state from day one for a user.

Step Two – Import your Configuration

As discussed earlier, VMware UEM has a very lightweight infrastructure, this is essentially underpinned by two file shares. One share is used to store user wide configurations and the second is used to store individual user settings based on these configurations. To import your configuration all you need to do is copy the files above to your configuration share:

Then go to your UEM Management Console and hit Refresh Tree on the Personalization tab.  This will rescan the share and pull in any new configurations:

Step Three – Configure your Configuration!

So off the bat now you are pretty much live with your new configuration however it is most likely the case you will want to further configure how this configuration is handles, here is a tab by tab round down:


Here you will be a representation of the actual configuration .ini file you have just imported. You are able to edit the file directly in this window if you so wish, you can also take advantage of similar functions you would find on the UEM Profiler such as the ability to add in Section and Folder Token tags to further build your configuration locations.

Profile Cleanup

On this tab we can configure any local file or registry  assets which we want to delete upon logoff or process exit. This can be especially useful when trying to move off roaming profiles as you can slowly trim down the local profile each time you chose to roam a new collection of settings. Overtime, this approach will mean the roaming profile gets slimmer and slimmer until eventually it can be retired completely in favour of UEM.

Predefined Settings

As mentioned in step one, this is the place where you can work with any predefined settings. These are basically a collection of files and/or registry that will be delivered from the offset for your users without any requirement to include them as part of a mandatory profile or logon script. UEM allows you to work with these settings directly from the console as shown above.


On this tab you can chose to keep point in time backups of user personalisation for each given configuration, this can also be specified across all configurations as a global setting using the GPO if desired. The default is not to create backups, if you turn the feature on then all you need to specify is however many previous captures of user settings you wish to keep. These will be stored in the UEM profile share under a separate folder called Backups. By default enabling this feature will mean users can self service restore their application personalisations to a point in time back up on the client side using the UEM Self-Support. You can disable this ability by checking the Hide from VMware UEM Self-Support tick box shown above.


This tab is a very useful place to refine how and when settings are imported. Without DirectFlex everything happens at logon (just in case) which could be wasted overhead if the user never launches the application. With this setting enabled the personalisations are only imported at process launch (just in time), UEM will intercept the executable launch to pull down any stored settings. The subsequent export of settings can also be configured to happen at either (last) process exit or logoff.

Additionally we also have the opportunity to Enable App-V 5.0 support, this will allow UEM to listen out for a given executable (this must be supplied without a specific path), when that process is seen launching UEM will essentially use the /APPVVE switch on the Flex engine process to inject into the virtual environment and import / export settings accordingly. Similarly ThinApp support can also be activated using the checkbox provided and unlike App-V support it doesn’t require a pathless executable reference. DirectFlex supports multiple executables to be listed per configuration.

Enabling DirectFlex also gives the opportunity to run other tasks at executable launch on the User Environment tab as I will go on to explain.


Most of the settings on this tab are self explanatory. Config File Processing will be greyed out if using DirectFlex otherwise by default it will be ticked to specify import/export to happen at logon/logoff. Skip allows us to specify files to exclude from the export of local settings back to the share based on size and/or age. OS-specific Settings can be used to prevent user settings transferring between different operating systems, typically this isn’t something that I would suggest as it isn’t conducive to a seamless user experience across platforms however can be enabled for circumstances that are known to cause issues.


Conditions form a key component of UEM when it comes to controlling who and what is effected by specific configurations. These conditions are can be formulated directly on the configuration using the detections listed above. You can also use re-useable predefined conditions called Conditon Sets which are configured on the Conditions tab of the console. The various conditions can be formulated using logical connectors such as AND/OR to tightly control the exact circumstances you want the configuration to be applied.

User Environment

This tab is often overlooked as it is hidden away somewhat from the rest of the environment related actions in the console however it offers a very useful ability to able to trigger tasks to occur at process launch. This is less related to the user personalisation and more regarding environmental changes you wish to make upon the user launching the application. As mentioned earlier this feature requires DirectFlex to be enabled and will be greyed out otherwise. Actions you can trigger here are almost as wide ranging as the various settings you can achieve on the main User Environment tab in the console but rather than apply at logon/logoff they will apply at process stop/start. If the out of the box environment settings do not suit your needs you can always utilise this feature to run script based actions at the given time junctions (Pre-Import, Post-Import, Pre-Export and Post-Export).


Finally on this tab we are able to give the configuration a title, description and relevant comments. Also there is a useful summary of all the settings specified on the other tabs for this configuration. These settings are all captured into the original configuration .ini file that we created.

Now you are all set! Your configuration is now ready to be consumed by your users at next logon!