Why you need to use the mS-DS-ConsistencyGUID?

WHAT IS THE MS-DS-CONSISTENCY-GUID?

Say what MS-DS-consistencyGUID an important sync attribute? Yes, true. It’s well known that you need to use the AD Connect tool to copy the on-premises user identities to the Cloud. What’s less common knowledge is that how both identities are connected. So, basically, this attribute functions as the glue.

History

 A couple of years ago, the previous version of what everyone knows as Azure AD connect was released. At that time another attribute was the default unique identifier. This was ObjectID, for a while this was fine. The ObjectID is always a unique value but the disadvantage is that that attribute cannot be changed.

SCENARIO

In large organizations, people are moving to other locations, departments and or offices. This can be a challenge for the user’s Active Directory account. For example when the organization uses one Azure AD tenant for multiple forests (without an AD trust relation). In the picture (left) gives an overview of the situation. But, Tristan describes for me the procedure to create a new account in Forest B and reconnect Enterprise Cloud apps like Office 365.

How to connect a (old) Azure AD Cloud identity to a new user object?

I describe this test scenario based on one AD environment. The described steps are equal in case you are using two AD Forests sync towards one Azure AD tenant.

There are two demo account. The original user account Denmark.user1@talkingworkplace.com and the new account Dutch.user1@talkingworkplace.com

 
Keep in mind;
  • The user is first location into the Denmark and is moved to the Netherlands. The company policy is to create a new identity and decommission the “old” AD account.
  • *The ADMT tool is an alternative solution but this requires a trust relationship between the domains. 

Both AD accounts need to sync towards to Azure AD! The process required two delta syncs because during the first sync the unique identifier is created in Azure AD only. The second sync the identifier is written-back to the AD attribute. *In a default configuration, the delta sync starts automatically every 30 minutes.

You can now wait until the two delta syncs are triggered automatically, use the synchronization service manager or use Powershell (admin privileges required).

Powershell – Start-ADSyncSyncCycle -PolicyType Delta

*It is recommended to add or change the attribute values at a domain controller within the same site. If this is not possible sync all changes with the command

cmd.exe – Repadmin/syncall

 

The screenshot right shows an example of the attribute ms-ds-consistencyGUID value.

Find both value’s you need this later during the process! 

I assigned a (direct) Office 365 license to the denmark.demo1 user account. Because of a e-mail box is created automatically and can prove later on that I have reassigned the Cloud account successfully. 

Now we need to disable the sync both AD accounts towards Azure AD. As soon account are no longer synced the accounts are marked as deleted and placed into the recycle bin for 30 days. We need to finalize the procedure within this time frame. (no worry!)

This first screenshots show that the accounts are removed from the sync. The second screenshots shows the recycle bin.

TIP: You can remove syncing the user accounts when you remove the account (applicable for denmark.user1) or move the user object to a Organization Unit (OU) who is not part of the synced OU’s.

Copy the denmark.user1 consistency to the Dutch accounts and make sure the account is in sync again. For example by move the user object to an OU that is part of the scope that synced to Azure AD.

As soon the account is synced again (delta sync), the change ms-ds-consistencyGUID will take care that the previous account of Denmark.user1 will be reconnected to Dutch.user1.

Make sure you don’t see any new sync error’s appears. 

You can now start cleaning up the user account for example by changing the UPN to the original user name.

** Be careful with this because in case the user account name (demark.user1) is logon earlier and now someone (previously knows as) dutch.user1 with an equal user name but different on-premises AD identifier (ObjectID) logons the a workplace a temporally profile will be created. To avoid this situation it is recommended login on a re-image or another workplace.

Optionally you can change the Azure AD UPN with the script below. ***Only applicable for the login name additional changes are required for the default e-mail address!

Connect-MsolService

$User = get-msoluser -All | where {$_.immutableId -like “*==”} | Out-GridView -PassThru

$newName = Read-Host “Give the new UPN”

Set-MsolUserPrincipalName -ObjectId $user.ObjectID -NewUserPrincipalName “$newname”

Share This