VMware App Volumes and FSLogix container conflicts resolved.
I have a client where we have implemented a full VMware Horizon VDI solution. This solution consists of VMware Horizon, User Environment Manager and App Volumes (along with UAGs of course). The whole suite of products working in harmony to give the users an excellent tailored VDI experience. With the recent acquisition of FSLogix by Microsoft, we decided to see how we could raise the bar even more for user experience and management. On our Windows 10 image, we have the View, UEM, App Volume and now FSLogix agents all installed. For the FSLogix configuration, we are using the Profile Container.
For those unfamiliar with FSLogix, it is a (now) Microsoft technology that basically uses a network mounted VHD file to store either Outlook Cached data (Outlook Container) or the entire user profile directory (Profile Container) essentially giving you a very stable and efficient roaming profile of sorts. For a GREAT primer on User Profiles, check out Jacques’ outstanding article below:
http://vcloudinfo.com/2019/08/a-brief-history-of-user-profiles-and-an-idea-for-microsoft.html
After introducing the FSLogix agent to the mix, the user’s VHD would never connect and always remain inactive during the session. I suspected a conflict with the User profile directories between FSLogix and App Volumes. (Spoiler Alert: I was right)
For the specifics of this case, we were running the following versions of the software:
|
vSphere |
6.7 |
|
Horizon |
7.9 |
|
App Volumes |
2.15 |
|
FSLogix Agent |
2.9.x |
|
Windows |
10 |
Looking through the FSLogix logs, I could see that it was failing to mount the VHD once the session started. After some back and forth with the VMware App Volumes Support team, we came up with a solution based on the SNAPVOL.CFG file available during packaging of an App Stack. This file is used a lot for writable volumes but can also allow you to selectively exclude parts of the file system and also processes during a capture and then subsequent mount of an AppStack.
For FSLogix specifically, we needed to add the following exclusions to the SNAPVOL.CFG file.
exclude_path=\Users
exclude_process_path=\FSLogix\Java
exclude_process_path=\Program Files\FSLogix\Apps
exclude_process_name=frxcontext.exe
exclude_process_name=frxshell.exe
exclude_process_name=frxsvc.exe
exclude_process_name=frxccds.exe
exclude_process_name=frx.exe
exclude_process_name=ConfigurationTool.exe
exclude_process_name=frxtray.exe
exclude_registry=\REGISTRY\MACHINE\SOFTWARE\FSLogix
These exclusions pretty much cover anything FSLogix related and should give you a great starting point for a conflict free implementation. Once we implemented these changes to the AppStack, the issue went away and both agents (FSLogix and AppVolumes) coexisted peacefully.
The challenge moving forward is to go back and update all existing AppStacks to now include these exclusions and make sure that new AppStacks contain them as well.
For the first challenge, there is no really good way to do it other than manually touching all the prior AppStacks but for future AppStacks, I recommend modifying or creating a customized Template AppStack so that these exclusions are used consistently and always from the start. Creating the new template involves creating a new VMDK, mounting it, adding the contents of a pre-existing template to it, and finally adding specific exclusions for FSLogix. You can use the following VMware KB article to accomplish this.
https://kb.vmware.com/s/article/2116022
This solution took a while to stumble upon and I could not find anything on the interwebs related to it so hopefully this post helps someone else searching for it. If it helps you, be sure to let us know in the comments and let us know if you needed to add any additional exclusions that we might have missed or have become out of date as the article ages.
I think more and more people will be rolling out FSLogix as it increasingly becomes a bigger part of the Microsoft User Experience Story.
Happy VDI’ing!