Did FSLogix Just Kill Legacy Profile Management for Server-Based Computing?

Not long after their first funding round and winning Best of Citrix Synergy 2015, FSLogix has built a pretty amazing feature into their already very effective solution. In the past I wrote a few articles about some other features, such as Font Management and Java Version Management (see Managing Multiple Java Versions with FSLogix Apps for more info). When I saw that they released a beta of their new FSLogix Apps 2.0 with a feature called profile containers, I had to take a look, and asked Brad Rowland to hook me up with a trial. I was not disappointed.

Take a look at this graphic that shows file reads overhead of FSLogix Apps 2.0 vs. other profile management solutions. Thanks to their new approach to the architecture, FSLogix is only reading a single file instead of the thousands or more that are usually read within every single profile. You can probably imagine just how much benefit this brings to the table. See the full article here GOODBYE legacy profile management.


Profile management has never been the funnest part of IT. I remember my days with the headaches of roaming profiles and endless complaint calls to the help desk, “It’s so slow logging in to my desktop”. No matter what environment you were working in, whether it was folder redirection through group policy, Citrix UPM, Roaming Profiles or whatever the solution of the day, just the site of the documentation could make your head spin. No matter how good you are with profiles there are so many moving variables involved that problems tend to result in loss of data and recreating profiles, or super slow logins and sustained CPU spikes on your file servers. Seems like people have focused on trying to optimize a broken model.

So going into the testing, I was expecting this to be complex and time consuming. I thought I would be writing a long article about the various intricacies of setting it up and managing it. I couldn’t have been more wrong. In fact it was so easy that I had it set up before I even knew it.

After installing FSLogix Apps 2.0, there are a few registry entries that need to be created (this would be a great thing to add to the UI), one of which points to one or more paths to search and store profiles. These can be local folders or network shares. For an existing profile that you want to convert, you just run a command line utility and the profile is converted for you. Here is the part that really impressed me. The computer I was testing on only had the Admin account, so I created a standard user account (and logged on with it) so a local profile would be generated for me to convert. When I went back to my Admin account I looked in the users folder, but there was no profile there, only a symlink. I checked the share I specified as my profile container and sure enough the user profile was there and I did not have to do anything else. At this point, any machine I logon from with FSLogix installed, will automatically grab that profile and log me on with it. That’s all there is to it.

Aside from ease of management, the biggest advantage in VDI and Xenapp of moving to the FSLogix profile container approach is user and server performance. Looking at my own experience and some of the FSLogix test numbers I can see how they’re getting an astounding 85% reduction in login times. I’d like to do some larger scale testing to prove this out, but I’m only seeing a fraction of file open activity and network traffic.

FSLogix has done a great job at getting another piece of enterprise technology re-architected, not just more optimizing, but a new design that eliminates the problem altogether. In the case of user profiles on server-based computing, this change is long overdue.

By |2017-07-22T13:02:51+00:00June 1st, 2015|Categories: Featured Post, Virtualization|Tags: , , , |1 Comment
Translate »