Helping FSLogix Help You… Only Better

Slow logons are a bane to EUC users. It’s one of those metrics where you can count the instances, measure how long they took, multiply it by your employee’s hourly rate and come up with the cost in lost end-user time. Speeding up logons or getting people to be productive as fast as possible is one of the promises of FSLogix.

For the most part, FSLogix works. The FSLogix profile container CAN improve logon times! The primary wins in reducing logon times that I’ve seen using FSLogix are removing the AppX Package Load Time that occurs on VDI machines (e.g. Microsoft “Preparing Windows” or “This won’t take long”)…

…and reducing the amount of time Outlook takes to load and have its search function fully operational.

Profile container technology such as FSLogix has dependencies that can cause performance problems. These dependencies can be network, storage, compute performance on the VM, etc. There has been some fabulous research on scalability of FSLogix by the Go-EUC guys here.

However, if you have FSLogix, and you encounter slower logons, the main method of troubleshooting is to use the FSLogix Profile Status tool, or just edit the log file directly. The FSLogix Profile Status tool nicely breaks out the sections of the feature, but the negative is that is all the filtering it does. It doesn’t filter temporally or by the user who is having the problem so it is still difficult to troubleshoot as you still need to find when the slowness occurred and for whom.

The ControlUp FSLogix Log Parser will read the FSLogix log file, and, by passing in the parameters for the user, session, and logon time this script can identify and display only the events from that time period for that user. I believe this will reduce your troubleshooting time by showing only the events when the slowness occurred. Not only does this reduce the amount of logging information you need to go through but the information is now specific to that slow logon event.

In this example, I encountered a slow logon. I was able to use the new Script Action to VERY quickly identify that the file was locked, which delayed my logon for 60 seconds. The delay is due to the LockedRetryCount reattempting 12 times, with a delay of 5 seconds per attempt. In reality, the delay was due to me logging into two different VDI machines where I have FSLogix configured for single user only — the first logon succeeding, the second attempting to access a file already in use and delaying out.

But using the FSLogix Log Parser I was able to quickly identify what happened, why, and I have some options for reducing my logon times by modifying these values or changing how I load profiles.