How can I insure “ms-dir-consistencyGUID” would be used for a source anchor and not the “fallback” ObjectGUID.?
If the reason is because you want to be able to move the users over to the other Local AD and rematch them back up, I have done it recently and from my experience the ms-dir-consistencyGUID didn't help in any way.
To explain: In order to match an existing Azure synced user to a different local AD user, the Azure user needs to be as cloud only otherwise the new user will be marked as duplicate. When the user is in cloud only state you can clear the ImmutableID which will cause a soft match next time a cloud sync imports a user with a UPN matching the cloud UPN. Of course you have the ability to leave the immutableID on the cloud object and set the ms-dir-consistencyGUID on the local object to match the cloud one (I have a PowerShell script somewhere if you need), but why go through this hassle?
My migration steps were the following
- Remove users from AzureSync scope on old AD domain (causes the user to be cloud deleted).
- Clear immutable ID (might require cloud restoring the user which converts the user to cloud only)
- Add users to AzureSync scope on new AD domain (causing soft matches based on UPN on next sync).
I also want to be sure that if I do sync these 3 AD's with "Cloud sync" I'm not "cutting off" a path of loading the Full "Azure AD Connect" later on if I needed it for Hybrid Device join.
Per the documentation and my own experience, these two can run side by side with no issues.
But I didn't see mention of going the other way around where you start with AD cloud provision and the need to add in "Azure AD Connect" later on.
I can't find now my notes, but I recall testing this and as long a user was in either scope, even if deleted in the other scope the user stayed cloud synced.