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

2. (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

3. 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

4. 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.

Original Post: https://vlenzker.net/2018/04/vmware-horizon-app-volumes-hints-for-performance-and-packaging/

‍