How to approach Azure AD Connect during migration

These days almost every AD or especially Mail migration has to account for Azure AD 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.

Migration View

At the migration start, you will likely be looking at the pre-existing Source AD environment that’s synced into the cloud Azure with AAD 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 AAD 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 AAD 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:
    “Azure AD 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 AAD Connect space (metaverse) has unique identifier attribute sourceAnchor, much like objectGUID in AD. Azure AD Connect (version 1.1.486.0 and older) had objectGUID (AD) => sourceAnchor (AAD Connect) => immutableID (Azure) attributes correlation where each attribute value, while appear different, is derived one from another and directly related. Starting with Azure AD 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 (AAD 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 AAD 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 AAD Connect
    https://blogs.technet.microsoft.com/markrenoden/2017/10/13/choosing-a-sourceanchor-for-groups-in-multi-forest-sync-with-aad-connect/
  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 AAD Connect is using the same DCs as your migration product. This is very important because removing Source object out of AAD 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 AAD 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 AAD 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” AAD 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 AAD Connect will be using those DCs that have all latest AD changes, start re-enabling AAD Connect sync. There are few ways here: 1) Manually right-clicking on each connector (AD then Azure AD) 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 AAD Connect Sync via:
    Set-ADSyncScheduler -SyncCycleEnabled $true

Tags:

Leave a Reply