Choosing a sourceAnchor for Multi-Forest Sync with AAD Connect - Part 2, Lab Setup

Update 25th May 2017:- As of AAD Connect May 2017 release, version 1.1.524, the default sourceAnchor used by the setup wizard is mS-DS-ConsistencyGuid. This renders most of this blog post series moot but it will be maintained for reference.

 

This blog post series is based upon and tested with AAD Connect, December 2016 release, version 1.1.380.0. Test all deployment designs before production implementation.

Table of Contents

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

Lab Setup

Before I get into the details, I want to cover to the lab setup I'll be using. It's really simple -

I scope AAD Connect to a single OU in each Active Directory Forest containing my test user -

and

Examining the objects, we see the values of objectGuid, mS-DS-ConsistencyGuid and msDS-SourceAnchor -

and

As you can see, mS-DS-ConsistencyGuid and msDS-SourceAnchor start life as NULL values.

The Metaverse

AAD Connect maintains its own database called the Metaverse. The Metaverse keeps a copy of the objects being synchronised. Connectors between the Metaverse and external databases are associated with rules that define how one attribute value maps to another. In this way, AAD Connect is able to extract information about a user object from an Active Directory database, populate the Metaverse copy with that information (potentially mapping one attribute into another) and then export that information to Azure Active Directory.

Depending on the attribute and the options selected when AAD Connect is configured, some values may flow from Azure Active Directory back to on-premises also.

The Plan

First we need to choose whether to use mS-DS-ConsistencyGuid or msDS-SourceAnchor. If you haven't installed the Windows Server 2016 schema, your only choice is to use ms-DS-ConsistencyGuid.

If you do have the Windows Server 2016 schema, use msDS-SourceAnchor. That's what it's there for and because the attribute syntax is a closer match to sourceAnchor in the Metaverse, it's slightly easier to set up.

Once that choice is made, the high-level logic for the attribute flow remains the same. For the rest of this post, I'll refer to either mS-DS-ConsistencyGuid or msDS-SourceAnchor as the immutableID.

Attribute flow pseudocode is simply -

 if (immutableID == NULL)
{
 populate Metaverse sourceAnchor using objectGuid
    write Metaverse sourceAnchor back into immutableID
}
else
{
    populate Metaverse sourceAnchor using immutableID
}

The implementation of these rules will be slightly different across a few different scenarios which will be covered in later posts.

Conclusion

An immutableID capable of surviving Forest to Forest object migrations may be configured using either mS-DS-ConsistencyGuid or msDS-SourceAnchor.

Comments

• Anonymous
  February 20, 2017
  Thanks
• Anonymous
  June 20, 2017
  How does this work if an org wants to migrate to a new Forest? Users exist in Forest1 and they intend to migrate those users to a new Forest2 at a future date. Problem being that they need to provide Forest1 users with EOL ahead of the user migration to Forest2. Am I correct in thinking that you should deploy AADC to Forest2, then add Forest1 to AADC and scope AADC so that the initial sync of Forest1 users uses mS-DS-ConsistencyGuid for the immutableID. That way when ADMT migrates the users across to Forest2, AADC merges the users and EOL continues to work as before the move?
  • Anonymous
    June 20, 2017
    That's exactly correct. Note also that the latest version of AAD Connect uses mS-DS-ConsistencyGuid by default.
    • Anonymous
      June 21, 2017
      Thanks Mark,Excellent article.
• Anonymous
  October 05, 2017
  I have a situation similar to terry. My org have 2 forests (forest 1 and 2) in 2008 R2 and want to consolidate/migrate users eventualy to a single forest (forest 3) in 2012 R2, but wants to go on production with EOL right now with the 2 existing forests. Which move should we do first? Is it prefferable to create immedialtly and connect the forest 3 with AADC before connecting and syncing forest 1 and 2 with EOL using mS-DS-ConsistencyGuid? If we don't, can we easily add later the 3 forest, move all users to them then remove the forestz 1 and 2? What is the differences to do it immediatly vs later?
  • Anonymous
    October 05, 2017
    It actually doesn't matter. You can have your existing Forests syncing with mS-DS-ConsistencyGuid and then add the new Forest later by re-running the wizard, or you can set them all up at the same time. There's no difference.