Choosing a sourceAnchor for Multi-Forest Sync with AAD Connect – Part 7, Migrating Users

Part 1, Introduction

Part 2, Lab Setup

Part 3, An Aside on EmployeeID

Part 4, Using msDS-SourceAnchor

Part 5, Using mS-DS-ConsistencyGuid

Part 6, Moving off objectGuid

Part 7, Migrating Users

Tools

I’m going to assume you’re using the Active Directory Migration Toolkit (ADMT). This is what I’ve tested with and can confirm works.

Migration Process

Here, I won’t be stepping through the use of ADMT. That’s not what I want to discuss. I just want to make the migration process clear so that you don’t lose any objects. Here we go –

1. Keep the user objects you want to migrate between Forests in scope for AAD Connect synchronisation. By this I mean, leave it in an OU that AAD Connect is synchronising
2. Migrate the users so that they are also in scope for AAD Connect synchronisation in the destination Forest – they should land in an OU that AAD Connect is synchronising
3. Make an edit to a replicated attribute on the destination user object and validate that this shows up in the Azure Active Directory tenant after the next sync cycle (Description attribute for example)
4. Move the object out of scope for AAD Connect synchronisation in the source Forest (and potentially delete/decommission it)

Example

I start with my synchronised users. I’m going to migrate forest2user over to forest1.com

Source user is in a synchronised OU –

After migration, the user object is in a synchronised OU –

At this point, both objects are synchronising into a merged object in the AAD Connect Metaverse. An attribute change on either object will propagate to the Azure Active Directory tenant. I make an edit to the Department attribute on the destination user object –

And now I see this after a sync in the Azure Active Directory tenant –

I am now able to decommission the user object in the source Forest.

Conclusion

This series has covered the proper use of a sourceAnchor for an AAD Connect deployment synchronising multiple Forests to an Azure Active Directory tenant. With the right configuration, user migration between Forests is successful without object duplication in the tenant.