Wednesday, 30 January 2013

Using AppSense Environment Manager to migrate user profile settings…

Using AppSense Environment Manager to migrate user profile settings…

So you have an existing Windows XP or Windows Server 2003 deployment and your users have happily (or not as the case may be) been working away for years with their old roaming profiles and you are looking to give them a shiny new Windows 7 or Windows Server 2008R2 platform to work on. The first problem you are going to have is that the users have built up their profiles for years and years and in some cases… cannot do their jobs without their Microsoft Outlook nicknames or their Internet Explorer favorites.

This post is going to show you a few ways you could leverage AppSense Environment Manager to get the settings from their existing machines onto their new machines. For simplicity sake I am going to assume that no AppSense Environment Manager agents have been deployed to the legacy estate but if it is possible having the Environment Manager Agent on the source platform will make migration a LOT easier.

So first lets talk about your main options:
Migrate Existing – we have ruled this out already by saying AppSense Environment Manager will not be deployed to the source platform. What you could do though, provided your Personalization Server configuration was restrictive enough, is deploy the Environment Manager Agent to all endpoints and run it in migrate mode for a long enough period of time. What this does is enable virtualize on read that means any registry keys and folders that are read are virtualized. The important things to take away here is that you need a very restrictive configuration within Personalization Server and quite a long window of running in migrate mode because you are relying on the users opening applications and running for a period of time to capture the data.

AppSenseSpecial – anyone who has working with AppSense Personalization Server long enough will probably already have heard of AppSenseSpecial. In short it is a way of running an application as though it were something different. For example using AppSenseSpecial I could launch XCOPY.exe as though it were EXCEL.exe so any file or folder copy actions that XCOPY.exe does are virtualized. There are a few limitations to AppSenseSpecial that I will come onto later.

Helper Applications (sometimes referred to as masquerading applications) – Is any approach which takes the concept of grouping applications and AppSenseSpecial and merging the two together. At a high level what I do here is add a copy of an executable to an application group and then anything that executable does is virtualized.

A few other options do exist but I am not really going to touch on them in this article because I personally do not feel they are up to the task at hand.

Exporting the data

Since the AppSense Environment Manager agent is not available for the export you could use a simple batch file invoked at logoff to export users settings from their local profile to a network file share (e.g. Users Home Drive.) In this blog post I am going to assume this is the case and that the data has already been exported to %HOMESHARE%\myData\Migration and all import actions will reference this location.

I have attached an EM Snippet which could be used to gather the data alternatively turn this into a script and run it as an Active Directory logoff script.

Note: If you were looking to use AppSense Environment Manager to hive the registry keys to a network folder you must use merge mode. If you do not select merge mode importing these to the database will be significantly more complex.


The AppSense Environment Manager agent has supported this hidden functionality since the very early days of Environment Manager 8. In the simplest possible way AppSenseSpecial tricks an application into thinking it is another application that allows it to be personalized.

In the example below we are telling command prompt (cmd.exe) that it is in fact %OfficeVersion% which is a variable set to outlook.exe:14.0. We are then passing an xcopy command to the application so AppSense Environment Manager is virtualizing any files or folders copied by xcopy.

AppSenseSpecial is great because it doesn’t rely on any “helper” applications being created BUT it does have limitations:

1. If I created a configuration that had a large number of AppSenseSpecial actions sequencing is important.

If you structure the actions to run in parallel as seen below the logon session will most likely hang and ultimately timeout without completing the actions:

You must structure the actions in a sequential manner as seen below to ensure that logon runs as expected.

Note: Each action MUST have “Do not execute children of this action until the process has exited” enabled.

2. Perhaps I am being a bit unkind here but the initial setup of this process will take a while unless you have a good template to work from.

Helper Applications

This approach is similar to the AppSenseSpecial approach above only instead of referencing AppSenseSpecial to perform the actions I use copied of XCopy.exe and Reg.exe.
The first actions required within the configuration are a number of file copy actions that run at Computer Startup. These actions copy the following files to a separate location:

·      C:\Windows\System32\xcopy.exe
·      C:\Windows\System32\reg.exe
·      C:\Windows\System32\en-US\reg.exe.mui

I typically name the copy the same as the Application Group they will be importing settings for.

E.g. If I were importing Microsoft Office 2007 the files would be named Office2007-xcopy.exe, Office2007-reg.exe and Office2007-reg.exe.mui.

Optional: The next action I perform is to use Microsoft PowerShell to create a Windows Batch file that I run to perform the migration. The only reason for this step is to make the migration process cleaner.

To run a batch file using Environment Manager you would launch cmd.exe with the /C switch. This gives you the ability to select the “Do not execute children of this action until the process has exited” and “Do not create window” which prevents the user from seeing that a migration is taking place thereby preventing them from cancelling it.

The process for creating the batch files is quite complex but it works very well. The important thing to take into account here is the folder structure you choose to implement on the export process. Keep this as closely aligned with the folder structure of the users profile and this greatly simplifies the PowerShell script.

The script seen below can be found here…

As I said before, the script is optional so you could now either do one of the following:

Multiple Actions

In this instance we are running all of the following at process started. The most important component of this entire process is to ensure the two registry value conditions.

These registry value conditions will check the specified registry value to make sure this is set to Migrated. If the does not exist or is not set to Migrated the subsequent migration actions will run. If the registry key is set to Migrated the actions will not run.

Once the migration actions run the registry value is set to Migrated preventing the action from running again.

Single Action

In this instance we are running the following at process started. Again, the most important component of this entire process is to ensure the two registry value conditions.

Personalization Configuration

So far all we have talked about is policy configuration… switching to Personalization now, all that is required for the above configuration to work as expected is the following:

Define the new user applications for Office2007-xcopy.exe and Office2007-reg.exe

Now add the new applications to the Microsoft Office 2007 application group.

Lastly add the registry key that holds all Migration flag keys to session data.

That’s it… you are done and migrations should be working like a dream.

To grab hold of the configuration with all of the actions, etc used within this configuration as well as the powershell script head here...

Give me a shout out if you need any assistance with this..