Azure AD Connect Cloud Sync / Azure AD Connect cloud provisioning agent (3 forests - 1 AAD tenant) Moving Users between forests?

Question

Have project that has 3 affiliates each with OnPrem AD (single domain forest) moving to Office365 and they would like everyone to have a common Office 365 logon domain.
So on-prem domains (e.g.: aaa.affiliateA.org, bbb.affiliateB.org, ccc.affilateC.org) and NEED (hard requirement) everyone to have Office 365 cloud exchange e-mails of (user@affiliategroup.org)
No existing trust or vpn between the affiliate offices. None of the affiliates coming from existing 365 exchange online or on-prem exchange.

Just discovered the existence of "Azure Active Directory Connect cloud sync" - lightweight sync agent (vs. Azure AD connect - full sync solution)

Reviewed:
Azure AD Connect cloud sync video
and
Cloud Sync Docs

(1)
How can I insure “ms-dir-consistencyGUID” would be used for a source anchor and not the “fallback” ObjectGUID.?
FAQ’s state:
By default, cloud sync uses ms-ds-consistency-GUID with a fallback to ObjectGUID as source anchor. There is no supported way to change the source anchor.

• and -
  No, cloud sync does not support writeback of ms-ds-consistencyGUID for any object (including user objects).

Expecting it would be likely that we would need move a user from one ad forest to another in the future (aaa\user1 moves to bbb\user1) – so expecting we would need to be able to create on-prem bbb\user1 and copy over the “ms-dir-consistencyGUID” from aaa\user.

(2)
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. Would expect to use "ms-dir-consistencyGUID" in order to facilitate the ability to move users from one forest to another if needed. Documents seem to cover a case where you already have Azure AD Connect (full sync soln) in place and you then want to change rules to use Azure AD Connect cloud provisioning agent for User/contact/group objects. 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.

@Daniel Birmingham - Hoping you are the Daniel Birmingham from you tube "Accelerate your hybrid identity journey with Azure Active Directory"
@Bill Mathers

Answer 1

Hi @K Wahlstrom ,

You can enable the use of ms-ds-consistencyGUID as sourceAnchor during new installation.

You would go through the installation process and select it in the "Configure Source Anchor" section as described in the guide.

If the attribute isn't configured on any object in the directory, Azure AD Connect can use it as
the Source Anchor attribute.

Answer 2

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

1. Remove users from AzureSync scope on old AD domain (causes the user to be cloud deleted).
2. Clear immutable ID (might require cloud restoring the user which converts the user to cloud only)
3. 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.