This post will cover the Security Translation Wizard from the context of migrating local user account profiles into the target domain. This step is crucial if you want your users to maintain the same local profile. The Translation Wizard needs to be run before migrating the computers. If you decide to skip this step, the users will receive a new profile when they logon to the target domain for the first time:
Be aware this process can take some time, I’ve seen it take up to 40-45 minutes on some older laptops.
Translation Security Wizard – For Local Profiles
From the ADMT machine, run ADMT and select Security Translation Wizard.
Next.
If you have migrated the source domain user accounts, you can select Previously Migrated Objects- this will pull the list of the source and target SIDs from the ADMT database for mapping across the new permissions. This is probably the best method if you have migrated the users across, or if you don’t need granular control over the process.
You can use a SID mapping file to link two accounts from the source and target domain. In the migration I recently went through, the accounts had already been created in the target domain, and there was no requirement for SID history. I decided that merging the user accounts wasn’t necessary. As I hadn’t migrated the users I was unable to use the previously migrated objects option, as ADMT has no history of the account SIDs in the ADMT database. A SID mapping file was used instead.
The SID Mapping file can be in the following formats:
|
1
|
OldSID,NewSID |
or
|
1
|
OldSID,TARGET\USER |
or
|
1
|
SOURCE\USER,TARGET\USER |
For demonstration purposes I have migrated a bunch of users accounts so I can choose the previously migrated objects option.
Select the source and target domain, you can also select which specific domain controller to use.
Select computers from the domain or use an include file.
We will be translating profiles on a Windows XP SP3 test machine.
Choose the objects you wish to translate.
Files and folders – Select this option to translate security on files and folders on the targeted computer.
Local groups – Select this option to translate security on the local groups on the targeted computer.
Printers – Select this option to translate security on the local printers that are configured on the targeted computer.
Registry – Select this option to translate security on registry settings on the targeted computer.
Shares – Select this option to translate security on the shared resources on the targeted computer.
User profiles – Select this option to translate security on the local user profiles on the targeted computer.
User rights – Select this option to translate security on the user rights on the targeted computer.
Here you can choose to replace, add or remove the permissions. Add is the safest option and is what I would recommend in most cases.
Select Finish.
Run the pre-check and make sure it passes, then choose run pre-check and agent operation.
If you click on Agent Detail and View Log you will be able to see what actions have been carried out. We have already migrated the user Ronnie Coleman so we see:
2012-05-19 17:00:36 Translating user profile, source account='Ronnie.Coleman', target account='Ronnie.Coleman'
After the profiles have been translated you will want to migrate the computers straight away.
What happens to the profile?
To show you what’s happened I’ve logged into XP1. You can see that the target user has been granted full permission over the local profile. As we chose the Add option, the source domain user also maintains access.
The migrated user in the target domain has been added to the profile list in the registry, and the profile is pointing to the source user’s profile. You can view this under HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\ProfileList.
Target SID / User
Source SID / User
The next part of the series will run through migrating the computer objects and computer domain affiliation to the target domain.
