How to approach Microsoft Entra ID Connect during “on-prem” migration

These days almost every AD or especially Mail migration has to account for Microsoft Entra ID Connect presence in the environment. I want to cover transition scenario where one AD domain is being migrated into another AD Domain, while migrated objects continue to be synchronized into the Azure cloud.

At the migration start, you will likely be looking at the pre-existing Source AD environment that’s synced into the cloud Azure with Microsoft Entra ID Connect instance. The Target AD environment can be new or pre-existing Domain that belong to a different business which was recently acquired, there are plenty of possible business use scenarios here. And AD objects will need to be migrated into this Target Domain while their cloud identities remain undisturbed. How exactly can this be achieved? At the very high level, Source objects need to be taken out of Microsoft Entra ID Connect Sync scope, while Target objects brought into the scope during the same delta sync cycle, so that sync engine can perform proper object adjustments in its metaverse in such a way, that “into-the-cloud” export operation would not affect pre-existing cloud object: it should not be deleted (worst case) or its attributes adversely affected (for example Email address changed resulting in mail loss, or UPN / password modified preventing user sign on operation). Now let’s get into finer details:

1. Review Microsoft Entra ID Connect to ensure Target AD connection is properly configured. It can be a separate AD connector with certain OUs selected to be in / out of scope, or separate AD partition which is included as part of a single forest AD connector. You need to define and know precisely which Source AD OU will be your “out of scope” landing for migrated objects, and which Target AD OU will be your new “in scope” destination for migrated objects.
   
   
2. Configure sourceAnchor metaverse attribute for proper object’s transition during migration. This Microsoft article has detailed explanation:
   “Microsoft Entra ID Connect: Design concepts”
   https://docs.microsoft.com/en-us/azure/active-directory/hybrid/plan-connect-design-concepts#using-msds-consistencyguid-as-sourceanchor but in brief, every object in Microsoft Entra ID Connect space (metaverse) has unique identifier attribute sourceAnchor, much like objectGUID in AD. Microsoft Entra ID Connect (version 1.1.486.0 and older) had objectGUID (AD) => sourceAnchor (Microsoft Entra ID Connect) => immutableID (Azure) attributes correlation where each attribute value, while appear different, is derived one from another and directly related. Starting with Microsoft Entra ID Connect version 1.1.524.0 and later, it is now using ms-DS-ConsistencyGuid as sourceAnchor attribute so single identity with multiple representations now looks like: ms-DS-ConsistencyGuid (AD) => sourceAnchor (Microsoft Entra ID Connect) => immutableID (Azure) making it easier to play with the incoming AD object attribute values because objectGUID value cannot be modified while ms-DS-ConsistencyGuid can be. Here it’s also important that sourceAnchor attribute is configured in the same fashion for the groups because Microsoft Entra ID Connect only has it for users out of the box. The following article is going to explain how to achieve this:
   “Choosing a sourceAnchor for Groups in Multi-Forest Sync with Microsoft Entra ID Connect“
   https://blogs.technet.microsoft.com/markrenoden/2017/10/13/choosing-a-sourceanchor-for-groups-in-multi-forest-sync-with-aad-connect/
   
   NOTE: As of Microsoft Entra ID Connect release Apr 02, 2020 1.5.18.0 it’s no longer required to modify any rules for proper group’s matching per release notes below:
   

   -Added support for the mS-DS-ConsistencyGuid feature for group objects. This allows you to move groups between forests or reconnect groups in AD to Microsoft Entra ID where the AD group objectID has changed, e.g. when an AD server is rebuilt after a calamity. For more information see Moving groups between forests.
   -The mS-DS-ConsistencyGuid attribute is automatically set on all synced groups and you do not have to do anything to enable this feature.

3. Ensure your migration product (QMM in my case) is going to bring ms-DS-ConsistencyGuid attribute over for users and groups, so that while Target migrated object will have new / different objectGUID attribute value, its ms-DS-ConsistencyGuid will remain the same.
   
   
4. The same goes for Email / UPN and any other key attributes that might affect the object in the cloud, because once Target migrated object is re-joined to the object in metaverse, its attributes will be updated with these new (hopefully old!) values flowing into the cloud. Or if your migration is actually allowing for these attributes to change, like new email address during re-branding, make sure that mail flow is prepared to handle these changes.
   
   
5. To eliminate any AD replication effects, ensure Microsoft Entra ID Connect is using the same DCs as your migration product. This is very important because removing Source object out of Microsoft Entra ID Connect scope while Target object is not yet in scope will result in cloud object deletion.
   
   
6. If you are brave enough, you can simply do the next steps sometime in the middle of Microsoft Entra ID Connect delta sync cycle (30 min interval by default) but I recommend to rather put sync on pause via this PowerShell command-let to avoid any surprises:
   Set-ADSyncScheduler -SyncCycleEnabled $false
   
   
7. Now perform migration session and create objects in Target AD in-scope of Microsoft Entra ID Connect (or merge into previously synced objects while bringing key attributes over). After confirming that objects are now properly created in Target AD and seat in the “in scope” Microsoft Entra ID Connect OU, move Source objects into “out of scope” OU. In particular I used a combination of QMM XML Add-in and PowerShell script so that 1) Migration session is marking extensionAttribute15 as “QMM_MIGRATED” on each Source migrated object 2) PowerShell script is then scheduled to run every 5 min monitoring AD for every objects with such attribute value, moving them into the “out of scope” OU.
   
   
8. At this point you can simply wait letting AD to replicate, or if certain that Microsoft Entra ID Connect will be using those DCs that have all latest AD changes, start re-enabling Microsoft Entra ID Connect sync. There are few ways here: 1) Manually right-clicking on each connector (AD then Microsoft Entra ID) in the GUI and selecting corresponding AD Sync cycle: Import / Delta Sync / Export which allows you to review result of each operation. 2) Force one time delta sync cycle:
   Start-ADSyncSyncCycle -PolicyType Delta
   and then examine results 3) Finally re-enable Microsoft Entra ID Connect Sync via:
   Set-ADSyncScheduler -SyncCycleEnabled $true