While a mandatory based profile solution was the original approach (something we leveraged in the earliest releases), we are not going to return to that method. Let me explain why and get your thoughts and opinions on this.

One request that has been commonly voiced has been around a mandatory style implementation. While previously we had leveraged a mandatory profile as the base, for many reasons we moved away from that approach. One key reason was to save time that the merging process required (the copying of the mandatory down first and then copying of all the net changes). All in the spirit of logon speed. Another key reason is that it really was not a mandatory profile anymore. Profile management captured all the net changes from that base mandatory. So no settings were enforced or re-written at next logon. Basically it was a holder of starting settings when a profile was loaded. But the net changes were always re-applied over the base so nothing was ever enforced. So in the end, you needed to leverage Group Policy to enforce any permanent settings anyway.

It's also been explained that having a mandatory approach enables customers without Group Policy delegation to have a means to control the profile settings. And mandatory by itself is a great solution albeit the limitations on the breadth of personalization - which the amount of personalization afforded by a mandatory solution is probably adequate for many scenarios. While you can redirect folders like My Documents, Favorites, Cookies and others, the ability to change anything registry related is prevented e.g. wallpapers, application configurations and such. But if you try to combine this with something like Profile management to enable those changes, how are you going to restrict what does not get saved? You would need to create an exclusion list of all the settings you want enforced (and thus excluded from being saved). Doable on a few settings but it will get unwieldy really fast. And I am willing to bet it's going to be harder than Group Policy to manage before long. In the end, it seems capturing all the settings and using Group Policy to enforce setting as required is the way to go and thus the direction for our profile management solution.

Finally, let's address the capability of having a base profile to start with. We do offer a template profile capability which you could think of as a Global Default User profile. When a user logs onto Windows and does not have an existing profile (be it local, mandatory, roaming or TS), Windows creates a new profile for that user based on the Default User profile located on that current machine. The fun of this is unless you want to sync all the Default User profiles across all the machines a user might likely log onto for the first time, the starting profile will different (although often only slightly) from user to user. Might not be a big deal initially or on smaller scales, but will be more problematic as your environment expands and grows.

