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
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.