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: http://community.citrix.com/x/A4AaAg).

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.

Today many users access their productivity applications using multiple methods.  This includes installed locally, published and/or streamed via XenApp (either as the mechanism to publish the app on XenApp or directly to the end point client).  So who is tired of re-creating their auto-signatures over and over?  One of the challenges is making sure your auto-signatures always follow you no matter how you launch Microsoft Outlook (as well as your other Office settings).

We also need to consider the other application settings like toolbar settings.  In Office 2007, changes to the toolbar are saved to a .qat file.  Microsoft has more details on these Office settings - http://support.microsoft.com/kb/926805/en-us

The below paths are for WinXP and WS2003.  For Vista, use AppData\Roaming\... instead of Application Data\... AND use AppData\Local\... instead of Local Settings\Applications Data\...  Although keep in mind in most scenarios you do not want to 'roam' local settings hence the name.  You would add (or verify they already exist) the below files and folders (or just the parent folder to capture everything) to the User Profile Manager settings to have them tracked and managed.

Files

• Local Settings\Application Data\Microsoft\Office\Access.qat
• Local Settings\Application Data\Microsoft\Office\Excel.qat
• Local Settings\Application Data\Microsoft\Office\Olkaddritem.qat
• Local Settings\Application Data\Microsoft\Office\Olkapptitem.qat
• Local Settings\Application Data\Microsoft\Office\Olkdistitem.qat
• Local Settings\Application Data\Microsoft\Office\Olklogitem.qat
• Local Settings\Application Data\Microsoft\Office\Olkmailitem.qat
• Local Settings\Application Data\Microsoft\Office\Olkpostitem.qat
• Local Settings\Application Data\Microsoft\Office\Olktaskitem.qat
• Local Settings\Application Data\Microsoft\Office\PowerPoint.qat
• Local Settings\Application Data\Microsoft\Office\Word.qat
  
  

Folders (Outlook)

• Application Data\Microsoft\Outlook
  • There are a number of files here that control/track configurations such as auto-complete, send/receive settings and tools, utilities and other add-ins configurations/settings
• Application Data\Microsoft\Signatures
  • These are all your signatures in various formats
• Local Settings\Application Data\Microsoft\Outlook
  • This folder (and all those in Local Settings) can be tricky since it stores offline folders (OST) and Personal Folders (PST files).  You may want your PST files to follow you but pending their size this can be an expensive file to roam.  And you can imagine the situations that will arise when two or more sessions are active simultaneously for these types of files - last write wins will definitely be a factor here and thus lost emails in the PST files.  For this reason Local Settings should probably not be roamed unless you are absolutely sure it is safe for a particular application.  Use file exclusion here as needed.
    
    

Folders (Office in general)

• Application Data\Microsoft\Office
  • ACL files (Auto correct entries) - http://support.microsoft.com/kb/926927
  • PIP files (personalized toolbar and menu settings) - http://support.microsoft.com/default.aspx/kb/193006
• Application Data\Microsoft\Templates
  • These are your office template files such as normal.dot/.dotm for Word and blank.pot/.potx for PowerPoint etc.
  • Again be careful here when using multiple versions (e.g. Office 2003 and Office 2007) - mixing can result in unpredictable results.
• Local Settings\Application Data\Microsoft\Office
  • Keep in mind in most scenarios you do not want to 'roam' local settings hence the name.  You would want to do this very selectively on a file by file basis.
    
    

I expect I covered the key areas for ensuring your Office settings follow your users.  Please let me know if there is anything missing or overlooked.

Previously I covered an overview of User Profile Manager as well as how it addresses last write wins.  Now I will cover profile bloat which is one of the more common user profile pain points.  Profile bloat creates unwieldy growth in user profiles and resulting storage and management issues (and the performance impact as profiles continue to grow in size).  So let's take a closer look at how User Profile Manager gives you control over this challenge.

Typically when using Folder Redirection or a roaming profile, the user's profile folders follow them as they move from system to system.  In a perfect world all your applications would behave properly and there would be no profile bloat. We know this is not the case and thus certain folders lend themselves to becoming very bloated fairly quickly.  Application Data is one of those folders, as applications may use it as a temporary folder (instead of the system's temp folder) and do not clean up the folder after the application ends.  This folder can become a graveyard of files no longer wanted or needed.  Or become a repository of files not really needing to be kept from one session to the next - temp files or cached data.  This folder can quickly become 100s of MB in size.

