Migrating your terminal server platform without users noticing it

I was recently supporting a customer who had a migration project planned. The customers were using Citrix Presentation Server 4.5 on Windows Server 2003 x86 and the task was to replace this with XenApp 6 on Windows Server 2008 R2. What made this interesting besides the change of profile versions and the system architecture was the fact that the users should not notice any downtime or lose any of their settings. Especially the Outlook settings and accounts and the Internet Explorer passwords were mission critical.

How hard can it be?

The customer had a total of around 10 applications that should keep their settings during the migration and there were about 50 users per farm. Now that doesn't sound like a lot, so why not just identify the few registry keys and directories that store those settings and copy them using a script? That should not take long...
Actually there is a bunch of registry keys and values scattered around the user's registry hive that store Internet Explorer settings. And when you think you found them all, you'll need to test that these do in fact transfer all settings. Now imagine this amount of work for Office and all the other applications that need to be migrated. And if that is not enough, you'll still need to write the scripts that copy the data from one profile to the other. But is there already a target profile that will receive the settings? The user has not logged on to the new system, hence there is no profile so far. How do you create it?
As you can see work is quickly piling up. Lucky for you (or our customer in that case) there is a simple solution to all of these problems.

Enter Profile Migrator

In the scenario I described here Profile Migrator helps in a lot of ways. It simplifies the whole process of all the necessary preparations to just three simple steps. The source profiles are selected via OUs or directories and the target profile is defined by the path to the default profile of the target system and the path for the migrated profiles. Profile Migrator copies this default profile automatically and personalizes it for every migrated user. After this the user's settings are added. This process also cleans up the profiles, because it saves the important settings and leaves behind all the things that bloated the profiles.
Application settings are migrated by ACS files that store a blueprint of locations where a specific application stores its settings. Migrating an application's settings for all of the users is as simple as selecting the application from the list and specifying the source and target version and target application architecture.

Profile Migrator comes with quite a number of ACS files already created
and tested by sepago, so that is a big load of work off your shoulders. But our customer still had some applications that were not covered by our ACS files. That's when the integrated ACS file editor and PMAppMon came into play. The built-in editor allows Profile Migrator users to create their own ACS files and migrate whatever application they want. But they still need to know, where that application stores its settings, you might ask. You're right, but the included tool PMAppMon helps you identify those locations by monitoring the application in question and afterwards presenting you with a list of locations that were accessed in the user's profile by that application. With that you'll have no trouble finding the application's setting storage.

In fact we used the shipped Microsoft Office and Internet Explorer ACS files from sepago, then we created ACS files for the other applications. The customer's in-house application is well documented and the storage locations of the user settings could be found easily. We just added these locations in the profile content tree view in the editor and the ACS file was complete. The other applications were third-party and the user settings locations unknown. For each of these applications we started PMAppMon out of the editor and monitored the application while we changed some of its settings. After the monitoring process the results were pasted directly into the editor. We then had to filter out some unnecessary entries manually, but there was no need to track down the application's user settings storage location by hand. The whole process of creating the ACS files took us only a few hours including validating the migration of the settings in a test environment. The sepago ACS files especially migrated all Outlook accounts, settings and passwords and all Internet Explorer credentials without a problem, ensuring the mission critical part of that migration was handled.

Getting out of the lab

With the preparations done and positive test results we went on and migrated users in the production environment. Profile migration was only one part of the whole migration process and had to be integrated into the automation scripts for the entire migration. That ruled out using the GUI of Profile Migrator and clicking yourself through every migration. For these scenarios Profile Migrator provides its command line interface PMCommand that uses the same migration engine as the GUI. With PMCommand it was easy to integrate the process of migration user profiles into the whole deployment scripting process and keep the automation intact.

In conclusion Profile Migrator helped in every step of the profile migration process. It supported the customer in identifying application settings in the user profile and creating an ACS file to migrate those settings. Its shipped ACS files ensured the smooth migration of Microsoft Office and its easy three step migration and command line version blend in well with the enterprise level automation of the migration process. The migration was performed over night and the next morning the users did not notice that their terminal server infrastructure had changed. There were zero support calls about missing passwords, e-mails or similar things!

Maybe I'm biased, because I am one of the developers of Profile Migrator. But that should not stop you from checking out the evaluation version. Because it really is a great tool.