#VMware #Horizon App Volumes: Hints (for Performance and Packaging)

Two weeks ago I had the pleasure to spent 4 days on problematic Applications within an App Volumes environment of a customer. The best thing that can happen to me as an infrastructure guy is to work on building AppStack with guys who know how to package and therefore troubleshoot those applications. Bringing together the knowledge from multiple domains helped us to fix the problems that we had so far with App Volumes.

Common issues we have been faced with:

  1. During the AppStack provisioning process an Application was not able to get installed
  2. (Crappy) Applications put user-data-files into C:\Windows
  3. Start-Up Performance of applications was really really slow (factor 20x slower)
  4. A mounted AppStack leads to a repair of Office-components

One of the common problems I have seen with App Volumes in the past. The infrastructure can be designed and delivered by an Infrastructure guy -> As soon as we talk about applications. We or more correct the organization that is planning to create AppStacks needs application packaging expertise.

So let’s make it quick. I will give you some hints how some of your problems might get solved.

  1. During the Appstack provisioning process an Application was not able to get installed

During the installation of Solidworks the progress was suddenly disrupted and a rollback occurred. Unfortunately no further information has been given.

Digging through some of the installer logs, we have seen that at the moment where Windows firewall settings have been changed the App Volumes engines obviously had a problem. As soon as a writeable Volume or App Stack is going to be provisioned a change in the integrated Windows firewall will lead to such a problem.

Solution: Make sure to Disable the Microsoft Firewall Service to avoid this problem


  1. (Crappy) Applications put user-data-files into C:\Windows

We all know those Applications that put user-data in folders that are not meant to store that kind of data. Storing personal configuration under C:\Windows would be such an example. The good thing is: As soon as the runtime-context is not allowed to store data within the system folder it creates a sandbox folder within the users profile which can then be ‘roamed’ via a User Environment Manager profile.

In a default-provisioning process the applications-user-config data would be stored in the abstracted App Volumes layer and could therefore not be put into the UEM profile.

Solution: Make sure to edit the snapvol.cfg (under C:\SnapVolumesTemp) file of this specific AppStack and add exclude the absolute path to the Configuration file. After doing that write approach will be done within the base Operating System and since the missing permission it will be written within the Users-Profile


  1. Start-Up Performance of applications was really really slow (factor 20x slower)

Sometimes the capturing process of an application works pretty fine, but as soon as the Application is started the performance is getting really bad. We have observed this with CATIA which needed around 10 minutes to start. A comparison with a native installed CATIA application showed us that it can be done within 15 seconds. Analyzing (e.g. with process monitor or SpyStudio) we figured out that the startup process did a lot of registry-operations during the applications start-up phase.

Thanks to an option that can be put into the snapvol.cfg of the Appstack we are able to pre-load and cache specific registry keys leading to an improved / native-installed start-up performance.

Solution: Figure out which if too many registry operations lead to the performance decrease. Specify this location via reverse_replicate_registry_key in the snapvol.cfg


  1. A mounted AppStack leads to a repair of Office-components

The bad thing with all kind of layering, application-virtualization or abstraction technologies is the dependencies between the different layers. A good example are applications that change Microsoft Office components during their installation (e.g. including Visual Basic stuff). If you provision the application on a clean Desktop (which is typically recommended) which has office not installed, you will be forced to do an application repair every time you start an office component when the previously built appstack is mounted.

Solution: Make sure on the provisioning machine office is installed.

Other important things I have noticed in all the years regarding AppStacks:

  • Don’t created too many AppStacks. Try to consolidate many and especially dependent applications in one AppStack.
  • Applications that are mounted based on a computer assignment rather than a user assignment lead to a very improved login time.
  • If you use Instant Clones, do NOT use OU for the computer assignments. This lead to a situation that the AppStacks get mounted to the Instant Clone Template.
  • You must have a proper profile management for the applications that are delivered via AppStacks. Use UEM and create functional application profiles!
  • Do NOT use App Volumes with dedicated – stateful VMs. If we go the App Volumes & UEM road -> Use instant-clones (dedicated & floating) that are clean at every login.
  • Scale-Out App Volumes and make sure it is highly available. An outage of the App Volumes infrastructure will lead to a severe End-User impact.
  • If you have issues, check for the latest App Volumes version, check/ask in the VMware App Volumes community or open a support at VMware.

I really like the idea of App Volumes and it still helps us to deliver a much more scaleable, easier to manage approach for virtual desktops (if we do it right). Anyway, I would also encourage VMware to drive more progress into App Volumes. We are still at version 2.X which is missing key-features that is IMO required in an enterprise. It is about time to elevate App Volumes to a next – modern level.

Appstacks depend on the quality of the packaging people – Please try to create a motivational approach so that knowledge about specific applications (and its wire traps) will be shared across the community (gamification might be the key ;-)

Note: Thanks Kai for the interesting week and good stuff I have also learned about the packaging point of view ;-). Keep on helping the VMware community.

4 thoughts on “#VMware #Horizon App Volumes: Hints (for Performance and Packaging)

  • 13. June 2018 at 18:27

    Awesome post, thanks! Didn’t know about the reverse_registry thing.
    Here’s the official KB if anyones interested: https://kb.vmware.com/s/article/2145683

    In the screenshot i see acad.exe, do you have any other tips optimizing AutoCAD while using Appvolumes?


  • 24. June 2018 at 23:50

    This is excellent piece of info! Not too much information is available out in the wild about App Volumes. This is one of the best pieces of advise i have seen.

    Look forward for more!

    – arun.

  • 6. December 2018 at 18:42

    Just a comment about assigning an AppStack to an Instant Clone OU. You can get around this by limiting the AppStack assignment to computers that start with certain characters. Don’t use “it” as the limit, as this is what the templates’ names start with.

  • 8. December 2021 at 15:57

    regarding RegEnumKey operations we still see the issue of low performance on AppVol 2103.4 (Version4)… each RegenumKey operation on the HKCR takes 0.00004s which is factor 20 compared to the normal 0.000002s as described in the kb https://kb.vmware.com/s/article/2145683
    Have you encountered similar problems in the past and have you overcome this?


Leave a Reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload CAPTCHA.

This site uses Akismet to reduce spam. Learn how your comment data is processed.