866-764-TECH(8324) · Subscribe to Application Solution Providers, Inc.News FeedSubscribe to Application Solution Providers, Inc.Comments

While I’ve blogged on the mechanics of upgrading from UPM 2.x to UPM 3.x, I’ve not yet addressed the other aspects of planning and configuration. This came up recently in-house, where we’d decided to upgrade an XD4 farm to XD5.

The original request came in as:

“We are creating a new CPM environment for XD5 Pooled in Showcase. We would like to take the contents of the existing user profiles in XD4 Pooled, being managed by an older version of CPM, and migrate them to a new folder share and then attach them to the new CPM environment.

Is this possible? Is it as simple as a robocopy command preserving permissions and pointing the new CPM to this directory?

Any guidance you can offer would be appreciated.

We are using UPM 2.1 currently – is it safe to move the profile folders to a new share and point UPM 3 at them (after the templates have been normalized)?”

So skipping the mechanics (for which, see How do you migrate from Profile Management 2.x to 3.x? )…

From the description, I assumed there was no co-existence phase. (If there is, then start with the above reference). So in essence you just switch off the old UPM 2.1 , copy the profiles to a new file share and turn on the new UPM 3.2.2 (the latest UPM). We recommend this version because the driver has been rewritten for improved coexistence with antivirus software.

So next: “is it safe to move the profile folders to a new share and point UPM 3 at them” – yes, this can be a simple robocopy operation. Please bear in mind the security (ACL) recommendations for the new share – Security Recommendations for Roaming User Profiles Shared Folders

Your existing configuration will form a good basis for the new XD farm. If you update the ADM template, then you will need to configure very little:

  • Path to user store – should point at the new file share. If the old Path to user store was something like \\oldserver\oldshare#sAMAccountName#%ProfVer% (where ProfVer is a system environment variable to differentiate between v1 (XP) and v2 (Vista/Win7) profiles – see here for how to set these up), then you will need to ensure the new farm has an identical environment variable set up. Note that the \\server\share part of the path can now refer to a DFS namespace – supported configurations and use cases are described at High Availability and Disaster Recovery with Profile Management
  • Active write back – this is enabled by default in version 3. It is designed to write back file changes to a profile without waiting for the user to log off. It may be valuable in XD setups using virtual machines, to avoid data loss following an outage.
  • Profile streaming – this is disabled by default in version 3, but is the “flagship” feature. It is designed to speed up logins, by only copying files from the network user store “on demand”. Its use is strongly recommended.
  • Always cache – this setting is only effective if Profile streaming has been enabled, and if set to zero, will cause the whole of the profile to be trickled down to the XD machine in the background after the logon completes.

Finally, assuming that you are planning to support local Internet Explorer on the XD desktop, then you should also read To manage cookie folders and other transactional folders. In order to maintain the integrity of the cookie folder, the supported configuration is to set both Folders to mirror and Process Internet cookie files on logoff policies.

The version 3.x release of Profile management enables streaming of your users’ profiles. Version 3.1 (available May 18, 2010) provides the same feature set as the v3.0 release (available back in March 2010) but has a number of fixes in it. Basically the same concept you see in our Application Streaming capability now exists for profiles. Also in this 3.x release is the new ability to write profile changes back as they occur instead of just on logoff. You can download it today from either the XenApp components section or the XenDesktop components and try it out (MyCitrix logon required, but there is also evaluation downloads available under the “Evaluations and Trial Software” category). Let’s take a closer look at both these new capabilities.

What this provides is the ability to only bring down the user’s profile as it’s needed. Thus instead of making the logon wait while the user’s profile downloads, it basically tells the OS that the profile is really there (when it’s not) and then cache fills the actual data on use. You may configure this behavior to only cache on use (default), pre-cache any files defined by size (e.g. 5 MB or larger files always get cached) or even configure it to cache the whole profile but only after letting the logon process proceed (and thus not bottleneck the logon process). These options are all about balancing bandwidth (only copy down files when used) with user performance (make sure the file is there before the user clicks it so as not to have to wait for larger files to cache).

Will this save you massive time in your logons? That depends on how big your profiles are and how much time in the logon is profile related versus logon scripts and GPO processing related? Is there really any other answer in the technology world? e.g. if you have a 200-300 MB profile, you may see upwards of 70-80% savings in time for loading that profile (if using just in time caching, the physical files no longer have to be copied down into the session).

The other new capability in this preview of Profile management provides the ability to actively write back a profile’s changes to the user store during a session. This way the synchronization of the user’s profile is no longer tied to the logoff event. Now as changes are detected the modified files will be written back during the course of the session. This means when a new session is started, any changes from the current session will be picked up in the new session. It also means logoffs are improved as well since the files needing to be updated are written back during the session and not saved to all happen at logoff. Please note that this does not mean changes are replicated to existing sessions. Only new session would pick up the changes.

So please give this release a look and we always look forward to any feedback. How much does it improve your logon times (e.g. how big are your profiles and how long did they take to load during logon)?

