Friday, May 6, 2011

User Account Migration and Merging – Part I (ADMT)

Part I - User Account Migration and Merging Using ADMT

Part II - User Account Migration and Merging Using QMM

pre-creating user account in the target domain is a common scenario these days due to single-sign-on solution, HR management procedure etc.  This will make the user migrate procedure more challenging.  During the migration you need to make sure these accounts are properly “merged” with correct SID information.  

In this example, I will explain a procedure to migrate and merge user accounts using Active Directory Migration Tool (ADMT).  In Part II of this document I will explain the account migration and merging procedure using Quest Migration Manager (QMM). 

Scenario:

I have a pre-created user accounts in the target domain.  Their logon name (samAccoutnName) is different in the target domain.  My goal to migrate an account from the source domain, merge it with the corresponding account in the target domain and maintain the source SID in the migrated object.

Migration Plan:

My plan is to use an input file (include file) for the migration.  This file contains a mapping between source and target user account.  I am using a TXT file. You can use CSV or any other format.  Here is an example of my include file:

image

Migration Procedure:

1.  Open Active Directory Migration Tool console. 

2.  Right click on the Active Directory Migration Tool node and select User Account Migration Wizard. 

image

3.  On the Welcome window, select the correct source and target domains and domain controllers.  Click Next

image

4.  Select Read object from an include file option on the User Selection Option window.  Click Next

image

5.  In the Input File Selection window, click Browse and select the previously created include file.  Click Next

image

6.  On the Organization Unit Selection window, select the correct destination OU.  Click Next

image

6.  Select appropriate option on the Password Options window.  Click Next

image

7.  Select appropriate option on the Password Options window. Make sure to select Migrate user SIDs to target domain option.  Click Next.

image

8.  On the User Account window, enter the proper credentials.  Click Next

image

9.  Select appropriate options on the User Options window.  Click Next. 

image

10. Select appropriate options on the Object Properties Exclusion window. Click Next.

image

11.  Select the following options on the Conflict Management window.  Click Next

    • Migrate and merge conflicting objects
    • Uncheck Before merging remove user rights for existing target account – I have some pre-assigned groups and don’t want to remove those. 
    • select Move merged objects to the specified target Organizational Unit – I am moving user objects from a pre-created OU to Migrated OU after the migration. 

image

12.  Click Finish to complete the user migration process. 

image

13.  You will see the migration status on the Migration Process window. 

image

Your target account should be merged and have the same SID in the sIDHistory attribute. 

Sid and sIDHisotry Info:

When a User object migrated from one domain to another, a new SID must be generated for the user account and stored in the ObjectSID property. Before the new value is written to the property, the previous value (ObjectSID from source domain) is copied to another property of a User object, sIDHistory in the Target domain. So you can use the sIDHistory value to search the Source domain using the ObjectSID attributes to identify the corresponding user in the Source domain. In other words, the sIDHistory value will be equal to the source ObjectSID.  You can SID and sIDHistory using the following procedure:

http://portal.sivarajan.com/2011/03/verify-sidhistory-and-identify-source.html

image

Other Related Articles:

Active Directory Migration Using ADMT  - http://www.sivarajan.com/admt.html

Computer Migration - Things to Consider - http://www.sivarajan.com/cm.html

ADMT Include File - http://portal.sivarajan.com/2011/06/admt-include-file.html

User Migration and Input File Format - http://portal.sivarajan.com/2010/12/user-migration-and-input-file-format.html

34 comments:

super really interesting..

This helped alot. Thank you for posting this article. I have accounts that I need to merge which have different names

Thanks for the feedback. I will be publishing the Part-II next week.

Good information for those who need to do AD migration. Thanks for the post.

Hello Sivarajan,

I saw you answer on this thread


I did admt to all users and groups but the primary groups of all migrated users are "domain users"

I'm looking for some script which can set the primary group for the migrated users

( i can't delete the users object now)

I need to export all user's primary groups from domain A
and import it back to all users in domain B.


do you have some script that can do this?

I guess you already found the solution based on this thread?

http://sivarajan.com/forum/viewthread.php?tid=185#pid706

You are really great.Helping to others in such a nice way really appricated

You are welcome :) and appreciate your feedback!

Do you know if there is a way to exclude attributes like "DisplayName"?
Thanks in advice

This comment has been removed by a blog administrator.

Eddie,
Just wanted to understated your requirement first..why do you need to exclude DisplayName? What are you trying to accomplish?

Santhosh - following this article, step 6 says to select the correct destination OU. But I have sub-OU's with multiple users, and all these users get migrated to the parent OU. How do I migrate the users to their proper OU in the target domain?

Hi Santhosh,

I have a query...

In domain A - user have exclusive access to some shared folders.

In domain B - Instead of migration, new users have been created with different logon name.

Now, I want to merge old SID (domain A) to new user's SIDHistory (Domain B), so that user can access shares using domain B credentials.
I followed all the steps mention above and got source SID in sidHistory in Target, but still unable to access share folder. any advice ?

