Migrate user profiles to a new domain with Profile Migrator 1.1

Since the release of Profile Migrator 1.0 we have received a lot of positve feedback and feature suggestions. While we are working on adding support for profile migration from client computers in the next major release, the beta version of Profile Migrator 1.1 is out. Besides bug fixes and minor improvements it contains a new feature: script execution before and after every profile migration including passing parameters to the scripts. This allows for a variety of additional tasks to be performed automatically during the migration process.

We'll pick up the domain migration scenario described by Helge Klein in this recent article and extend a migration process with a script that enables a domain migration and allows user names to change. Along the way you'll learn how to use the script extension in Profile Migrator 1.1.

So what's the scenario?

When it comes to migrating users, it is a common task to not only migrate the user profiles from one OS to another, but to migrate the entire user to a new domain. Let's assume a migration of Windows XP roaming profiles to Windows 7. During the migration the old domain will be replaced and on top of that the user names will change due to new naming conventions, which makes the task even more complex.

These are the necessary steps:

  • Migrate the user profiles: This is a piece of cake using Profile Migrator.
  • Copy the old user account's permissions to the new domain and user account: A few simple commands using SetACL.
  • Automate the entire process: Let Profile Migrator 1.1 call the script and pass the necessary parameters.

New account - same permissions

SetACL is a powerful command line utilty, which is well documented. The necessary action to copy user permissions from one account to another can be initiated by this command:

> SetACL.exe -on "\\FileServer\ProfileShare\UserX.DomainNew.V2" -ot file -actn trustee -rec cont_obj -trst "n1:DomainOld\User_X;n2:DomainNew\UserX;ta:cpytrst;w:dacl"

The old user was a member of DomainOld and his account name was User_X. The intent is to migrate this user's profile to his new account UserX on DomainNew. Note that the profile path contains the new user name and domain. This is because the permission modification is best performed after the profile migration to avoid changing the source profile. But let's not forget that the permissions in the user's registry hive need to be changed, too. This requires the user hive to be loaded before calling SetACL and unloading it afterwards:

> reg load HKU\PMTemporaryHive \\FileServer\ProfileShare\UserX.DomainNew.V2\NTUser.dat
> SetACL.exe -on HKU\PMTemporaryHive -ot reg -actn trustee -rec cont_obj -trst "n1:DomainOld\User_X;n2:DomainNew\UserX;ta:cpytrst;w:dacl"
> reg unload HKU\PMTemporaryHive

That was easy, right? But the old and new account are specified directly in these commands. How do we automate this?

Calling the script from Profile Migrator

As mentioned before Profile Migrator 1.1 introduces the option to run scripts and commands before and after each profile migration. The script integration is designed for full automation meaning Profile Migrator can pass a large number of variables to the script that is being called. Each variable is filled with a value specific to the profile that is being migrated. All of the variables are described in the help area. Three of them are necessary for our purposes: the old user name and domain and the path of the migrated profile. We'll use these three pieces of information to build the old account name in the format domain\user and copy the permissions on the migrated profile.

 

 

One thing is missing, though. How do we tell the script what any old user account will be named in the new domain? The solution is to use a simple text file that contains a mapping of the old and new account name in one line, separated by a ":". The script can load this file and look for the owner of the currently migrated profile. The mapping table will tell the script the new domain and user name and we can use this to tell SetACL what to do. Here's an example of what the mapping text file should contain:

DomainOld\User_1:DomainNew\User1
DomainOld\User_2:DomainNew\User2
DomainOld\User_3:\DomainNew\User3

The script

Now that you know what to do, go ahead and fire up your favorite text editor to hack in the script. Alright, alright, no need to do this, I already wrote the script. I used Helge Klein's script and modified it to fit this scenario. The script takes four parameters: the old domain and user name, the new domain and user name, the profile path and the file containing the account mappings.

The script can be downloaded here. Please note that SetACL.exe needs to be located in the same directory as the script.

Calling a script from Profile Migrator is regarded as an integral part of the migration process. If the script fails and returns an error code, the profile migration fails, too. This is by design to help prevent inconsistencies in migrated profiles. Feel free to modify the script to your needs and check out another script from Helge Klein and Dieter Schmitz dealing with client profile migration. The script here can easily be integrated into the script for client migration to combine both efforts.