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.
Application Profiler
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.
Management Console
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!
UEM Client
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)
Deep Dive
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!
7 thoughts on “How does VMware UEM work with App-V 5 Packages?”
Good information Tamim :)Do you feel UEM better than Ue-V?
Thanks Vigneshwaran. Yes I’d personally say UEM is more feature rich while maintaining the flat file simplicity of UE-V. It also has a much more reassuring communicated roadmap and product team engagement with its user base.
Thanks Thamim for your feedback. In the last line you have mentioned UEM need to rely on detecting App-V and use /appvve to load into application’s virtual environment. So how will this still be better than Ue-V? Your idea’s are highly welcome as I have even planned to check out UEM later this week after reading your blog.
Good question. So it still does the job just as good even though it needs to self inject, there is an outstanding issue with RunVirtual support but this has been really quickly addressed by the product group who will release support for it soon.
UEM is ultimately more powerful than UE-V which just provides file and registry to roam for all users. UEM gives much more control via conditioning. It also covers environmental stuff such as ADMX, scripting, file/reg copies, driver mappings, folder redirection etc.
Cool 🙂 Thanks Thamim 🙂
You do tidy work, sir! Not just good info for App-V with VMware UEM also some good tips for people using any other UEM product.
That means a lot coming from the hardest working man in virtbiz!
Comments are closed.