In a roaming profile scenario, this is a lot of data to be dragged around with a user.  With folder redirection, this becomes a lot of data to have to store somewhere - particularly if it's not really needed.  This becomes a painful process since the data may be getting copied back and forth with every logon and logoff event (although some optimizations within the profile contain the copying back to only files that changed).  In the case of XenApp servers where profile caches are almost always deleted upon logoff, all this profile data will have to be copied down again upon next logon.  Situations like this compound the pain we experience with unwieldy profile sizes.

With User Profile Manager you configure to exclude this 'extra baggage' causing that data to be ignored.  The payoff will be better management of the central storage resources (not storing extraneous files back to the user's central store) and this can translate to improved logon times since this extra baggage is not processed with the user's profile (which unless it is already cached on the machine the user is logon into, it will be copied down).

User Profile Manager provides the capability to fine tune the files and folders in a user's profile.  Now an administrator can explicitly include or exclude folders and files within a user's profile (and the ability to combine these such as to include a specific folder and exclude a subfolder within that folder).  For example, you might have an application called MyApp that creates and stores a multitude of supporting files in the \Application Data\MyApp directory (of which the subdirectory called '\MyAppStuff' is not needed).  You could include the root MyApp_ directory but then define an exclusion of the _\Application Data\MyApp\Stuff folder and upon logoff these files are left behind and not transferred to the user's central store.  If you have configured local profiles to not be cached, this extraneous data is just deleted at logoff with the cached profile.

By fine tuning and adjusting over time what is kept and not kept in the profile enables the profile size to be managed more efficiently.  For a start have a look at the INI files installed with User Profile Manager (in the target install directory) provided with UPM as they provide some good initial settings. And of course the profile size being reduced and less data being copied back at logoff can contribute to improved logon and logoff time.

There are two primary components to a user's profile - registry information and files.  This article will focus on the registry portion where last write wins becomes an issue.  While session sharing will mitigate this issue since only a single profile will be loaded (e.g. one session being shared by all apps equals one profile), there will be scenarios where multiple sessions occur or may be required and thus the potential for last write wins.  Specifically I will discuss the differences in how User Profile Manager functions over traditional roaming profiles when it comes to managing the NTUSER.DAT file (the user's registry settings also known as the HKEY_CURENT_USER or HKCU registry hive). 

