I’ve got a question that I did raise with Quest support but they said it was question for PSO as they were more break fix. The scenario I have is simple: Single Source forest migration to single target forest using QMMAD Each forest has its own Exchange Organisation in a multiforest Hybrid to a single tenant Microsoft AAD Connect is configured in Target synchronising both source and target objects with “ms-ds-constencyGUID” as the object anchor All mailboxes in source and target are within 365 with local recipient type as “remote mailbox” Migration approach Given that we are using a migratable source anchor already we migrate the object using QMMAD in a disabled state We use a custom addin is used which is a slightly altered version of the Quest OOB xml which ensures our key exchange attributes are copied to target (target address, proxy addresses, mail nickname, recipient type etc) Microsoft AADC joins the two objects across the two forest as the ms-ds-constencyGUID matches and AzureAD projections occur from the Source as the target object is disabled as per the OOB “account enabled” sync rule When we are ready to switch the user we rerun a migration session disabling the Source and enabling the target object Microsoft AADC now starts projecting attributes from the target object as per the OOB “account enabled” sync rule We remove the Source object from the AADC sync scope which disconnects the join from AADC bringing the AzureAD object back to a 1:1 sync This all works well and I have used this approach numerous times. The question that I have is that this particular environment previously has had Galsync configured. This means that following scenarios I need to try and find a way around: Migrating Source Users to the target and wanting to merge with already existing target contacts Migrating Source Contacts to the target and wanting to merge with already existing target users This scenario is loosely played out here - https://support.quest.com/kb/27811/how-does-migration-manager-handle-merging-scenarios-when-contacts-and-mail-enabled-users-match described in scenarios 1 and 2, however this article is very old and expects you to be configuring Exchange attributes using Dirsync. I do see the option to “merge with contact” however without knowing the underlying workflow of what this did id be at risk of some unwanted results given it was written for Onprem to Onprem migrations. Therefore my question is around how in a modern day world with 365 everywhere can we solve the contact merging question given that it was previously solved Exchange to Exchange migrations. Are there anything that your guys use or pointers I can get?

AD migration, with mailboxes in office365 and needing to merge with existing contacts in target (previous Galsync)

I’ve got a question that I did raise with Quest support but they said it was question for PSO as they were more break fix.

The scenario I have is simple:

Single Source forest migration to single target forest using QMMAD
Each forest has its own Exchange Organisation in a multiforest Hybrid to a single tenant
Microsoft AAD Connect is configured in Target synchronising both source and target objects with “ms-ds-constencyGUID” as the object anchor
All mailboxes in source and target are within 365 with local recipient type as “remote mailbox”

Migration approach

Given that we are using a migratable source anchor already we migrate the object using QMMAD in a disabled state
- We use a custom addin is used which is a slightly altered version of the Quest OOB xml which ensures our key exchange attributes are copied to target (target address, proxy addresses, mail nickname, recipient type etc)
- Microsoft AADC joins the two objects across the two forest as the ms-ds-constencyGUID matches and AzureAD projections occur from the Source as the target object is disabled as per the OOB “account enabled” sync rule
When we are ready to switch the user we rerun a migration session disabling the Source and enabling the target object
- Microsoft AADC now starts projecting attributes from the target object as per the OOB “account enabled” sync rule
- We remove the Source object from the AADC sync scope which disconnects the join from AADC bringing the AzureAD object back to a 1:1 sync

This all works well and I have used this approach numerous times. The question that I have is that this particular environment previously has had Galsync configured. This means that following scenarios I need to try and find a way around:

Migrating Source Users to the target and wanting to merge with already existing target contacts
Migrating Source Contacts to the target and wanting to merge with already existing target users

This scenario is loosely played out here - https://support.quest.com/kb/27811/how-does-migration-manager-handle-merging-scenarios-when-contacts-and-mail-enabled-users-match described in scenarios 1 and 2, however this article is very old and expects you to be configuring Exchange attributes using Dirsync. I do see the option to “merge with contact” however without knowing the underlying workflow of what this did id be at risk of some unwanted results given it was written for Onprem to Onprem migrations.

Therefore my question is around how in a modern day world with 365 everywhere can we solve the contact merging question given that it was previously solved Exchange to Exchange migrations. Are there anything that your guys use or pointers I can get?

0 MBILLI1 over 3 years ago

Hi Graham,

I broke the queries and questions down below as best we could, I think you should contact Quest Professional Services to form a migration plan for the customer in question, hopefully the below information helps with the understanding and possiblities.

Migrating Source Users to the target and wanting to merge with already existing target contacts
-Yes DMA can match and merge with the target contact, but it can only do so with customization of the matching rules, and mapping of the attributes. It will not consume the target contact as DSA can with onprem objects, it will only match and populate the target attribute data with source data if possible.

Migrating Source Contacts to the target and wanting to merge with already existing target users
-Yes DMA can match and merge with the target User, but as above, it will only bring over the attribute data it can populate on the target object with source data.

Custom mapping and matching has to be configured in the DMA console, usually this will be configured by Quest Professional Services.

Regards Mark
Cancel
Up 0 Down

Reply

Verify Answer

Cancel