One of the common questions and quests around user profile solutions is improving logon speed.  Often there is an expectation that if the profile load time is addressed, my logon time issues are addressed.  This is not always the case.  There are other factors that influence the logon time.  Group Policy objects, global logon scripts and user logon scripts are other critical areas that have significant influence on logon times.  So let’s take a closer look at the influence the user’s profile has on logon speed.

User Profile Manager ‘might’ help improve logon time but it really depends on what is in the profile and what is consuming the time to load it.  Also keep in mind if you are currently using a mandatory profile (a size controlled profile that does not store any new settings from a user’s session) then moving to User Profile Manager will likely increase the size of the user’s profile (since now the user can add and create new settings, files and folders in their respective profile).  A larger profile means it will then take longer to load than the previous mandatory profile.  Of course the upside is the user now has a much more customizable and personalized experience.

Let’s compare User Profile Manager to roaming style profiles where the user’s profile settings are stored and will follow the user from computer to computer.  User Profile Manager may improve logon time significantly if these profiles are being weighted down by bloat.  User profile bloat is when there are many extra settings, files and folders in the user’s profile that are not needed but are still being captured and stored (here is a blog on profile bloat:

With User Profile Manager, you can granularly define what is included and what is excluded in a user’s profile. This includes using combinations of includes and excludes to further refine and target only what is absolutely required to be in a user’s profile.  Thus by managing the size, the time it takes to copy down is optimized and improved.

But if everything in the profile is necessary and needs to remain in the profile, now we have a traditional bandwidth challenge.  How do you get data from point A (on the network) to point B (on the windows device) more efficiently and more quickly?  As there is much improvement that can be done in this area, it will be a focus area of User Profile Manager over future releases.

Next let’s cover the question of how do I know if the profile is dragging out the login time.  It could be the profile is very large and the time it takes to copy down to the system creates logon lag (which often feels exactly like jet lag).    One option is to allow Windows to cache the user’s profile.  By caching and thus retaining the profile on the local drive, only changed or updated files in the profile are copied down on next logon to the device.

While caching profiles may be fine on individual devices and desktops, not so much on a XenApp server when you could have 100s or 1000s of users (or even more) passing through.  In fact on XenApp based deployments you almost never want to cache the user profile (is there ever anything in technology that is an absolute).  While caching will certainly speed up logon time, it turns your server into a profile storage device which can easily translate into gigabytes and gigabytes of storage on that local drive.

So how do you figure out how much overhead the profile (or even part of the profile) is adding to the logon?  Based on finding this answer you will better be able to determine whether User Profile Manager will benefit logon time.  User Profile Manager offers the ability to extensively log the activities during logon including the time each activity required.

Not only is the profile loading process logged (NTUSER.DAT, files and folders) but also times querying AD, getting correct paths, etc. will be logged with time stamps.  In order to capture the user specific logging, please ensure that users have write access to %systemroot%\system32\LogFiles\UserProfileManager (the default Windows log directory).  Since users do not typically have write access here, you should add the user group “Authenticated users” to have write access to this directory.

So now that logging is enabled and you have logged on and off with some user accounts, let’s take a look at what you have now.  At the end of the loading process of the profile, UPM summarizes this. Here’s an example log entry:

2008-10-12,15:44:46.552,INFORMATION,SEPAGO,Joe,2,DispatchLogonLogoff: -——–- Finished logon processing successfully in [s]: <2.28>.

*Tip*: Always search for “——-- ” to get starting and end points of logon / logoff events with accumulated information.
Wow, 2.28 seconds to process the logon -- this would be a great performing environment (this example was only processing the Registry and not files).  If the time captured was similar to “Finished logon processing successfully in [s]: <20.00>.” (or more) you should have a look at the single timestamps in the logfile and identify if a big gap exists between two entries.  That is presumably the point you can start searching for what is going wrong.

If there is no such gap, have a look at the profile size. Back to the earlier discussion, if everything needs to be in a 2 GB profile, then this becomes a different discussion.  A discussion we should have someday soon.