One of the common questions or really frustrations is why can’t the stupid profile just roam across OS versions and bitness – meaning between both OS versions and across x86 and x64.  And while the idea of a single profile is an optimal approach, there are some challenges to be overcome.  And in reality, often it’s not necessarily the entire profile that needs to be roamed but just the settings related to certain applications that tend to be installed across OS versions.

Applications like Microsoft Office and Adobe Acrobat Reader to name a couple.  Most business line apps will be relegated to a few or one OS in order to improve supportability.  I suspect most IT shops always want to support these apps on the fewest OSes as possible from an efficiency perspective – preferrably just one OS.  But apps like Office always end up having to be supported on just about every OS in your organization.  So let’s break this down and talk about files first and then the registry settings.

All the files in your profile are either under \Documents and Settings\USERNAME or \Users\USERNAME.  Ultimately application data in the profile is what’s at issue here. In Microsoft’s v1 profiles (XP and Server 2003) there is \Application Data\ and \Local Settings\. In Microsoft’s v2 profiles (Vista, 2008, 2008 R2 and Win7) there is now a single root folder \AppData\ that contains \Local\ and \LocalLow\ and \Roaming\.

While for the most part all the things that use to be in v1′s \Local Settings\ landed in v2′s \AppData\Local or \AppData\LocalLow\ ( and \Application Data\ to \AppDat\Roaming) it’s not necessarily a direct mapping … some apps changed the way they stored their data. And I’m not clear on the selection criteria for storing data in targets like \Local\ and \LocalLow\. Maybe someone else is knows??

Most other data like My Documents, Favorites and Cookies would roam just fine (and thus great candidates for Folder Redirection), but a lot of the Application Data may be at risk by being moved where the app can no longer find it. Probably for the most part harmless and the app would just recreate settings from default. And of course if that happens, the user loses some settings.  Not good.

As for the registry (NTUSER.DAT), here is another big challenge.  Sharing settings between Windows x86 and x64 might work, but there will probably be some issues.  There are several reasons, but here is one example provded by Helge Klein:

  • Per-use file associations are stored in HKCU\Software\Classes. If a non-Admin sets Firefox as his default browser, the following is stored on a 32-bit system:
  • HKEY_CURRENT_USER\Software\Classes\FirefoxHTML\shell\open\command -> “C:\Program Files\Mozilla Firefox\firefox.exe” -requestPending -osint -url “%1″

If a profile containing above path is used on 64-bit Windows, the OS would look for a 64-bit version of Firefox, which does not exist. Instead, there will probably only be a 32-bit version of Firefox installed to C:\Program Files (x86)\Mozilla Firefox. Result: the Browser cannot be started. This also happens the other way round (path set on x64 and used on x86).

So if the machines are not exactly alike (e.g. same 32-bit apps on 64-bit and not the 64-bit counterpart apps) then problems will likely start surfacing.  This challenge also exists for version differences in the applications themselves.  Office 2007 for example -- while most settings roam no problem, there are some that will ‘damage’ an Office 2003 install.  In other words, if you roam settings between machines, the machines really need to be application version/bitness identical.  If not identical, you might be able to address some of this with app isolation/streaming and isolate those settings or at least the ones that conflict between app versions.  But then that means some settings will need to be reconfigured by users since they will be isolated.  Again not good.

So as always it certainly can be done … the hard part is not enabling this to occur – it’s getting it to actually work right once settings roam.

We actually do have a technology preview of a cross-platform settings capability -- we are exploring this technology and are in need of some feedback from the field. Essentially this is a capability to allow admins to define settings in the profile that may roam from one OS to another. E.g. Settings for AppA are supported on 2003, 2008, XP and Win7. Settings for AppB are only supported on XP and Win7. Etc.

Unfortunately it’s not something we can offer to everyone on a broad basis so we will only be able to accept a few requests. Its purpose is not to create a singular profile but enable application specific settings to roam across OS versions – applications like Office that typically need to be supported on a number of OS versions. It is a limited preview as we are limited in the ability to broadly support it (basically I am front line support). And there are key questions we want answered from any evaluators outlined below. If interested, drop me an email (surely you’ve figured out the secret email address format at Citrix ).  If you are able to commit to actively testing per the below guidelines over the next month or so, I would gladly consider accepting you into this testing group. But unfortunately I will not be able to accept everyone.

Our primary focus for this is getting insight into the admin experience (is it a viable way to handle these types of settings) and to better understand what apps (and types of apps) are likely to be supported across OSes. We expect this to primarily be apps like Office and Adobe Reader but want to make sure we understand all such apps .

The evaluation can be done with as few as two machines (e.g. 2003 and 2008 XA servers and using XD with XP and Vista/Win7). But you probably want to have at least one machine to represent each OS you plan on roaming settings across.

What are the results we expect from evaluations:

  • Validation we are easy enough to use for admins
  • Validate we have the minimal configuration set for apps that will roam across platforms (e.g. Office, Acrobat Reader, WinZip etc).
    • Customers can extend to other apps. Citrix needs to ensure we have sufficient ones identified and pre-defined to provide out of box experience.
    • If you are using other apps besides the ones we pre-packaged, please itemize those for us for consideration.