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 Quest Migration Manager (QMM). You can read the Part I (User Account Migration and Merging – Part I (ADMT)) of this document in the following link:
http://portal.sivarajan.com/2011/05/user-account-migration-and-merging-part.html
Scenario:
I have 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 which contains a mapping between source and target user accounts. The file encoding type must be ANSI. You can read about this requirement in my following blog:
http://portal.sivarajan.com/2010/12/user-migration-and-input-file-format.html
Here is an example of this input file:
In the above example, my plan is to migrate User1 and merge it with a pre-created user account (12345) in the target domain. The column headers are Source sAMAccountName, Target sAMAccountName and Target Name.
Migration Procedure:
1. Open Quest Migration Manager console. Right click on the Migration node and select New Session option.
Note: Make sure the Account Name matching attributes is selected in the domain pair configuration (Domain Pair –> Properties –> Object Matching).
2. Click Next on the Welcome window.
3. Specify the name in the Name box for this migration session. Click Next.
4. On the Select Object in Source Domain window, click on Import button and select the user input file and click Open.
5. Click Next on Select Objects in Source Domain window.
6. On the Select Target Container window:
a. Click Browse to select the appropriate target OU
b. Select Migrate objects without OUs as a flat list option and
c. Select either
- Merge and move the objects to the new OU –> This option will move the migrated/merged object to the selected OU.
- Merge and leave the account where it was before the migration option –> This option will leave the account where it was before the migration.
d. Click Next.
7. On the Set Security Settings window, select appropriate options. Click Next.
8. On the Specify Object Processing Options window, select appropriate options. Click Next.
9. Click Next on the Specify Object Processing Options window.
10. On the Select Migration Agent window, select the correct DSA as the migration agent server. Click Next.
11. Click Next on the Migrate Active Directory Objects window.
12. Click Yes on the Migration Wizard Popup window. Migration process status will display on the status windows
14. Select View log button on the Completing the Migration Wizard windows to verify the log file.
15. Click Finish to complete the user migration process.
sIDHistory
You can verify the sIDHistory value using ADSI Editor or one of the following scripts. The sIDHistory value should be equal to the ObjectSID in the source domain.
Verify sIDHistory and Identify the Source User Account - http://portal.sivarajan.com/2011/03/verify-sidhistory-and-identify-source.html
siDHistory Report - with Multi Value Support - http://portal.sivarajan.com/2011/04/sidhistory-report-with-multi-value.html
Generate sidHistory Report using DSQUERY command - http://portal.sivarajan.com/2011/01/generate-sidhistory-report-using.html
![[image7.png]](http://lh6.ggpht.com/_kv_Du1FpJkk/TS00nUQDpTI/AAAAAAAAAmY/7QOagWBA3Nw/s1600/image7.png)
QMM Directory Synchronization
If you are planning to use Quest directory synchronization, you can enable the directory synchronization after the user migration. QMM will update the user information (user properties, group membership etc) based the QMM matching attribute value (adminDescription & adminDisplayName or ExtensionAttribute 14 and 15). These values get populated during the user migration.
Other Related Blogs & Articles:
Active Directory Migration Using ADMT - http://www.sivarajan.com/admt.html
Computer Migration - Things to Consider - http://www.sivarajan.com/cm.html
User Account Migration and Merging Using ADMT - http://www.sivarajan.com/
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
9 comments:
Hi Santhosh,
could you please clarify two things regarding this Merge Document for QMM.
1.Manually Re created users in target are having same sam account name of source, still can i use these similar steps ?
2 On selecte target container page of this doc, you have mentioned as below to select but in screenshot the option is different, please clarify , which is correct ??
c. Select Merge and leave the account where it was before the migration option.
>>>1.Manually Re created users in target are having same sam account name of source, still can i use these similar steps ?
What do you mean by “re-created”? re-created after the QMM process? Anyway, you can use the same procedure for manually created users. Make sure there is no QMM attributes are populated (by default, adminDispaly, adminDescription & EA13 and EA14)
>>> 2 On selecte target container page of this doc, you have mentioned as below to select but in screenshot the option is different, please clarify , which is correct ??
I have updated the sentence in the blog. Technically, these options are not going make any difference in the migration process. This is your destination location.
Merge and leave the account where it was before the migration option -> option will NOT move the migrated/merged object to a new OU.
Merge and move the object to the new OU -> This option will MOVE the object to the selected OU.
Hi Santhosh,
Group migration is the same procedure? I must migrate first users or groups?
Regards
Yes. You can use the same procedure for Group migration also.
Technically, it doesn’t matter. However, I always recommend to migrate groups first.
Are you using Quest and Directory Sync? Keep in mind that Quest Dirsync will only synchronize based on Quest matching attribute. You can’t do Many -> One group membership sync.
Yes I use Directory Synchronisation. Need a Quest licence for a group migration?
Sorry, I dont understand your last sentence.
User, group, computer migration and synchronization are part of AD migration license suite. If you have AD migration license, you don’t need separate license for Group migration piece.
HI I have a query, is it possible to create a report that shows you which accounts, are currently being synchronised by Quest?
You have a few options. If you have Quest Statistic Portal configured you can get the details from there. Or you can query Active Directory using your Quest matching attribute. Synchronized objects will have a matching attribute populate with a value. Just perform an LDAP query.
"report that shows you which accounts are currently being synchronised by Quest?"
It sounds like you want to know which accounts are in the scope of directory synchronization component? There is no out of the box report to tell you this. If you go into the properties of the Synchronization node and select "source scope" you will see a Set Filter button. Next to this there is an LDAP filter string - if you copy out this filter string into or ADUC or LDP, this will show you which accounts are actually in scope for direcotry sync.
Post a Comment