One of the most looked at topics on this blogpost is the ImmutableID series for Azure AD Connect and AADSync. And I wanted to give an update to this, given the latest versions of Azure AD Connect seemed to have adopted the idea to use the ms-ds-ConsistencyGuid (or any other value) to replace the ImmutableID used for synchronization. Don’t worry, please keep reading the other posts, as they clearly explain the how behind the idea of using the alternative ImmutableID.. and this post is just to tell you.. Microsoft has made the implementation a lot easier!
Upgrading Azure AD Connect
It is vital that when you have configured an alternative ImmutableID (with the custom rule-set) that you take care when you upgrade the Azure AD Connect software. If you don’t the new rule-set configured will be placed next to the custom rules (without disabling them). This cause the entire synchronization process to halt and you will receive errors in the eventvwr and if you manually try to synchronize.
So, how to upgrade? First of all, draw out your specific rules that you created. If you just followed my blog for the instructions in AADSync or AzureADConnect, you should be fine by only removing Azure AD Connect and reinstalling it according to the following guide
Configuring an alternative ImmutableID
- Download the latest version of Azure AD Connect
- Uninstall the old version of Azure AD Connect
- Install the latest version of Azure AD Connect and select a Custom installation
- Connect to your tenant during the installation and configure according to your settings up to the following window
On this window you need to make some choices. ONLY If you followed by guide because you had multiple forests that needed to be merged, the unique identifier across forests is the mS-DS-ConsistencyGuid. In any other case, please validate – usually it will be the mail attribute – or any specific field you created if you have a multi-forest replication setup.
If you only have 1 forest and you just used the mS-DS-ConsistencyGuid to be more flexible later-on you can select that users are represented only once across all directories.
Then the second selection box. That is where you specify the mS-DS-ConsistencyGuid. It will be used as the ImmutableID and all rules will be configured for you.
This we can check when we open the Rules Editor after installation. You can check the In From AD – User AccountEnabled rule and then on the transformations tab you will find the SourceAnchor attribute being: IIF(IsPresent([msExchRecipientTypeDetails]),IIF([msExchRecipientTypeDetails]=2,NULL,IIF(“mS-DS-ConsistencyGuid”=”mS-DS-ConsistencyGuid”,IIF(IsPresent([mS-DS-ConsistencyGuid]),IIF(IsString([mS-DS-ConsistencyGuid]),CStr([mS-DS-ConsistencyGuid]),ConvertToBase64([mS-DS-ConsistencyGuid])),……..
Now, note that what we did in our architecture, they did in one line. If the mS-DS-ConsistencyGuid field is empty, they will use the objectGuid by default:
[ELSE] SourceAnchor = IIF(IsString([objectGUID]),CStr([objectGUID]),ConvertToBase64([objectGUID]))) [taken from the same entry of SourceAnchor]
The other changed entry is obviously the SourceAnchorBinary with a similar entry.
Writing back to AD
The second rule that we made earlier was to write the mS-DS-ConsistencyGuid contents back into Active Directory in the case it did not exist. Which is exactly what the wizard does today as well. Looking at the Outbound rule set, you will find the outgoing ImmutableID rule:
mS-DS-ConsistencyGUID = IIF(IsPresent([sourceAnchorBinary]),[sourceAnchorBinary],IgnoreThisFlow)
[translated into: mS-DS-ConsistencyGuid = sourceAnhorBinary, unless it is empty]
Another writeback 
When preparing for my presentations, I noticed that another addition was made in the attribute flow. In short, the flow is now that when an object is created on Azure AD this object gets a “Cloud Anchor” attribute (not to be confused with the on-premises initiated “CloudSourceAnchor” attribute). This Cloud Anchor is replicated back into the Azure AD Connect Metaverse as the “Cloud Anchor” (where [aad]CloudSourceAnchor=[metaverse]sourceAnchor=base64[AD]msDs-ConsistencyGuid/ObjectGUID) – that CloudAnchor attribute is written back to the connected AD objects in a new attribute called msDS-ExternalDirectoryObjectID this attribute should also be applicable to groups – and thus can help us with ADMT migrations…
Because of this attribute, even changing the objectGUID or msDS-ConsistencyGuid allows Azure AD Connect to still find a link between objects in AD and AAD
If you selected to use a federated domain (and thus ADFS) and you chose to have Azure AD Connect to configure your ADFS farm, the changes to the ADFS ruleset are also automatically applied by the wizard and thus no changes are required anymore after installation.
Configuring the ImmutableID to be something else than objectGuid has become much easier.. and even better, now supported as well. There is no need to go and hack the rule-set just to configure this.. (but for partial password replication, you’d still need to.. – lets hope Microsoft embeds that option in there too 😉 )