Forum Discussion
Finalizing migration from Connect Sync to Cloud Sync
Hi Towel,
De-scoping and deleting the connector are no different from the perspective of the connector space object: Both actions trigger a call the the Deprovision() function.
I had a read of the technical part of the article you originally linked and what prevents the object(s) deletion for the pilot is the combined impact of the custom inbound and outbound rules they ask you to create:
• Tutorial - Migrate to Microsoft Entra Cloud Sync for a Synced Active Directory Forest - Microsoft Entra ID | Microsoft Learn
So, their claim of not deleting objects is correct, so long as you do indeed create these rules.
There's also a quick correction to be made for their article. Under "Inbound connector" step 3, you want to use the Active Directory connector, not the Entra connector - as they've written.
With respect to exiting the pilot and resolving the need for getting rid of the Active Directory domain, your best course of action is to perform a swing migration, where after you have imported the original AAD Connect server's configuration but before it runs the full import and sync, you get rid of the to-be-removed domain's connector.Deleting the connector while the connector space is empty means it's not possible for the new AAD Connect instance to project any deletions (since there's nothing to delete and therefore nothing to deprovision).
Cheers,
Lain
Thank you LainRobertson for your detailed response.
If you meet these requirements then at least based on the documentation, AAD Connect will not delete the objects when de-scoped.
The intention is to delete the connector to that AD, not to descope it through the wizard.
I would suspect that AD Connect would act similarly to Cloud Sync - once the configuration (connector) is deleted the objects would be left as is. (https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/reference-cloud-sync-faq#i-m-provisioning-users-using-cloud-sync--i-deleted-the-configuration--why-do-i-still-see-the-old-synced-objects-in-microsoft-entra-id--)
Even if ms-ds-consistencyGUID is populated, it would still not prevent AD Connect from deleting the user. If removed from sync, I understand that all the objects within the removed scope are deleted from Entra ID. Soft-deleted to be precise.
According to what I read, after providing an option to change the Source Anchor from objectGUID to ms-ds-consistencyGUID at one of the earlier versions of AD Connect, the sync process would still look for the objectGUID attribute value if the ms-ds-consistencyGUID for that user is NULL. That value, converted from BINARY to BASE64 is the value of OnPremisesImmutableId in Entra ID. It would behave as Cloud Sync. (https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/reference-cloud-sync-faq#can-i-change-the-source-anchor-for-cloud-sync-)
The hard-match.
Hi Towel,
De-scoping and deleting the connector are no different from the perspective of the connector space object: Both actions trigger a call the the Deprovision() function.
I had a read of the technical part of the article you originally linked and what prevents the object(s) deletion for the pilot is the combined impact of the custom inbound and outbound rules they ask you to create:
• Tutorial - Migrate to Microsoft Entra Cloud Sync for a Synced Active Directory Forest - Microsoft Entra ID | Microsoft Learn
So, their claim of not deleting objects is correct, so long as you do indeed create these rules.
There's also a quick correction to be made for their article. Under "Inbound connector" step 3, you want to use the Active Directory connector, not the Entra connector - as they've written.
With respect to exiting the pilot and resolving the need for getting rid of the Active Directory domain, your best course of action is to perform a swing migration, where after you have imported the original AAD Connect server's configuration but before it runs the full import and sync, you get rid of the to-be-removed domain's connector.Deleting the connector while the connector space is empty means it's not possible for the new AAD Connect instance to project any deletions (since there's nothing to delete and therefore nothing to deprovision).
Cheers,
Lain
LainRobertson wrote:
There's also a quick correction to be made for their article. Under "Inbound connector" step 3, you want to use the Active Directory connector, not the Entra connector - as they've written.
Yes, I noticed that as well.
De-scoping and deleting the connector are no different from the perspective of the connector space object: Both actions trigger a call the the Deprovision() function.
Tested.
Removing the connector to the domain deletes the objects from Entra ID.The new server deployment is the only approach as it seems.