The purpose of the template profile is to enable a consistence starting point for a new profile being created no matter the machine. The template profile can leverage a copy of the mandatory profile you use today but you just need to rename the NTUSER.MAN back to NTUSER.DAT (so no you can't use the same one as both the template and a mandatory). And the template profile has to be complete (e.g. the entire directory structure and NTUSER.DAT). Also keep in mind that this is used for profile creation. So changing the template is fine, but only affects new profile being created and not existing ones. Need to change or enforce a setting for all users? Then we are back to using Group Policy for those situations.

So that is where we stand today with our Profile management feature (a feature of both XenApp (Enterprise and Platinum) and XenDesktop (Advanced, Enterprise and Platinum). Of course this is always open to debate and discussion if you have scenarios that illustrate weaknesses to this approach that Citrix should pay more attention to addressing.

You may already know about this feature as it was previously called User Profile Manager. Profile management is the new name for User Profile Manager. This technology is a feature of both XenApp (Enterprise and Platinum Editions) and XenDesktop (Advanced, Enterprise and Platinum Editions). For a more detailed overview of what Profile management is and how it works to improve application virtualization, please read this article. For this article I will focus on the improvements in this updated feature that will first be available in XenApp 5 Feature Pack 2.

The improvements added into this release have focused around improved logging, Citrix product line integrations and Windows 7 support (really just testing and validation as the profile mechanism did not significantly change in this release from Vista and Windows Server 2008). And of course we have fixed many of the known issues and support concerns.

We've introduced EdgeSight counters to add visibility into the logon process and activities. Here is a summary of the counters that are provided:

• Logon Duration - this is the total logon time.
• Local Profile Setup Duration - aka the time to set up the user's local profile. Basically this compromises of the following steps:
  • Does the user have a local profile - if not create one
  • Is a profile migration required? If so migrate the profile
  • The time to copy down files from the user store to the local profile location
  • Synchronize with user store. This is only needed at logon for a new profile. While a Microsoft roaming profile copies a new roaming profile back to the network at logoff, Profile management performs this activity during that first logon.
  • At this point Profile management gets notified that this profile is ready to be managed
• Time to Start Monitoring - this is the gap from the last step of notifying Profile management that a profile is ready to be monitored and until monitoring actually starts (meaning the user is allowed to start their session). This consists of processing the NTFS change journal entries (basically a start point for monitoring file changes). The purpose of this counter is to help narrow the area causing longer than expected logon times. This should be fairly short time period and if not, you know something is happening out of the ordinary here. How short should it be - defining your baseline will provide you that measurement.
• Logoff Duration - this is the total logoff time
• Stop monitoring profile - NTFS change journal processing. This time should be very short
• Logon Bytes - total bytes in the user's profile copied down at logon
• Logoff Bytes - total bytes from the user's profile copied to user store at logoff
• Processed Logon Files - total number of files in the user's profile copied down at logon. How many files and their respective size grouping.
• Processed Logoff Files - total number of files from the user's profile copied to user store at logoff. How many files and their respective size grouping.

We also focused and extended on XenDesktop and Provisioning Server testing and validation. A key aspect of this was the new log file redirection capability. Now administrators can configure the log file to any local drive instead of the default %WINDIR%/system32/LogFiles/ location. This addressed the critical issue of capturing a log file from a local drive that is reset at logoff. The log file being just another changed file from the session is thus lost when system is reset at logoff.

I also would like to add clarification around the extended synchronization capability. Extended Synchronization was introduced in the User Profile Manager v2.0 release. It become apparent we were not clear enough in the context of its purpose and often it was being leveraged beyond its scope and ability. It was designed to enable personalization settings that are not properly stored in the user's profile location to be captured as part of the user profile. So-called "bad applications", for example, store settings in non-standard locations. However, the capability was not documented clearly in the Version 2.0 administrator's guide, which resulted in attempts to use the feature in ways for which it was not designed. We have clarified the supported scenarios in this release.

Extended synchronization is not intended to manage multi-user access to these files or folders (for example, we are not compensating for an application that is not multi-user aware). Nor is it intended to become a file and folder synchronization mechanism (for example, one that allows you to synchronize the entire contents of c:\docs across machines). It is intended purely to extend personalization settings that exist outside the default user profile location and thus provide a consistent experience across all resources accessed by the user.

This latest version (2.1) will be available for download on September 29th 2009 via MyCitrix. So now that you know a little more about Profile management, I recommend you check back on the 29th to MyCitrix and grab a copy (logon required) to evaluate and consider for your environment. Please note that it is important to review the current profile technologies available and ensure a good match with your business needs. There are a broad range of solutions and ensuring a good match is critical in order to properly balance the administrative needs with user personalization needs. You should review this best practices guide covering profile options such as mandatory, roaming and of course Profile management.

Finally, if you would like to learn more about Citrix XenApp 5 Feature Pack 2 here are some useful links:

• Official Press Release - http://citrix.com/English/NE/news/news.asp?newsID=1857726
• XenApp 5 Feature Pack 2 release Web Site - http://citrix.com/xenapp/featurepack2
• XenApp 5 Feature Pack 2 Executive Video - http://citrix.com/xenapp/fp2/video
• XenApp 5 Feature Pack 2 Release Webinar - http://citrix.com/xenapp/fp2/techtalk
• XenApp Expert Series videos for this release - http://citrix.com/xenapp/fp2/expertseries
• XenApp 5 Feature Pack 2 Blogs- http://community.citrix.com/blogs/tag/xa5fp2
• Download XenApp technology previews - http://citrix.com/xenapp/techpreviews
• XenApp Product Page - http://citrix.com/xenapp/

Follow XenApp on | | |

When you're setting up a User Store for Profile Management, you configure the location in the GPMC under "Path to user store" (as described in http://support.citrix.com/article/CTX118944 ), and in the simple case, that's a single location, such as \\server1\profiles . 

(Actually, you'd also include the username and probably the userdomain variables as well, and a system environment variable to indicate the profile version or platform e.g. \\server\profiles \ %USERNAME%.%USERDOMAIN% \ %ProfVer . However, it all gets very verbose, and I'll assume you can add these bits yourselves in the discussion below.)

Anyway, we've had a couple of requests recently on how to load-balance User Stores for Profile Management across multiple servers, and we came up with a couple of approaches which might be helpful generally.

A couple of reasons for load-balancing came to light:

• simply to balance the load across several servers
• where an organisation operates several datacenters, each serving one or more geos.

The customers didn't want to use DFS, because they recognised that replication would take place of all profiles between all DFS servers, which would waste bandwidth. I seem to recall that Microsoft doesn't recommend DFS for storing profiles, anyway.

One administrator asked if he could use %homeshare% on the assumption that %homeshare% ought to reference a local server.  No, because %homeshare% is a user environment variable, and Profile Management can't see user environment variables ... but AD does have a property #homeDirectory# which holds the same information.  So if you're OK to put profiles on the same share as the users' HOME directories, configure the "Path to user store" as #homeDirectory#\profiles

The other approach is more general, and may require some AD configuration and/or some DNS hackery.

If you can find an AD attribute, such as #c# (country) or #l# (location - that's #L# but lower case), then the job may be easy - just set the "Path to user store" to \\FileServ#c#\profiles (say) - this should expand to \\FileServUS\profiles or whatever your country happens to be.  Similarly #l# could be used, but if your office is in "Ashby de la Zouch" or "Llanfairpwllgwyn..." (you know the place I mean, in Wales) that may cause grief when used as part of a server name!

So if there are spaces or just a very long name, you'll have to get your AD admins to create and populate a new attribute, such as #geo#

What if you've got a #l# attribute, short, with no spaces, but you want to map several different values to the same server?  In Citrix, for example, we have several geographically close offices sharing a single datacenter, and some offices which have had different names in their history, e.g.

Chalfont (CHF), High Wycombe (HW), Gerrards Cross (GX) and even London (LON) all actually refer to the same office, so \\FileServ#l#\profiles will expand to

\\FileServCHF\profiles or \\FileServHW\profiles etc...

The trick here is to configure multiple names in DNS with the same IP address, so that, regardless of what's configured in #l#, it all maps to the same physical server.

XenApp Expert Series - Profile Management Part 1 - Informational, News, Interviews (2009) The show where we interview the experts to get you the latest research and technology news on XenApp application virtualization. Host Vinny Sosa (@vinnysosa) interviews Citrix Product Manager Dave Wagner on the Profile Management feature of Citrix XenApp and XenDesktop and why this is key technology in the application and desktop virtualization stack. This is part 1 of 2 where we will bring Dave and/or another expert in to dive deeper into Profile Management. Episode 2, Season 1.

ADDITIONAL BACKGROUND: My intro would have been funnier but I totally screwed it up. I have a strict one take policy on the show though so it stayed as is. Dave is a great character. He has been with Citrix for 8 years 6 months 15 days and 7 hours by the start of this recording. While here, he has managed a number of products including Access Essentials, MetaFrame for UNIX, Conferencing Manager, MetaFrame x64, Desktop Broker/Server, Password Manager, Profile management, Web Interface, and the Linux Client. He doesn't have a Twitter account (yet!). He says he's still too busy jumping on the JAVA/Linux Desktops/Webify Everything bandwagons. After which he needs to jump on the Facebook bandwagon. He loves photography followed closely by video games ... xBox addict at the moment but that usually shifts around every few months. Why? He says he likes video games primarily because it annoys everyone else to think that it's a total waste of his time. Join us for this interesting episode with David Wagner.

Listen to this episode

• Listen to archived episodes:
  • Episode 1: Power Management with Sridhar Mullapudi

Follow XenApp on Twitter

Download XenApp technology previews

XenApp Expert Series - Profile Management Part 1 - Informational, News, Interviews (2009) The show where we interview the experts to get you the latest research and technology news on XenApp application virtualization. Host Vinny Sosa (@vinnysosa) interviews Citrix Product Manager Dave Wagner on the Profile Management feature of Citrix XenApp and XenDesktop and why this is key technology in the application and desktop virtualization stack. This is part 1 of 2 where we will bring Dave and/or another expert in to dive deeper into Profile Management. Episode 2, Season 1.

ADDITIONAL BACKGROUND: My intro would have been funnier but I totally screwed. I have a strict one take policy one the show though so it stayed as is. Dave is a great character. He has been with Citrix for 8 years 6 months 15 days and 7 hours by the start of this recording. While here, he has managed a number of products including Access Essentials, MetaFrame for UNIX, Conferencing Manager, MetaFrame x64, Desktop Broker/Server, Password Manager, Profile management, Web Interface, and the Linux Client. He doesn't have a Twitter account (yet!). He says he's still too busy jumping on the JAVA/Linux Desktops/Webify Everything bandwagons. After which he needs to jump on the Facebook bandwagon. He loves photography followed closely by video games ... xBox addict at the moment but that usually shifts around every few months. Why? He says he likes video games primarily because it annoys everyone else to think that it's a total waste of his time. Join us for this interesting episode with David Wagner.

View this Episode and Subscribe to the XenApp Expert Series

Follow XenApp on Twitter

Download XenApp technology previews

I thought I would share some useful links that I tend to end up emailing around. Also a couple links to a some really useful tools for User Profile Manager (brought to you by our friends at Sepago).

First is a migration tool that enables customers to migrate from the sepagoPROFILE profile format to User Profile Manager v2 format. It also lets customers migrate from the Tech Preview version of User Profile Manager (as both the Tech Preview and sepagoPROFILE releases were based on a mandatory profile). Details and the tool are here: http://blogs.sepago.de/tools/category/citrix-user-profile-manager-migration-tool/

Next is a tool that helps prune your profiles of old or unwanted data. One of the biggest challenges with Windows profiles is removing unwanted items. All those registry settings or APPDATA files after an application is removed or just no longer used. Or perhaps some settings were captured unintentially and now you want to get them out of all your users' profiles. Let me introduce you to the ProfileNurse (stop your smirking) – full details and the tool can be found here: http://blogs.sepago.de/tools/category/profilenurse/.

While ultimately we will like to see this capability as part of the product, for now this nice tool helps fill this gap. Available operations in ProfileNurse include:
*Creating and deleting registry keys and values
*Altering registry values
*Deleting files or folders
*Copying files or folders into user profiles

And here is the basket of other links I've found useful:

General
http://www.citrix.com/upm Main Page with links to downloads (downloads are actually under XD and XA product sections)
https://www.citrix.com/English/ss/downloads/results.asp?productID=186 XA download page (Under Components and Evals)
https://www.citrix.com/English/ss/downloads/results.asp?productID=163057 XD download page (Under Components and Evals)
http://forums.citrix.com/category.jspa?categoryID=163 Support Forum

Product Docs
http://support.citrix.com/article/ctx118943 Admin Guide
http://support.citrix.com/article/ctx119791 Technical FAQ
http://support.citrix.com/article/ctx119747 Licensing FAQ
http://support.citrix.com/article/ctx119466 Logon/Logoff Chart
http://support.citrix.com/article/ctx119039 Cross Platform Considerations FAQ
http://support.citrix.com/article/ctx119038 Troubleshooting FAQ
http://support.citrix.com/article/ctx118944 Group Policy Template Reference
http://support.citrix.com/article/ctx119186 Using with XenDesktop
http://support.citrix.com/proddocs/topic/xenapp/upm-xa-wrapper.html Using with XenApp

Best Practices
http://support.citrix.com/article/CTX119036 Best Practices
http://support.citrix.com/article/ctx120285 User Profile Best Practices (XenApp 5)
http://support.citrix.com/article/CTX110351 User Profile Best Practices (CPS 4.5 and prior)
http://support.citrix.com/article/CTX114884 - Password Manager Best Practices

Overview
http://community.citrix.com/x/AoEAAg (overview and insight on UPM)
http://community.citrix.com/x/OIENAg Last Write Wins
http://community.citrix.com/x/A4AaAg Profile Bloat
http://community.citrix.com/x/SIOZAg UPM and Office Settings
http://community.citrix.com/x/HYXuAg Improve logon speed?
http://community.citrix.com/x/AwBeAw Differences from Tech Preview and v2
http://community.citrix.com/x/8ICsAw Using GPOs
http://community.citrix.com/x/3IGiAw Quick Setup Guide

Sepago
http://blogs.sepago.de/tools/category/adm2html/ - ADM to HTML
http://blogs.sepago.de/helge/2009/01/23/citrix-user-profile-manager-released-user-store-design-recommendations/ - User Store
http://www.sepago.de/citrix/upmwhitepaper.html Sepago White Paper
http://blogs.sepago.de/helge/2009/02/25/citrix-user-profile-manager-how-registry-exclusion-lists-can-mess-up-group-policy-processing/

Microsoft Office:
http://technet.microsoft.com/en-us/library/cc768089.aspx - Configure Outlook settings
http://office.microsoft.com/download/afile.aspx?AssetID=AM102105061033 - Outlook 2007 setup automation
http://office.microsoft.com/en-us/ork2003/HA011402061033.aspx - Office installation recommendations
http://support.microsoft.com/kb/926805/en-us - Office 2007 Toolbar settings
http://office.microsoft.com/en-us/ork2003/HA011402691033.aspx - Recommended strategies for Outlook roaming

Microsoft Profiles
http://technet.microsoft.com/en-us/library/cc784484.aspx - Best Practices for Roaming Profiles
http://technet2.microsoft.com/windowsserver/en/library/fd81008e-269a-4155-b81a-752242bec9ff1033.mspx?mfr=true - User Profiles Overview in User Data and Settings Management
http://technet2.microsoft.com/windowsserver/en/library/fd81008e-269a-4155-b81a-752242bec9ff1033.mspx?mfr=true - Folder Redirection Overview
http://blogs.technet.com/neilcar/pages/247903.aspx - SMB/CIFS Performance Over WAN Links
 
Microsoft
http://msdn.microsoft.com/en-gb/library/ms675090.aspx AD Attributes
http://technet.microsoft.com/en-us/sysinternals/bb963907.aspx - AD Explorer

An update to User Profile Manager was released a few weeks ago (v2.0.1). This contains fixes and improvements for some known issues such as:

• Support for the user variables %USERNAME% and %USEROMAIN%. This enables explicit paths to be defined for users when supporting multiple domains
• Profiles are now migrated properly when defined by the GPO "Set path fopr S Roaming User Proifle"
• Addressed the issue of unresponsive logons in certain cases with cloned images or provisioned shared images
• Resolved the issue with default registry exclusions and the conflict it created with Windows caching of group policies

The full details are here: http://support.citrix.com/article/CTX120967

The documentation when using with XenApp is located here: http://support.citrix.com/proddocs/topic/xenapp5fp-w2k3/upm-xa-wrapper-v2.html

And the documentation when using with XenDesktop is located here: http://support.citrix.com/proddocs/topic/xendesktop/upm-xd-wrapper.html

This updated install package completely replaces the previously posted package (and thus the old one is no longer available). You may run this install on existing deployments and it will upgrade your service. As well as use it for a fresh install. BUT defintely upgrade any existing installs before rolling out this new version since you do not want to mix the versions in your deployment (and thus have some services that recognize variables like %USERNAME% and some that do not). I assure you it would not be a very pleasant experience. The UserProfileManager.exe binary version is 2.0.1.48.

The ADM template was updated but it was just helper text updates. Basically calling out items like the added support for %USERNAME% and %USERDOMAIN%. So you do not need to update the ADM template unless you want to read the new helper text or just enjoy updating ADM templates. Or you can just open up the ADM file in your favorite text editor and scroll to the end and read it there.

On a side note here are some links to the main page, support forum and XenApp/XenDesktop download site (you need to be logged on to MyCitrix to see the downloads – and it is the same download so pick either product and look in the in the Evaluations and Components sections). And yes, the official name for this is Profile management which you will see reflected in the next release.

Main Page http://www.citrix.com/upm
XA download page https://www.citrix.com/English/ss/downloads/results.asp?productID=186
XD download page https://www.citrix.com/English/ss/downloads/results.asp?productID=163057
Support Forum http://forums.citrix.com/category.jspa?categoryID=163

I thought I would let you know about a little gotcha that I bumped into this issue yesterday.

So you are using Citrix User Profile Manager (a.k.a Profile management), you have installed it on machines running on VMware, (possibly in your XenDesktop or XenApp set up) probably because no-one has told you that you can get XenServer for free! 

You have your User profile Manager GPO settings to delete the cached local profiles when the user logs off, only they won't.....

...read on.

I had VMware tools installed on my XenApp server running on ESX 3.5 (I have some on XenServers too, I have make this clear before the XenPolice come and get me...)

I had installed the tools using the complete install. Little did I know that with a roaming profile of any variety this can cause issues. The "Shared Folders" option in VMware tools put a little file in your users profile, which gets locked by a running process. Consequently if you have a GPO set up to delete the users profile at log off, the system can't because of this pesky little file, namely;

C:\Documents and Settings\userid\Application Data\VMware\hgfs.dat

Your Profile management log (C:\Windows\system32\LogFiles\User Profile Manager\UserProfilemanager.log) will probably have an entry in it like the following: (if you have all the log options enabled in your GPO that is!)

2009-06-03;11:44:31.456;ERROR;PCNAME;johncarthy4;3;3640;DeleteDirectory: Deleting the directory <C:\Documents and Settings\johncarthy4\Local Settings\Application Data\VMware> failed with: The directory is not empty. 

Here's the quick fix:

1. If its XenApp log all your users off the server, preferably politely, send a warning message or if your feeling particularly ruthless a quick "session reset" will surely get them ranting at the helpdesk...

2. Login as an Administrator go to Control Panel - Add remove Programs.

3. Find VMware Tools and choose the "change" option.

4. Change the "shared folders" to "This feature will not be available".

5. Click "next", Click "Modify" and click "finish".

6. Restart the server / PC and now it's a good time to clean up those half deleted profiles.

7. Its best to use the My Computer - Properties - Advanced - User Profiles and select the remnant profiles and delete from here, this way you will always see any issue as Windows will kindly inform you of any difficulties by means of an error message...

Now I also found this to be the case on an XP vm that I had running on the same VMware server. The bizarre thing is that even if you click over the tools icon next to the clock, and check the settings, it said that the shared folder option was disabled, herein lies the difference, you will still see this issue even if the system is set to use Shared Folders, you just have to make sure it isnt installed at all.

Here's the other slightly longer fix:

1. Download XenServer.

2. Install your VM's on that.

3. Install Profile manager.

I hope this helps some of you. 

We're quite pleased with the new version 2 release of User Profile Manager, but of course there are new features being planned already. (Note that going forward, the name User Profile Manager will be dropped, and future versions will carry the name "Profile management" or Pm.)

Without going into details, we're looking at features to improve both performance and usability. What does that mean for current users of Pm, though, and what provision should they make as they roll out their v2 deployments to minimise the disruption when versions 3 and 4 come along?

First of all, there's the design of the User Store. If you're using Windows XP and/or Windows 2003, you'll be using "version 1" profiles, and if you're using Windows Vista or Windows 2008, you'll be using "version 2" profiles. That's Microsoft's terminology, but it can get really ambiguous when I'm also talking about Pm versions, so I'll refer to Windows XP and Windows 2003 profiles as Win5 profiles. Likewise Windows Vista and Windows 2008 profiles can be grouped under the term Win6 profiles. As an aside, it's looking like Windows 7 profiles share the same format as Vista and 2008, so at the time of writing, it looks like Windows 7 is also covered by the term Win6.

So what we're expecting is that you'll put both your Win5 and Win6 profiles on the same server, and we expect that you'll set up your User Store as suggested by Microsoft's article http://technet.microsoft.com/en-us/library/cc757013.aspx (Security Recommendations for Roaming User Profiles Shared Folders). For the sake of example, let's say you have the User Store set up as the share //OutlawSrv1/profiles/ . Pm lets you configure paths using Active Directory attributes, so you might use either #cn# or #sAMAccountName# to define the next level. Again, for the sake of example, let's use #cn#, giving us a path of //OutlawSrv1/profiles/#cn#/ . If we do this, all the different Pm directories we're going to create will just inherit the permissions from the top level directory, which is exactly what we want.

Now we recommend setting up a System Environment variable to differentiate between Win5 and Win6 profiles at the next level. Pm lets you incorporate System Environment variable into the profile path, by enclosing the variable in percent signs. In our example, we'll set up a System Environment variable %ProfileVer% which will take the value "v1" on Windows XP and Windows 2003 systems and "v2" on Windows Vista and Windows 2008 systems. So now the complete path you configure in the Pm GPO is //OutlawSrv1/profiles/#cn#/%ProfileVer%/

Here is the User Store layout that results:

//OutlawSrv1/profiles/William/v1/
                     .       /v2/
                     /Douglas/v1/
                     .       /v2/
                     /Henry/v1/
                     .     /v2/
                     /Ginger/v1/
                     .      /v2/

Sorry if that's a bit long winded, but it's important to understand that this is the basis of our planning for the next versions of Pm. We're going to assume that new features will be able to slot in alongside the v1 and v2 directories above, so that Pm v3/v4 will build per-feature data on the directory structure above, giving:

//OutlawSrv1/profiles/William/v1/
                     .       /v2/
                     .       /feature1/
                     .       /feature2/
                     /Douglas/v1/
                     .       /v2/
                     .       /feature1/
                     .       /feature2/
                     /Henry/v1/
                     .     /v2/
                     .     /feature1/
                     .     /feature2/
                     /Ginger/v1/
                     .      /v2/
                     .      /feature1/
                     .      /feature2/

That's the first recommendation. If you're only interested on how to future-proof your Pm installation against future Pm feature updates, you can stop reading here.

The next recommendations are about how you might manage upgrade scenarios. Typically, you've got Pm v2 deployed, and you'd like to take advantage of the new features in Pm v3 or Pm v4. Unfortunately, we don't expect to be able to offer co-existence of different Pm versions. Specifically, for any given user, all machines that he uses must be managed by the same version of Pm. Otherwise, older versions of Pm will just ignore the new feature directories, and will make changes in the v1 or v2 directories without making corresponding changes in the feature directories. Result: a corrupt profile - precisely what Pm is supposed to avoid!

The first step in solving this problem is that we'll be providing compatibility flags in the configuration of all future versions of Pm. If Pm v3 (say) can't find a configured compatibility flag, it reverts to the Pm v2 functional level. Similarly, if the flag is turned off, it operates at the Pm v2 functional level. So it's OK to install newer versions of Pm over the top of older versions - they'll work correctly. Likewise, the configuration of Pm v3 will be designed to be a superset of Pm v2, so you can replace the v2 ADM template with a v3 ADM template and Pm v2 will continue to operate correctly. (BTW, you're probably better off removing INI files, they could cause problems. My personal opinion is that INI files and production farms don't mix.)

There are two difficulties:

• AD changes don't propagate through the forest instantaneously, so we have to avoid the situation where some instances of Pm v3 have been told they can now operate at Pm v3 level, while others haven't seen the group policy update and continue to operate at Pm v2 level.

• You can't (in general) be sure that you've found and updated every copy of Pm v2 to Pm v3, so regardless of what group policy says, some copies of Pm can only operate at Pm v2 level

There are two obvious ways around this problem.  Neither solution is particularly elegant (so we're working on improvements), but these give the flavour of how to do it.

The first is applicable in small networks, where you can be sure that you've managed to upgrade every machine.

1. Replace the Pm v2 ADM template in the GPO with the new Pm v3 template. Set the compatibility flag to off (0)
2. Upgrade all machines to Pm v3
3. Make whatever other changes you need to migrate (as per Pm v3 administrator guide)
4. At a scheduled maintenance period, log everybody off
5. Make the necessary configuration changes and set the compatibility flag to 1
6. Wait for the group policy changes to propagate - maybe run gpupdate on each machine to force the update
7. Let everybody log on again, and watch the fun.

Hmm, that might work in a small network, but you don't have much of a backup plan if it goes wrong. It's a "Big Bang" approach.

There's another way, which gives you a bit more safety, and makes it easier to revert if something goes wrong. It makes use of the processed user group feature of Pm.

The idea is to create a new OU to contain all machines that have been upgraded to Pm v3 and a new group which contains the all the users allowed to use those machines. Initially the OU is empty and the group has no members.

(The OU will most likely be a set of OUs, covering each of the different OS types, but we'll keep it simple for now. We'll call that OU "V2OU")

Step 1: If you have not already done so, ensure that all the users of the Pm v2 machines belong to a group, and configure this group as the processed group in the Pm v2 configuration. Let's call that group "V2Users"

Step 2: Create a "mini-farm" in the new OU. We'll call that new OU "V3OU" - again it could be several OUs, but we're keeping it simple. You could move some unused machines from V2OU into V3OU, or you could build fresh machines. Ensure that V2Users are directed to machines in V2OU, and V3Users are directed into V3OU (this will involve some XA / XD changes outside the scope of this article). Install and configure Pm v3 on all the machines in the mini-farm, with the v3 feature level enabled. For this OU, make the processed group V3Users.

Step 3: Now you can migrate your first department of users. Get them all to log off and remove them from V2Users. Back up their profiles.

Step 4: Add them into V3Users and ensure that their sessions are now directed to V3OU.

Step 5: Let the users from the first department log on. Pm v3 will migrate their profiles on-the-fly to the new structure.

Step 6: Having transferred some users out of V2OU, you should now have a bit of spare capacity in V2OU. Transfer some more machines out of V2OU, upgrade them from Pm v2 to Pm v3, and transfer them in to V3OU. Migrate your next department (steps 3-5)

Step 7: Repeat step 6 above until all machines and all users are using Pm v3.

Phew!!

Hopefully there weren't any problems with that. You migrated your users in small batches and if a problem did show up, you could revert that department to their backed-up profiles until you could fix the problem.

Job done!

We were doing a benchmarking exercise recently, comparing the performance of an (untuned) User Profile Manager against standard Roaming Profiles.  I say "untuned", meaning that we hadn't set up any include or exclude rules against particular files or directories, nor were we doing any special processing on the registry, and while that's missing out one of the key benefits of UPM (the ability to exclude unwanted files, etc from the profile), that wasn't the point.

We assume that many Citrix admins would want to do a like-for-like comparison of UPM against Roaming Profiles to ensure that generally performance is comparable.  Better would be nice, but if there's a small price to pay for improved functionality, then that's probably acceptable.

You can imagine our shock when the first benchmark results appeared to show Roaming Profiles was twice as fast, and we had visions of a major re-architecting of the product, just weeks before we were due to release.

Of course, it turned out that we'd not made a proper comparison, which we realised as soon as we looked at the Citrix User Profile Manager 2.0 Logon-Logoff Chart - see http://support.citrix.com/article/ctx119466.

What that chart tells you is exactly what UPM does at logon and logoff time.  It tells you the circumstances in which UPM will create a brand new profile, or migrate an existing local / remote profile, and what processing is associated with that.

So we'd set up a template profile, with a set number of files of various sizes, which gave us the ability to measure repeatably the time it took to log on, compared to an equivalent Roaming Profile.  It should be the same, because all we're doing is copying files across the network, right?

Wrong!

We'd been tripped up by the extra function of User Profile Manager, in particular, the ability to write back only the changed profile data at the end of session, which helps UPM avoid the dreaded "last write wins" scenarios.  If there's no existing profile, UPM has to create one, and write it back immediately to the User Store, so there's something for other sessions to use straight away.

That, of course, means a second network copy, on the first logon only.  So whereas Roaming Profiles performs one full network copy-read at the start of each session, and a full network copy-write at the end of every session, UPM performs a full copy-read and a full copy-write at the start of the very first session.  For all subsequent sessions, UPM performs a full copy-read at session start, and a differential merge-write at session end.  It's that last merge-write that's the clever bit, of course, that lets UPM merge changes from multiple simultaneous sessions and avoids overwriting changes from earlier sessions.

Once that was sorted out, we were able to satisfy ourselves that logon times for UPM were very similar to logon times for Roaming Profiles.  The next step was to start adding include / exclude rules to reduce logon times ... but that's another blog post.

Group Policy Object (GPO) configuration is an option in addition to INI files for managing your User Profile Manager environment.  While the INI configuration approach provides a quick and easy way to get started on a few machines, if you wish to evaluate or try on more than a few machines, you should leverage the GPO configuration approach.  If using GPO for configuration you should rename or delete the INI files.  A GPO setting will always take precedence, but if a GPO setting is Not Configured and that setting exists in the INI, it will use the INI setting.  Thus this situation could result in unexpected behavior if not watching both configurations reliably.  Although with logging enabled, the log file will contain details of the source for applied settings.  E.g. the setting came from the GPO or from an INI file.
In order to use a GPO for configuration, you need to import the ADM template.  So first thing is to place the "UserProfileManager 2.0.0.adm" template somewhere easily accessible (e.g. you will need to search and select this file when importing into the GPO so place it somewhere easy to get like on the desktop where you will be running the Group Policy Management Console).

Launch Group Policy Management Console (GPMC) and either create a new GPO or select an existing GPO to manage your User Profile Manager settings.  I'll leave the discussion of balancing the number of GPOs against managing GPOs on a single functional role for another day J.  There are good arguments for both sides of keeping a GPO functionally specific versus having too many GPOs bogging down the logon.  Also, if you do not already have GPMC on your Windows Server 2003 or Windows XP system, download it here.  That console is by default already on Vista and Windows Server 2008.

Once your GPO is created (or selected if using an existing GPO), you need to import the ADM template which will then expose all the User Profile Manager settings.  Details on importing an ADM template can be found here under the Custom ADM Files paragraph/section: http://support.microsoft.com/kb/816662.  Once imported, all the ADM settings will be available for configuration.  Details of all the available UPM GPO settings are located here: http://support.citrix.com/article/ctx118944.

You can now enter edit mode for that GPO and view the settings and configure as desired.  You will find these settings under Computer Configuration/ Administrative Templates/ Citrix/ User Profile Manager.  If you are using a Windows Server 2008 or a Vista machine to manage your GPOs, the path will be Computer Configuration/ Policies/ Administrative Templates/ Classic Administrative Templates (ADM)/ Citrix/ User Profile Manager.  A good start is to have a look at the INI file and use the settings provided there in your GPO.

Side note: Keep in mind that by default, everything in the user profile is included.  Therefore you do not have to define anything in the include section except in certain circumstances.  For example, you would use inclusions to include any sub folders within excluded folders (e.g. you exclude Local Settings since this contains mostly temp garbage but then turn around and include the folders that actually contain useful application settings data like Local Settings\Application Data\Microsoft\Feeds and Local Settings\Application Data\Microsoft\Outlook).

Best practices suggest that configurations should be done on a per OS basis as Windows XP and Vista do not have compatible profiles.  For example create two OU's, one containing XP Desktops and one with Vista desktop and apply a GPO to each OU.  Here is a specific example on how to the design the user store for this scenario: http://blogs.sepago.de/helge/2009/01/23/citrix-user-profile-manager-released-user-store-design-recommendations/

Although you can share profiles between Win2k3 & XP and between Vista & W2k8 please refer to this FAQ on potential repercussions to take into consideration: http://support.citrix.com/article/ctx119039.

Once you have completed your configured to your desired state, you are ready to go.  To force a target machine to collect this updated configuration, run "gpupdate /force" in a command shell.  Or typically after about 90 minutes, group policy will refresh by default.  Once again you are ready to evaluate and test.

This will give you a very basic setup to get you up, running and evaluating.  I will cover using INI files in this article and post a second article on using Group Policy Objects(GPO).  While the INI configuration approach provides a quick and easy way to get started on a few machines, if you wish to evaluate or try on more than a few machines, you should leverage the GPO configuration approach

Step 1: You need to download the package.  User Profile Manager (UPM) may be found in both the XenDesktop and XenApp download pages (listed below).  Depending on the status of your Subscription Advantage, you will have access to up to two links.  One link is for those with an entitled Subscription Advantage status and the other link available to all for evaluation purposes.  Also I should mention that you will start seeing us reference this technology as the Profile management feature (for both XenApp and XenDesktop).

-          XenApp https://www.citrix.com/English/ss/downloads/results.asp?productID=186&c1=pov1349748&c2=sot8218

-          XenDesktop https://www.citrix.com/English/ss/downloads/results.asp?productID=163057&c1=sot8218

The zip package you download will contain the install packages, ADM template for Group Policy and supporting documents (all of which are available in the Knowledgebase and the respective links are at the bottom of this article).

Step 2: You need to install the profile service. This service must be installed on each endpoint that you want to have user profiles managed by UPM (e.g. XenApp server, Desktops (XP, Vista), etc).  There are two MSI packages - one for 32-bit platforms and one for 64-bit.  The install is simple and straight forward.  After clicking next a couple times, the package will be installed.  There is nothing to configure at this point other than the target install directory if you desire something different than the default (which is c:\program files\citrix\user profile manager{}).

The target install directory is also where the INI files are located.  The settings in the INI files provide a default configuration.  The INI section naming translates directly to the GPO configuration settings.  By using the INI file, you have a basic configuration ready to go.  It is relatively easy to read and interpret what the INI configuration settings are having User Profile Manager capture and track.

Per the default configuration, UPM will capture the user's entire profile (files and registry) and store it in the user's home directory under a folder called 'windows' (you may change this to any folder name desired or use a fully qualified UNC target).  For files and folders this means everything in the user's profile directory.  For example, on WinXP or Windows Server 2003 that would include everything in /Documents and Settings/%USERNAME%/.  For the registry this is the entire HKCU (NTUSER.DAT).  Thus you only need to be concerned with what to exclude (keeping the bad and bloating things out).  There are a few defined exclusions in the INI file for both file system and the registry which will provide you a good starting point for your test environment.

Side note: Keep in mind that by default, everything in the user profile is included.  Therefore you do not have to define anything in the include section except in certain circumstances.  For example, you would use inclusions to include any sub folders within excluded folders (e.g. you exclude Local Settings since this contains mostly temp garbage but then turn around and include the folders that actually contain useful application settings data like Local Settings\Application Data\Microsoft\Feeds and Local Settings\Application Data\Microsoft\Outlook).

Step 3: There is one setting change required to enable the service to start working - this is the 'ServiceActive=' setting.  By default, the service sits idle enabling customers to push this service out before enabling it (even though the service is 'running' in the services list, it does not manage anything).  Enabling the service is done by setting ServiceActive=1 in the General Settings section of the INI.  Also remove the semicolon at the beginning of the line otherwise the line will be interpreted as a comment.

And with that you are off and running.  All user accounts will be processed by default unless you assign an AD domain group in the configuration.  Also, Administrator accounts will be ignored (again by default).

You are ready now to test and evaluate away!  Enjoy.

To get a sense for what User Profile Manager is doing and to verify your settings you can enable the logging mechanism of User Profile Manager. This will be achieved by the setting LoggingEnabled=1. Logging details can be enabled by the remaining settings all in the Log Settings section.  '=1' is on and '= ' or '=0' is off.

CTX Articles (Documents and FAQS):

-          http://support.citrix.com/article/ctx118943 Admin Guide

-          http://support.citrix.com/article/ctx118944 Group Policy Template Reference

-          http://support.citrix.com/article/ctx119466 Logon/Logoff Chart

-          http://support.citrix.com/article/ctx119791 Technical FAQ

-          http://support.citrix.com/article/ctx119747 Licensing FAQ

-          http://support.citrix.com/article/ctx119039 Cross Platform Considerations FAQ

-          http://support.citrix.com/article/ctx119038 Troubleshooting FAQ

You may have noticed that Citrix recently released User Profile Manager v2 (UPM).  Those of you using the Technology Preview or a previous sepagoPROFILE product are probably wondering what exactly has changed in this release.  There are six key changes to this v2 release you should be aware.

The biggest change is UPM no longer uses a mandatory profile.  The previous method of loading a mandatory profile and merging settings has been replaced with a mechanism that behaves much more like the mechanics of a roaming profile (plus saves time since it no longer has to merge settings).  Since a mandatory profile also served as a good 'base' profile, we added the capability of a 'template profile'.  This is what would be used as a 'default profile' for creating a new users profile.  You can actually use your mandatory for the template profile if you just rename NTUSER.MAN to NTUSER.DAT.  Please remember that it does need to be a 'whole' profile and not just the NTUSER.DAT file (HKCU registry settings).

You should also make note that once a template profile is used to create a profile, that profile is then copied to the user's store (the target location defined when configuring UPM) and is no longer connected to the template profile.  Meaning that you cannot change the template profile after a user has their profile built and expect those updates to replicate to existing users - only new users would see the changes.  If you desire to enforce settings, configurations or other environmental items, this would be a job for Group Policy.  Thus when Group Policy is updated or changed, this new policy would be applied to all applicable users or computers.

The next significant change is the support of wild cards in the configuration.  Whereas before if you wanted to add only INI files to the profile, you had to literally type each file name in entirety.  Now you can use *.INI to configure that same behavior.  The standard wild cards are supported such as '*' and '?'.

Next we added the ability to synchronize folders outside of the user's profile directories.  Such in the case when you have an application storing user settings improperly such as in 'c:/badapp/'.  Now the administrator can define these 'rogue' folders as part of the user's profile and they will roam with the user.  Just make sure they don't roam with you into a dark alley - they really cannot be trusted.

We significantly improved logging so that you can view your log files in an application such as Excel and be able to sort and filter the files for better reviewing and analysis.  I will post separately on all the details around logging.

We added language independent storage of profiles on the Windows Server 2003 and Windows XP platforms (Windows Server 2008 and Vista already do this).  What this does is append folders such as favorites with '_upm_var' so that when roaming between different languages, you do not end up with multiple folders since on these platforms Favorites would get localized and treated as unique folders.  E.g. on German you would have Favoriten while on English you would have Favorites.

We also had one casualty that we will honor with a moment of silence.  That would be the archiving functionality being dropped in v2.  This was the capability to compress files within a folder into a ZIP file and then copy that ZIP file to the user's central store.  Unfortunately this introduced last write wins since the last zip file written would overwrite any previous file.  But fret not, we will certainly be focusing on areas to improve speed and performance as we continue to build out this technology.

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.

As part of Synergy Underground project, we interviewed many of the people in the XenApp booth in the TechLab to talk about the different features and components of Citrix XenApp Platinum.

(Each of these videos were shot and streamed live to the Underground site via a Nokia N95 cell phone. The convienience and ability to stream live video directly to the net is the trade off for the lower audio and video quality. Read this post for an explanation of the process and a video on how the live streaming worked.)

Here are three of those video interviews -

Jay Tomlin on Smart Access

David Wagner talks about the new User profile Manager Tech Preview

Victor Thu talks about Easy Call
(low audio in first half)