During migration it is very important to understand how your actions affect the Target AD. You might get lucky if it’s newly built forest but often this is not the case and Target is full of pre-existing objects which, if something goes wrong (mis-merge, conflict on “mail” attribute etc.), can seriously affect production. Also these types of conflicts end up in the “Conflicts” QMM Directory Sync queue waiting to be resolved. Here I wanted to talk about various cross-forest conflicts that need to be considered during migration scenarios and how to deal with them.
I. “samaccountname”
This attribute is unique per-domain and introducing another object with the same “samaccountname” can either result in 1) undesired object merge if “Merge by Account Name” is enabled; 2) “samaccountname” not migrated properly on the object if “Merge by Account Name” is disabled.
To properly address these types of conflicts, perform Source/Target dumps of AD and match on samaccountname to see if any such conflicts are going to occur. Alternatively use products like Quest Reporter which have ready to use reports on samaccountname. Don’t forget that even if you merge on samaccountname, QMM only considers same object classes for the merge and Group(Source)-to-User(Target) and vice versa types of conflicts need to also be taken into account. The following reports normally need to be reviewed DOMAIN-to-DOMAIN wide:
1. Same object types – depending if merging on “samaccountname”:
a) User(Source)-to-User(Target)[match on samaccountname]
b) Group(Source)-to-Group(Target)[match on samaccountname]
2. Cross-object types:
a) User(Source)-to-Group(Target)[match on samaccountname]
b) Group(Source)-to-User(Target)[match on samaccountname]
Good idea is to rely on Conflict resolution logic in QMM and configure the product to for example add “DUP_” prefix to the conflicted “samaccountname” values.
II “mail”
“mail” or Primary SMTP address from proxyAddresses attribute is unique per-forest. Similar to “samaccountname”, this attribute needs to be carefully analyzed cross-forest on the subject of various conflicts. When “Merge on Email” option is selected QMM can only merge objects within the same object type (user-to-user, group-to-group, contact-to-contact) and if the same email address already exists “cross-object-class” for example Source User conflicts with Target DL, then AD object will still be created but mailbox-enabling (or mail-enabling for group/contact) will fail. [Remember: even if mailboxes are merged by mail, QMM cannot migrate mail into the pre-existing mailbox when using legacy MAPI agents] If however Source User or Group conflicts with the Target Contact then such Contact will be “consumed” (in other words deleted) while all its critical attributes like LEDN, proxyAddresses and DL membership will be inherited by the newly created user mailbox (QMM logic if “Merge objects with corresponding contacts” checkmark selected on “Specify Exchange Options” Tab). If not merging on Email, then migration of conflicting object can fail because mail attribute already exists in Target forest.
The following types of reports are normally reviewed and analyzed FOREST-to-FOREST to fully prepare for the migration:
1. Same object types depending if merging on “mail”:
a) User(Source)-to-User(Target)[match on mail]
b) DL(Source)-to-DL(Target)[match on mail]
c) Contact(Source)-to-Contact(Target)[match on mail]
2. Cross-object types:
a) User(Source)-to-DL(Target)[match on mail]
b) DL(Source)-to-User(Target)[match on mail]
c) Contact(Source)-to-User_AND_DL(Target)[match on mail]
d) User_AND_DL(Source)-to-Contact(Target)[match on mail] (to understand which Target Contacts will be consumed by QMM DirSync)
3. If Exchange Resource Forest scenario is involved:
a) User(Source)-to-User(Target)[match objectSID to msExchMasterAccountSID] (to help identifying objects which already have pre-existing linked mailboxes and might be excluded from migration)
b) User(Source)-to-Enabled_User(Target)[match on mail] (when merging into pre-existing Enabled User, msExchMasterAccountSID will NOT be set and therefore linked mailbox will not be created)
III. Advanced: Instead of “mail” attribute it also might be useful to review multivalued attribute proxyAddresses(Source)-to-proxyAddresses(Target) types of conflicts. This however might quickly get too complex but the good thing is, QMM will simply not migrate such conflicting proxies anyway leaving them in Conflicts queue while, since the primarySMTP (“mail”) is unique, the object itself will come over fine.
POSSIBLE CONFLICTS RESOLUTION ACTIONS:
-Leave as is – let QMM logic to handle the conflict and accept consequences.
-Exclude from migration scope, via for example LDAP exclusion filter (!extensionAttributeX=QMMSkip) or moving objects into separate OU.
-(Recommended but often hard to achieve) Work with the customer and resolve manually depending on type of the conflict.
Good luck with your migration, as you can see it takes a lot of efforts and planning to be successful in it!
