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.
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.
2 people found this helpful
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..
Your experience is so interesting. We are using Horizon Advanced with full clone desk pools and MS roaming profiles. I am planning to switch to FSlogic profiles management solution. Do you think it worthy to try? Any benefit?
Lost this post out of my sight... At this time, we are running the current configuration for a month now for about 30 users and everything works smoothly!
- Horizon 7.9
- Linked Clone non-persistent VDI with Windows Server 2019 base OS
- FSLogix profile containers for profiles & FSLogix Office containers for Office data, both stored on a Server2019 fileserver REFS volume with deduplication enabled (getting around 30% savings)
- (we dropped the DEM configurations)
Profile containers are quite ok. Biggest one right now is 3GB, but most are around 1~1.5GB. Office containers are much bigger, some of them grow to 10GB (mostly because of Outlook OST file or OneNote cache and MS Teams cache). But by using deduplication we can keep this within reasonable storage ranges.
We are running the shrinkfsl.exe tool on all VHDX each night after the backups (actually we run it twice after each other, cause it sometimes seems to shrink nothing the first time and a whole lot the second time, but I could find any pattern in this)
Will be extending this configuration to around 200 sessions in the next weeks.
Hope this helps anyone. If you ask me, FSLogix is definitely the way to go for profiles! (That is, probably, until I have some terribly data corruption one day... but let's keep fingers crossed!)
We are running Veeam backup of the server that hosts the VHDX files. Our VDI's are set so they are logged off after 2 hours of disconnection to force the users log off their sessions regularly. So during the backup, most VHDX files are not in use.
I've already done some tests with restoring VHDX files (both used and unused during backup) and they seem to be fine. Most important is that the security on the VHDX is set correctly or you'll get an access denied when opening the profile.
I've had concerns in the beginning too, that's why I started off with differencing disks, so the parent disk is always "unused" during backup. However we've had some issues with the Shrinkfsl tool to compress those VHDX (has been solved in the meantime) and as the restore of in-use VHDX seems to work fine, we reverted backup to direct-access VHDX.
On the other hand, there's not much "critical" data inside those VHDX. The ODFC contains only cached data that is completely recoverable, folders like Documents, Pictures, ... are redirected, so at the end only user "settings" (and lots of crap) remain in the profile container. In a User Experience way of cource, this is very important.
Coming from Persona, we planned to migrate to FSlogix this spring, but the covid-19 slowed us down a bit.
Migrated 60 persona profiles to fslogix and none of our users complained about anything.
Found out a script to shrink VHDs at night, it's like PSTs, you have to compress them if the users delete files/folders.
Had to tweak what to include/exlcude (with XML) but it works good for us.
Thanks Mickeybyte. Apologies for my lack of knowledge here, still a newbie on FSLogix. When you say
"I've already done some tests with restoring VHDX files (both used and unused during backup) and they seem to be fine. Most important is that the security on the VHDX is set correctly or you'll get an access denied when opening the profile."
do you mean the Veeam backup concepts? What do you mean by "security on the VHDX is set correctly"?
Also the shrinkfsl script is a third party one? Does VMware/Microsoft Support it officially?
By "Veeam Backup" I mean that it's taking an snapshot backup with vss support, so files should be recoverable even when they were in use during backup.
Security on the VHDX: I had issues at first after restoring the VHDX and letting the user logon, it didn't have access to his profile. I had to make sure the user had modify permissions on the folder and on the the (restored) VHDX.
Of couse, the ShrinkFSLtool is NOT supported by MS , but I didn't have any issues with it and it sure helps to keep storage usage within limits. (In fact, it's only a combination of running some supported commands on the VHDX to optimize the disk)
To those with successful FSlogix deployment: are you no longer using app volumes at all?
I wanted to implement FSlogix just to handle Office data, Outlook cache, search, etc. Keep DEM because I like the individualized app control, and App Volumes for attaching software (no writables for the most part). But I am finding that whenever I attach an app stack, the search index is corrupted and rebuilt at every logon. With no app stack it works fine.