Well, my first blog on migration strategy provoked a few interesting reactions, which is good, because we did need to find out whether our proposal for a migration strategy was going to be acceptable. No-one wants to go to market with a product where the pain of upgrading outweighs the gain from the new features.

The messages that came back were:

  • Network admins don’t like adding OUs just to upgrade a product. Cloning an OU, with all its settings (GPOs), isn’t a trivial operation. Find another way to co-exist with older versions.
  • Upgrades without downtime are preferred for some scenarios. But we need to handle a “big bang” too.
  • Don’t force profiles for different OS types to be stored together on a single User Store.

So I’m going to outline an improved scheme, which allows us to do all of these things, and also run through a few typical migration scenarios.

The basic idea is to use AD groups to separate Profile management users into those who are allowed to use specific features, and those who are not. It’s an optional feature in UPM v2 – if you don’t set up a group, UPM v2 processes logons for all users.

When Profile Management v3 comes along, you’ll need to configure a group for all your UPM v2 users – V2USERS – and another group for all your Profile Management v3 users – V3USERS. These groups are actually lists of groups, so you can configure more than one AD group to be part of V2USERS, and similarly for V3USERS.

(Note that V2USERS (and V3USERS) should be set up in larger deployments to identify those users licensed to use Profile Management.)

If you’re not sure what I mean by V2USERS, here’s the ADM template for UPM v2 in the Group Policy Management Editor:

What I’ve called V2USERS is the “Processed groups” line, which I’ve ringed.  When Profile Management v3 comes along, there’ll be another similar line for V3USERS, with a name that hasn’t been decided yet.  When you configure it, the Group Policy Management Editor lets you enter a list of Active Directory groups.
So here are my revised scenarios for upgrade. As with my previous blog, there is a ‘Big Bang’ scenario, and a phased upgrade scenario.

First, here’s the Big Bang Scenario. I assume that some downtime is acceptable, maybe a holiday weekend, but we will do most of the work prior to that time.

  • Replace the ADM template with the new Profile Management v3 template. The template is designed to be compatible with UPM v2, so your UPM v2 machines continue to operate normally.
  • Configure all of the Profile Management v3 features OFF. (This will be the default setting, anyway)
  • start migrating all the machines from UPM v2 to Profile Management v3. Fit this in with your normal maintenance and update schedules, take as long as you like. Until you enable Profile Management v3 features, everything will operate at UPM v2 functional level.
  • Optionally, set V3USERS to just include the members of a small pilot group. Wait for the Active Directory Group Policy changes to propagate throughout the network (e.g. over a weekend). You don’t need to prevent access for any other users while this is happening. Back up the profiles of the pilot group. then let the pilot group test out UPM.
  • Once you’re happy with the pilot group results, ensure that you’ve backed up everybody’s profiles, and…
  • use the next scheduled maintenance window to add the remaining licensed users to V3USERS. Allow sufficient time for the AD changes to propagate, and let the users log on again.

Second, here’s that scenario modified to work with the phased upgrade, where you can’t move all your machines or your users to the new version. You could use this approach where you have several datacenters or geographically distributed users.

The steps to upgrade are now:

  • Replace the ADM template with the new Profile Management v3 template. The template is designed to be compatible with UPM v2, so your UPM v2 machines continue to operate normally.
  • Configure all of the Profile Management v3 features OFF. (This will be the default setting, anyway)
  • upgrade a few machines to Profile Management v3. (Or install brand new machines with Profile Management v3.) Initially, V3USERS is set to contain an empty group, so nobody gets processed under “v3 rules”.
  • publish new apps (XA) and desktops (XA / XD) using the Profile Management v3 machines. These apps and desktops will be identical to the old ones, except for the names, which will identify them as for use by Profile Management v3 users
  • When your selected users log on (e.g. using Web Interface), they now choose the new applications (use Web Interface to enforce this, based on user name or group menbership). Consequently, their sessions run wholly on the Profile Management v3 machines.  At the moment, they’re still using UPM v2 rules.
  • ensure that you’ve backed up everybody’s profiles, and…
  • move the users out of V2USERS and into V3USERS. Allow time for the group changes to propagate to the Profile Management v3 machines. Next time they log on, they’ll be processed using v3 rules.
  • repeat with the next batch of machines. Migrate the next group of users, as above.

Eventually all your users and machines will be migrated.  It’s more work, because you have to keep updating V3USERS and maintain two sets of applications and desktops (but you can automate that because you can export app definitions from XenApp).  The upside is that you can take your time over the upgrade.

(Remind me – Why do I have to go through all this palaver to migrate?  See my previous blog post[\~billp:/2009/03/20/Long term planning for Profile Management], but basically profiles for different Profile Management versions don’t mix.  If user Ginger uses one machine with Profile Management v3 to handle his profiles, then all the machines he uses must use that version, else profiles will get corrupted.)