Easy. Just follow the instructions at http://support.citrix.com/proddocs/topic/user-profile-manager-kib/upm-upgrade-den.html and http://support.citrix.com/article/CTX126659;.

However, those instructions describe the ideal scenario, and assumes you have 2.1.1 already installed and you want to get to 3.2.2 (the latest version, as I write this blog), and that you’ve got a convenient maintenance window that you can use.

What do you do if those assumptions don’t apply to you? Maybe you’re on 2.0 or 2.1. Maybe you don’t have a maintenance window for another 11 months, and everything is expected to run 24×7 until then.

I’m going to suggest a method that’ll get you from older 2.x versions to 3.2.2 directly, without a maintenance shutdown, and what the risks are associated with that method.  To do that, I’ll have to delve into the workings of Profile Management (UPM) a little bit.

Profile Management version 3.0 introduced Profile Streaming and Active Write Back as its new features. Both of these features required the use of a new directory on the user store, called Pending. This Pending Area is used to merge changes when several sessions are active for a user.

(For example, when a XenDesktop user Fred is using published apps from one or more XenApp servers, the XenDesktop machine and each XenApp server will each have an active Windows session for user Fred.  UPM 3.x is able to maintain profile consistency and speed up the loading of profiles by keeping recent changes in the Pending area.)

UPM version 2.x doesn’t know about the Pending area, so when a 2.x session ends, it merges all its changes back into the base profile directly. This has 2 potential issues: a) subsequent 3.x sessions that start won’t pick up changes made by the 2.x session and b) when 3.x sessions finish, they’ll write their changes back to the Pending area, and then simply overwrite what’s in the base profile, potentially losing changes from the 2.x session(s).

So in 2.1.1 we added awareness of the Pending area, but only to the point of giving the user a temporary profile if it recognised that a newer version of UPM was using the user store.

If you don’t have 2.1.1, then you can still upgrade to 3.2.2, but you must make absolutely sure that all copies of 2.x have been upgraded before you enable any 3.x features. In particular, you must first upgrade the 3.x ADM template in the GPO and then explicitly disable the Active Write Back feature (as this is enabled by default) before installing any 3.x version of UPM.

Then you can update XA servers and XD desktops one-at-a-time.  (UPM 3.2.2 acts both as an update and a full install.)

Once you are sure that all copies of 2.x have been upgraded can you enable any 3.x features, without the danger of profile corruption. (If you don’t enable the 3.x features, then the 3.2.2 install will happily function as a service pack for 2.x)

This “danger of profile corruption” is most likely to arise when you have UPM installed on a large number of physical machines, in multiple locations, and actually accessing every machine to perform the upgrade is difficult and time-consuming.  Where the XD and XA images are wholly within the boundaries and control of the datacenter, the administrator can reasonably easily be certain that all 2.x versions have been upgraded, particularly if technologies such as PVS are used to derive the production images from a single master image.

So in many cases, it is just as straightforward to upgrade from earlier 2.x versions. Working from a 2.1.1 base adds a tiny extra bit of safety – which is why we recommend it – but that safety measure is not always needed.

I trust that helps.