During logon the NTUSER.DAT is copied down to the local machine the user is logging on (as well as the profile's files).  The NTUSER.DAT file contains the user's registry settings (HKCU) that are unique for every user (user being defined as a security account GUID).  The exception is when a mandatory profile is applied where all users share the same NTUSER.DAT (but then it's renamed to NTUSER.MAN).

During logoff, a roaming profile will copy the entire NTUSER.DAT file back to the central network share.  In this situation, the last session to end will have its NTUSER.DAT file saved.  Thus any settings in the 'previous' NTUSER.DAT on the network share will be lost if it happens to have changed since being copied down to the current session.  If the user has modified any profile settings in any of their active sessions, then the NTUSER.DAT file will have changed since the original version was copied down.

The difference with User Profile Manager is it will scan the current user hive (HKCU) and only writes back the changed registry settings.  User Profile Manager does this is by loading the 'centrally stored' DAT file called the 'user store' (file name is %USERNAME%.DAT) within the user's active session (in other words with the currently active HKCU hive) and performing a diff against that HKCU.  The results of the diff are then written into the user store.  It does not overwrite the previous NTUSER.DAT file.  So is this good?  It seems good, so let's take a closer look and see.

Let's look at roaming profiles and User Profile Manager using a simple example.  I have two separate XenApp sessions - one session has Microsoft Word and the other has Microsoft Excel (work with me for now on why there would be two sessions).  I make changes to my Microsoft Word application settings in the first session.  In the second session I make changes to Microsoft Excel application settings.  I close out the Microsoft Excel session first.  My roaming profile unloads and the NTUSER.DAT file is written back to the network share replacing the existing copy.  Then I close out the Microsoft Word session.  And again the NTUSER.DAT file is then written back to the network share replacing the one just copied back from the Excel session.  I've just lost my Microsoft Excel settings.  While I've used Microsoft Office applications for simplicity sake, this would be true for any two applications in this scenario.

What User Profile Manager does is as simple as easy: only save the net changes and merge them to the user store.  User Profile Manager's method is to scan the registry for changed settings and then write these settings to the user store DAT file on the network share.  Thus User Profile Manager 'merges' these changed settings into the user store instead of categorically copying back an entire DAT file over any previous DAT file at each logoff.  Thus different sessions being logged off will have their net changes written back to that central DAT file.  Goodbye to last write wins!

User Profile Manager provides an easy and reliable way to manage user personalization settings in Windows environments (the user's profile).  A user's profile consists of registry settings (stored in HKEY_CURRENT_USER) along with the files and folders (favorites, My Documents, cookies, Application Data etc).  The purpose of this article is to provide an overview and some details around User Profile Manager.  This will provide you enough to understand its core propose and for preparation to take a deeper dive into the technology.  The Technology Preview is available today for download (go here for links to the download site, Technical FAQ and other related items). 

User Profile Manager is a Windows service that monitors the logon and logoff process.  That means any user that logs onto a Windows environment with this service will have their profile managed by User Profile Manager.  E.g. installing the service on a XenApp server will enable all the users with sessions on that XenApp server to have profiles managed by User Profile Manager.

Let's start with the core files that are installed.  The MSI package (one for 32-bit platforms and one for 64-bit platforms) installs a Windows service (UserProfileManager.exe), two DLLs for Windows XP and Windows Server 2003 (upmHook.dll and upmLogonMonitor.dll) and some supporting files that I will cover a bit later (INI, ADM and ChangeLog.txt).  All of these are installed by default to \Program Files\Citrix\User Profile Manager.  Once installed, a new service will be listed (in the MMC Services plug-in or in Computer Management under Services) called Citrix User Profile Manager.

The service receives its configuration defining which users and what to manage in these users' profiles through a Group Policy Object (GPO) or an INI file.  The service will first read the GPO for its configuration and then check the INI file for any settings not configured in the GPO.  Typically you would use one or the other to manage configurations.  INI files are great for simple pilots and evaluations.  GPOs will offer better manageability and scale as you move into larger production deployments.  If neither the GPO nor INI exists, User Profile Manager will just manage the registry (and thus ignore any files or folders in the profile).  Please note that once you install User Profile Manager it will begin working using a default configuration (based on the INI files that were installed).

The INI files are installed in the target directory with an initial configuration.  There are two types of INI files installed: v1 (Windows Server 2003 and Windows XP profile) and v2 (Windows Server 2008 and Vista profiles).  Also installed in the same directory is the ADM template to be imported into your policies for creating User Profile Manager GPOs.

By virtue of these INI files, User Profile Manager works out of the box with a base configuration (HKEY_CURRENT_USER, My Documents, Favorites, Cookies, Desktop and Application Data etc - just read through the INI files for the full details).  This also means that if you choose to use or move your configuration to GPOs, you should delete or rename these INI files to avoid inadvertently having settings applied.  These INI files can be used as a starting point for your configuration and as a template for your GPO settings.

Once User Profile Manager is installed and a user logs onto that computer, User Profile Manager will manage the user's profile (registry settings, files and folders).  Within GPO settings the administrator has granular control over which users utilize User Profile Manager through AD Groups.  If the user does not belong to the specified AD Group, User Profile Manager will just ignore the user.  By default, all users (including local accounts) are managed and administrators are ignored (also can be configured in GPOs). 

Upon logoff, any net changes within the profile will be copied back to the central share (and only items that have changed).  The user's settings (DAT files, files and folders) are all centrally stored on the network in their defined HOME directory (which can be configured to be any UNC path).  The user now has all their settings and profile data (as defined in the configuration) following them reliably and consistently throughout their sessions.

Stay tuned as I will follow up this article with one that will dig deeper into how the registry settings are handled (NTUSER.DAT) in order to alleviate the 'last write wins' challenge.  As well as a look at how files and folders can by optimized to mitigate the 'extra baggage' challenge creating profile bloat issues (trust me, a bloated profile is not a pretty thing).

I look forward to any and all feedback on your experiences with this Technology Preview.

Have you seen or are you even aware of Citrix's Technical Video Library?  Well, consider this your official invite to watch these videos.  Educational format preferences are of course a personal thing.  Some people enjoy reading the books and admin guides while some prefer online training whereas others work best with instructor lead training formats.  Ultimately multiple formats must be available in order to best match the personal preferences of content as well as what works best for any given individual.  Thus enter our Technical Videos - not to replace any of our existing educational tools but a video format to deliver technical content on the more popular technology areas and topics.

The purpose of these videos is a focused and technical delivery on product features, architectures, capabilities and the basics of how things work.  The intent is to create a library of concise videos on numerous topics and subject areas.  If I want to learn the nuts and bolts of Presentation Server's architecture, then I can watch this 30 minute video in the library that covers what I need to know to get started.

These videos will cover the technical details and information that's required to get you knowledgeable, comfortable and moving forward in the right direction.  Now of course this is technology we are talking about so after one video we are not promising to turn you into a subject matter expert but they will certainly get you started.  We work to keep them in the 20-40 minutes range to make watching them easier and more flexible - hit just the topics you want, when you want.

Well, why are you still here - check them out now at http://www.citrix.com/techvideos. And of course, please comment on these current videos as well as let us know what other topics you would like to see delivered.