I also check , that SID filtering is disable in both trusting and trusted domain.

Opps !! I got the answer now.

I forgot to enable SID history in target domain :)

We can access resource in source domain from target after SID migration anf merging.

command to enable SID history:

netdom trust trusted_domain /domain:trusting_domain /enablesidhistory:yes

how to prepare include file

Hi , I am planning to migrate user and groups from windows 2003 domain into Windows 2008 R2 domain in a separate forest. However we have been told there won’t trust and network connectivity between 2 domains. What would be the best approach to migrate users and groups across the target domain?

Also even if we have network connectivity between 2 domains , can we use ADMT 3.2 without setting up a trust to migrate users and groups along with SID?

Awesome info, I am in the design stage of a migration to a new domain and am trying to decide if we should move to new IDs or keep our existing. The problem is the ID is based on the employee ID and that is changing, so I would like to change and be consistent, but am worried this will create many down stream issues with applications that have authirization or user tables based on the ID. Any suggestions or benefits for one over the other?

Include file – I have included a screenshot. You can use any script or automated option.

chrisbuzby,
Change the ID (samAccountName) won’t cause any issues. Because permission is based on SID (objectSID)not names.

dzlondon,
Trust is a requirement for ADMT. If you can’t establish trust because of network issues, you can try an “offline” migration.

1. Create a DC from your source domain (add addition DC)
2. Move this DC to your target domain network
3. Transfer all FSMO roles and make it an independent domain/forest. Make sure this network is isolated from Source domain network.
4. Create domain trust from this domain and migrate all users and groups

FYI..You can’t migrate computer with this option.

Pramod Khandelwal,
If it is a Forest trust, you need to manually enable SID History.

Hi Santhosh,

I want a script through which i can fetch out all migrated users list

Please provide more information. What do you mean by “fetch out all migrated users list”?

You can see my scripts in:

http://portal.sivarajan.com/search?q=script&x=0&y=0

http://gallery.technet.microsoft.com/scriptcenter/site/profile?userName=Santhosh%20Sivarajan-

This comment has been removed by the author.

I am having difficulty migrating a DMZ domain to an internal domain. I just need to migrate users, groups and passwords. Each domain is in a separate forest and neither of them are the root domain. I created a two-way external trust between DomA and DomB. DomA is in the DomA root domain with 2 other domains (4 domains total - Primary network) and DomB is in the DomB root domain (2 domains total - root and DomB - 4 total servers: RootDC1, RootDC2, DomBPDC, DomBDC2). I had a firewall rule created to allow all traffic both ways between DomA's PDC and DomB's PDC also allow all traffic both ways for ADMT01 (Server that has ADMT installed and resides in DomA) and DomB's PDC. DomA and DomB share the same DNS server so I did not have to worry about DNS. I was able to create an External Trust between DomA and DomB. My issue was when I was selecting the Target Domain and the Source Domain in ADMT. I was able to select the source domain, DomB, and the domain controller DomBPDC. I was also able to select the target domain, DomA, and the domain controller DomAPDC. Once I tried to go to the next step it gave me the following error message: Error: ADMT is unable to connect to domain controller \\DomBPDC.DomB.com, in domain DomB.com. Access is denied. (0x80070005). I also tried logging in to ADMT01 as DomB Admin and running ADMT as that user, but then got the same error, just the other way: Error: ADMT is unable to connect to domain controller \\DomAPDC\DomA.com, in domain DomA.com. Access is denied. (0x80070005). I have added DomA's admin to DomB's Built-In Administrator Group and vice versa (for testing), DomB's admin to DomA's Built-In Administrator Group.
Notes: - DomB's admin was able to logon to ADMT01 which is in DomA.

For ADMT to work do the root domains need to talk? Do I need to open firewall rules for the root domains? Any suggestions? I have not been able to find any helpful information searching for the error given.

Any help is much appreciated.

Another thing... The DomARootDomain and DomBRootDomain have a transitive forest trust - Do I even need the external trust?

Hi, I have a quick question and was hoping if anyone would have an idea on the answer. I need to re-ACL about 5 million files (13TB). Our fileserver and DCs are on the same virtual cluster, so performance is fast. Does anyone have an idea of how long this would take using ADMT?
Thanks,
Al

Altaf,
I don’t think anyone can give you an exact estimate. It depends on a lot of variables.
You can run re-ACL process in the background. Users won’t notify a difference.

techa07
Sorry. I missed your comment. You still need help?

Hi there - what do you recommend when there is not a two-way trust possible? We have network and DNS connectivity to the source domain. There is a one-way trust where our new domain trusts the old domain. Workstations and servers are in the new domain however all access to resources like File Shares, access to applications...etc is done via the old domain global groups. Users are still logging into the old domain. Users and groups need to be migrated over and then the trust removed. Thanks!

Post a Comment

Popular Posts

Share

Twitter Delicious Facebook Digg Stumbleupon Favorites More