Over my design and implementation projects with VMware User Environment Manager (UEM) I couldn’t help but pay particular interest into how it works with App-V. In this blog I intend to lift the hood on how UEM captures and collects user settings for App-V and the mechanisms it uses to make this as seamless as possible.
As far as application profiling is concerned, I always recommend a local installation of an application where possible, this is to limit any potential conflicts or incorrect paths being detected. The goal should always be to capture the traditional locations an application writes to and then let any path translation for other technologies such as App-V or ThinApp happen later down the line. Taking this approach will give your configuration the best chance of survival in the wild and will also reduce the overhead of complexity when generating the configuration. That being said I have tested detection of settings of an App-V package with UEM and found that it has located the traditional paths correctly.
Another useful approach I have taken when bringing profiling tasks into operational processes is to include the profiler tools as part of the packaging build. By doing this you can include the generation of an application profile into the process of actually packaging it. For example a packager could sequence a package, profile it, collect both App-V and UEM assets and then copy them off into a single payload.
Once you have created your application profile and imported it into the management console as described in my previous blog post here you can go ahead and tick the box that says Enable App-V 5.0 support. While the GUI mentions 5.0 rest assured the feature works with 5.1 too!
App-V support has two dependencies before it can be enabled:
Firstly, DirectFlex must be enabled. This allows the UEM engine to intercept process launches on the client to import settings rather than doing the work upfront at logon, the importance of this mechanism will become clearer further in this post.
Secondly, at least one of the DirectFlex executables must be configured without a path. This is because once we introduce App-V we can no longer rely on a certain path to an executable in traditional dependable paths (Program Files), we need to give the UEM engine the freedom to detect a process launch irrespective of where it is being launched from.
Once you have specified your executable(s) for your application configuration, that’s it, you are all set!
Once you taken the steps detailed above to enable your application profile to apply to App-V packages you will find UEM now roams not only settings for traditionally installed applications but also App-V delivered packages. The mechanics of this are exposed when you take a look at the logs after launching, configuring and closing an App-V package:
As soon as the process launch is detected DirectFlex will engage:
[INFO ] Performing DirectFlex import for config file '\\SERVER01\UEMConfig\general\Applications\Notepad++\Notepad++.ini'
UEM will then locate any saved archived settings in anticipation of the import:
[DEBUG] Using profile archive '\\SERVER01\UEMProfiles\thamimk\Archives\Applications\Notepad++\Notepad++.zip'
UEM will then pick up on the fact that the process has been launched from the App-V cache location in %ProgramData%:
[DEBUG] Triggered by 'C:\ProgramData\App-V\8A420GBa-28Q1-73EW-9DV3-JWB42KWNSA52\44462432-235W-6690-D0G1-113B95MMGW70\Root\VFS\ProgramFilesX86\Notepad++\notepad++.exe'
The detection that the process is being launched from the App-V cache will launch the UEM (Flex) engine for the App-V import and it will leverage the /appvve switch to elevate the flex process (FlexEngine.exe) into the virtual environment. This ensures that the import happens within the ‘bubble’ of the package. By taking this approach UEM essentially writes the change within the App-V environment and hands off to App-V to redirect the changes where it sees fit.
[DEBUG] Launching FlexEngine.exe for App-V 5 import ('"C:\Program Files\Immidio\Flex Profiles\FlexEngine.exe" -v- -ua -I "\\SERVER01\UEMConfig\general\Applications\Notepad++\Notepad++.ini" -r "\\SERVER01\UEMProfiles\thamimk\Archives\Applications\Notepad++\Notepad++.zip" -f "\\SERVER01\UEMProfiles\thamimk\Logs\FlexEngine-AppV5.log" /appvve:8A420GBa-28Q1-73EW-9DV3-JWB42KWNSA52_44462432-235W-6690-D0G1-113B95MMGW70', 'U')
Finally the import completes:
[DEBUG] App-V 5 import returned exit code 0 [INFO ] Completed DirectFlex import (221 ms)
The same sequence is engaged when the export occurs when closing the application:
[INFO ] Performing DirectFlex export for config file '\\SERVER01\UEMConfig\general\Applications\Notepad++\Notepad++.ini' [DEBUG] Using profile archive '\\SERVER01\UEMProfiles\thamimk\Archives\Applications\Notepad++\Notepad++.zip' [DEBUG] Triggered by 'C:\ProgramData\App-V\8A420GBa-28Q1-73EW-9DV3-JWB42KWNSA52\44462432-235W-6690-D0G1-113B95MMGW70\Root\VFS\ProgramFilesX86\Notepad++\notepad++.exe' [DEBUG] Launching FlexEngine.exe for App-V 5 export ('"C:\Program Files\Immidio\Flex Profiles\FlexEngine.exe" -v- -ua -i "\\SERVER01\UEMConfig\general\Applications\Notepad++\Notepad++.ini" -s "\\SERVER01\UEMProfiles\thamimk\Archives\Applications\Notepad++\Notepad++.zip" -b "\\SERVER01\UEMProfiles\thamimk\Backups\Applications\Notepad++\Notepad++.zip" -f "\\SERVER01\UEMProfiles\thamimk\Logs\FlexEngine-AppV5.log" /appvve:8A420GBa-28Q1-73EW-9DV3-JWB42KWNSA52_44462432-235W-6690-D0G1-113B95MMGW70') [DEBUG] App-V 5 export returned exit code 0 [INFO ] Completed DirectFlex export (251 ms)
So to further understand why UEM takes the approach described above we need to dive a bit deeper and look at how mini filter drivers work to intercept operations in the I/O stack. Mini filter drivers attach in a particular order referred to as altitude, these are managed by Microsoft and allow one filter driver to intercept calls before another. For each I/O operation the filter driver has the ability to issue a pre-operation callback routine and/or post-operation callback routine.
Above is a list of some of the filter drivers on a UEM client machine in my lab. As you can see the UEM immflex mini filter driver sits at a lower altitude than the AppvVfs driver which is responsible for the App-V virtual filesystem. This isn’t ideal because it means that UEM can only deal with the I/O stack after App-V has diverted changes around. Compare this to the UevAgentDriver which has the luxury of sitting above the App-V driver, this means UE-V (Microsoft’s User Personalisation solution) does not care so much about whether an application is App-V or not as it gets to work before any diversions take place. For this reason as we saw in the logs above, UEM has to detect App-V packages and inject itself into the App-V virtual environment to get itself into the correct altitude using the /APPVE switch on its engine process.
Above I have detailed a somewhat simplified representation of what happens when a user launches an App-V application which we have enabled for personalization in UEM. All of this happens transparently to the user who at worst sees a small delay between invocation and launch, however usually this is not noticeable. In an ideal world UEM would secure a filter driver altitude higher than the App-V VFS so that it wouldn’t need to rely on detection of App-V vs. traditional applications and inject into the virtual environment. However all said and done, UEM is very effective in roaming settings for App-V packages in its own unique way!