Is the last post we looked at a vanilla user account migration, assuming a clean target domain.
There may be a situation where the users have already been created in the target domain with a different sAMAccountName. For example, the user Branch Warren might have the sAMAccountName of bwarren in the source domain but branch.warren in the target.
Source
Target
To get around this you can use an include file to map these different sAMAccountNames together when migrating. The include file is in the following format, and if we use the example above would look like this:
Sourcename,TargetSAM,TargetUPN bwarren,branch.warren,branch.warren@target.local
Creating the Include File
To generate this list you can use CSVDE to pull out the required information from the two forests. The final include file will require a bit of manual preparation to get into the correct format.
From the source domain:
csvde -d "OU=source,DC=source,DC=local" -f sourceinclude.csv -l "sAMAccountName"
From the target domain:
csvde -d "OU=target,DC=target,DC=local" -f targetinclude.csv -l "sAMAccountName, userPrincipalName"
Create the include CSV file in the same format as the example above, I’ve created three users which I need to migrate and merge with an include file.
Sourcename,TargetSAM,TargetUPN jjackson,Johnnie.Jackson,Johnnie.Jackson@target.local jcutler,jay.cutler,jay.cutler@target.local bwarren,branch.warren,branch.warren@target.local
Once you have this in place, the migration process is very similar to the method outlined in the last blog post. When you are asked to select users, choose Read objects from an include file, specify the Include file you created above.
Clear all check boxes.
When you get to the conflict management screen, choose Migrate and merge conflicting, leave both tick boxes empty.
Click finish, and view log. Here you can see the account being merged, passwords being migrated and sIDHistory completed.
If you open up one of the users, you can see the attributes have been carried across from the source domain user.
Migrating Only the siDHistory
When you migrate users, all attributes are carried across unless otherwise specified. There may be a scenario where the user objects in the target domain need to be kept untouched but siDHistory brought across. You can achieve this with the object property exclusion options. Run through the user migration and tick Exclude specific object properties from migration, select object type User and move all attributes into the excluded properties box.
Run through and finish the rest of the wizard. You can confirm that only the siDHistory has been brought across by running ldifde and comparing the two files.
Run before:
ldifde -f user_before.ldf -d "CN=lee.priest,OU=target,DC=target,DC=local
Run after:
ldifde -f user_after.ldf -d "CN=lee.priest,OU=target,DC=target,DC=local
Winmerge is a pretty handy tool to compare two files, here they are side-by-side:
ADMT Series – 1. Preparing Active Directory
ADMT Series – 2. Preparing the ADMT Machine
ADMT Series – 3. SID History
ADMT Series – 4. Password Export Server
ADMT Series – 5. Machine Preparation
ADMT Series – 6. Service Account Migration Wizard
ADMT Series – 7. Group Account Migration Wizard
ADMT Series – 8. User Account Migration Wizard
ADMT Series – 9. Merging Users with a Different sAMAccountName
ADMT Series – 10. Security Translation Wizard – Local Profiles
ADMT Series – 11. Computer Migration Wizard
October 27, 2014 at 10:15 pm
Will this help in linking user to the old profiles on the their desktops?
October 30, 2014 at 9:22 pm
Hi Julian
No, you need to look at part 10. Security Translation Wizard.
Tom
December 3, 2014 at 4:22 am
Thanks for the response Tom, I’m also having an issue with the sid history. I’m getting the following error ” Could not verify auditing and TcpipClientSupport on domains. Will not be able to migrate SID’s. Access denied.” can you point me in the right direction? I’m not sure what I missed.
Thanks
December 9, 2014 at 9:02 pm
Julian – Please refer to the ADMT Migration guide here: http://www.microsoft.com/en-gb/download/confirmation.aspx?id=19188. Specifically pages 52/53 and 254.
December 17, 2014 at 9:57 pm
Thanks found my issues, not added in my ADMT user to local admin.
February 24, 2015 at 12:15 am
I thank you very much for this tutorial, for it is exactly what I needed, and it answered my expectations about merging users with diferent samaccountname using ADMT.
Now I can start my migration with less doubts, you’re the best !
Thanks again for sharing this knowledge.
March 26, 2015 at 3:59 pm
Somebody likes bodybuilding!!! 🙂
March 9, 2016 at 1:38 pm
One note I would add to this article regarding the include file.
It is case sensitive. So if your TargetUPN contains cased characters you must make sure to use the exact case in your include file. If not it will rename your existing target UPN with a 0 at the end.
May 15, 2019 at 11:49 pm
I can see that you are definitely a body building fan 🙂