1 person found this helpful
I read an article that says appvolumes will start making sure they play nice with fslogix but I don't think its there, so I think we need to edit the snapvol.cfg file to make sure they play nice. Fslogix looks to be basically similar to appvolumes, which what I think is a much poorer management structure(I hate GPOs). I'm working on a new pod now where I plan on testing them, but so far the other threads I've read they don't do much more than writable volumes already provide. They are a good option for people who don't have appvolume license and are stuck with roaming profile or horizon persona management.
1 person found this helpful
I'm currently setting up an environment with FSLogix Office Containers and DEM (Horizon 7.9).
Played a short time with FSLogic Profile containers also, but they grew too big. I also don't like the idea of loosing my profiles when the VHDX gets corrupted one way or another (Office Containers don't contain critical data, they can be recovered easily)
It works very nice for the time being. Only issue I'm trying to figure out at this time is the activation of Office 365 ProPlus. It worked fine when I had the Profile Containers, but since I ditched them and used DEM, I always need to reenter my password for the activation (account is remembered, but password not)
Have to say I'm very excited about the outlook cache and search index that is working flawless on our non-persistent desktop pools with Office Containers (Server 2019 & Office 365)
Plan is to go live in the next 2 months...
1 person found this helpful
Up until now, we've used Instant Clones with mandatory profiles, UEM (DEM), and App Volumes writable volumes with custom snapvol.cfg rules. With writable volumes, we disabled all virtualization and just used it as a hidden persistent disk. We then used junction paths to redirect applications installed in the user's local profile (Slack, Teams, OneDrive, etc.) to the writable volume instead. Any other use of App Volumes-- whether it was AppStacks, UIA + profile, etc. was all either too costly on performance, too unreliable/buggy, or both.
We are now in the process of completely replacing App Volumes with FSLogix O365 containers. We're able to use it in the same way we used writable volumes, except it's designed out-of-the-box to work flawlessly with Microsoft products (and it does). Just in our brief testing of Windows 10 1809 with FSLogix O365 containers and keeping UEM + mandatory profiles for profile management, login times have been reduced from about 90 seconds to 30 seconds, and all Office features are working exactly like they should. Teams auto-signs the user in after login, Outlook local OST cache + search indexing enabled provide a great e-mail experience, OneDrive is ready to go a few seconds after login and retains all previously downloaded files, etc.
I'm still not sold on going full profile container, but that may change down the road. Until then, I love the mix of mandatory profiles + UEM + FSLogix O365 containers, and I can't wait to get this fully tested because I know my users are going to love it too.
This makes me hopeful that there are improvements coming for VDI environments. I'd hope that VMware sees the increased adoption of FSlogix and maybe invests more into improve AppVolumes to provide a competitive product.
We are seeing similar experiences with Writables/AppStacks impacting performance heavily, even with added resources (3vCPU/8GBvRAM/1GB vGPU).
How was the setup process for FSlogix in comparison to AppVolumes?
The setup can be so much easier than App Volumes since the setup can be as simple as an agent on the gold image + a network share.
In my test lab, I complicated things a bit, but may rearchitect as I keep testing. I have two Windows Server 2016 boxes on the VDI VSAN cluster used for VDI in each of my sites; I use these servers as a "user environment" repo. These servers are behind a DFS-N with DFS-R replicating UEM configurations, UEM archives, folder redirection destinations, FSLogix rules, FSLogix O365 containers, the mandatory profile, and miscellaneous scripts. After configuring share permissions the way I want, setting a FSLogix GPO to point to the share, and replacing the AppVolumes agent with the FSLogix agent on the gold image, I saw immediate results in performance-- both with login speed and general responsiveness after login.
By the way, my VDIs have the same resources allocated as yours (3 vCPU/8GB RAM), minus the vGPU.
Bought Horizon Standard several years ago and never had an opportunity to test UEM as there was no reason to upgrade to higher graded versions.
Persona has worked - wouldn't say well but it worked for the last 6 or so years.
Enter Fslogix... Started testing with an aim to see if we should deploy it as we migrate our users from Windows 7 to windows 10.
In windows 10, persona profiles load in a 30 seconds to a minute + depending on how fat their profiles are... Persona Management needed a lot of settings created to make office 365 work without any issues and has generally been a pain especially when upgrading the client agent which usually added persona management issues....
I first started testing Fslogix with just the Office 365 component and wasn't happy with the results. Log in times were the same and i didn't really think it added any benefit.
I then tested full profile management - Fslogix with a simple file share location (plus a couple of other simple settings) gives us consistent 15 second log ins and has been solid so far in windows 10 testing. I am annoyed i didn't plan this move earlier as it seems to have fixed most of our persona hates....
So far i am happy with it and can only see it getting better..