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
24 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.
Hi Santhosh,
I am trying to configure QMM the scenario as follows
Intraforest
Migrate the 2 child domains to the root domain
Interforest
Migrate domain from a different forest
1) When I am trying to merge an account from different forest, it is throwing error? Is there any prerequisite I need to take. Do I need to configure any QMM attributes to make this work.
2) For approximately 3000 Users/800 servers environmet How many QMM servers recommended / in this case, do I need to use the same ADAM database even if I install the
console on a different system using open project.
Thanks in advance.
What is the error message?
>>> For approximately 3000 Users/800 servers environmet How many QMM servers recommended
It has nothing to do with no. of users or servers. You can do all migration using a single server. However it is a best practice to have different/dedicated DSAs. Are you migrating any mailboxes?
You need only one ADAM. How many projects are you planning to create and why?
Santhosh
Windows 2012 Migration - http://www.amazon.com/dp/1849687447/?tag=packtpubli-20
>>>> "report that shows you which accounts are
currently being synchronised by Quest?"
What are you talking about here? May be I am missing something. Please provide more information.
Thanks Santhosh for the response.
Below is the message. I found a quest article relates to this and its talks about the attributes. Do I really need to set the attributes for ech domain pairs?
Error 0xe3000005. Target object matched by the following high-priority matching rule: adminDisplayName=4C3D556E839AB74BBCC993742FC61966 has already been matched with another source object by the following low-priority matching rule: objectClass=top#person#organizationalPerson#user
Sorry I missed other questions.
How many projects are you planning to create and why?
I thought of creating 1 project for all there and domain pairs and faciltate the migration for multiple people install console on other systems use open project option and connect to the same ADAM. (Is it the recommened option?)
Are you migrating any mailboxes?
Not now , It is LN environment and it will be handled as next phase.
Jiji Philip,
“adminDisplayName=4C3D556E839AB74BBCC993742FC61966 has already been matched with another source”
It is basically saying you already have a migrated object in target. You are using adminDisplayName as QMM service attribute.
You need select Service attribute for each domain pair. By default, if you don’t have Ex schema, it will be adminDisplayName and adminDescription. If you have EX schema, it will be EA14 and EA15.
One project should be enough
Thanks Santhosh for the response.
I have 3 Domains in scope for Migration, so 3 Domain pairs
If I am not setting up the service attributes for the domain pairs, it will take the Default values and it may be conflict with other entries
In this case can I set below attributes for each domain pair repecctively?
Source1 --> Destination
Source & Target service Attributes
Object Class Attributes
Auxilary: AdminDescription
Matching: AdminDisplayName
Source2 --> Destination
Source & Target service Attributes
Object Class Attributes
Auxilary: allowedAttributes
Matching: displayNamePrintable
Source3 --> Destination
Source & Target service Attributes
Object Class Attributes
Auxilary: distinguishedName
Matching: displayName
Please confirm..
>>>>If I am not setting up the service attributes for the domain pairs, it will take the Default values and it may be conflict with other entries
This is NOT 100% true. I always recommend selecting your Auxiliary and Matching attribute.
Look at you 3rd domain pair. It has displayName as matching attribute. What will happen if you have a conflict with Display Name and that object was migrated/synchronized using Domain Pair 1? You will get the error you mentioned in the initial question
“Error 0xe3000005. Target object matched by the following high-priority matching rule: adminDisplayName=4C3D556E839AB74BBCC993742FC61966 has already been matched with another source”
Pardon my ignorance about this, still I am bit confused about the service attribute usage and functionality. Based on your comment I beleive that displayname is not a good matching attribute,so can you suggest any other attribute that I can use.Thanks in advance
Hi Santosh, I have similar issue in my environment can help on this
I have some requirement to migrate from A domain to B domain domain under root domain in single forest then collapse the A domain. here is my requirement
using Quest Migration Manager
1. User & security groups migration to B domain from A domain
2. Exchange servers and Mailboxes are in B domain
3. Lync configurations also in B domain.
4. A domain has many nested groups and procedure to migrate the nested groups migration
Can you please provide your guidance and steps to start..
Thanks in advance
Mastan
Please provide more information about your requirement and environment.
So all resources are going to a single domain? If so, that is a straight forward migration.
Thanks for your reply. May I know the steps to start the process and any link to setup Lync object migration.
Currently I am using Quest 8.9 Version,
in current setup like , merging the sid history to target domain.
1. Is it possible to Nested Group Migration in QMM 8.9 ? If yes ,May I know the steps or any weblink?
2. Lync object setup and migration steps in QMM8.9?
3. Any prerequisites to be follow?
Thanks
Mastan.S
Post a Comment