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
Your summary is precisely right. I have multiple AD domains, across a couple of forests synchronizing to a single Entra ID tenant.
I did realize, after posting the question, that following the wizard and removing the domain, will mark objects as deleted, but decided to leave the question as is, as was hoping to get a "correction" to the approach expressed there.
I cannot decommission or in any other way impact the functionality of the Connect Sync server, as it is used for syncing other AD Domains.
After some research and discussion of the issue with two Microsoft support engineers (they did not seem to be familiar with such a situation), it looks like the most appropriate approach is to DELETE the connector to the AD domain through "Synchronization Service Manager" MMC. In essence, breaking the connectivity from the Connect Sync server to the AD Domain, which was moved to synchronize through Cloud Sync.
The objects that were previously synchronized by the Connect Sync server now would be synchronized using Cloud Sync.
The issue with this approach is that Microsoft indicates that DELETE action, should NOT be used.
https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sync-service-manager-ui-connectors
(see Connector Actions table)
Hi Towel,
I'll preface what I'm about to point out by saying that I haven't moved off AAD Connect to Cloud Connect yet as there's things the former can do that the latter cannot. This means I'm working solely off the Microsoft documentation you linked in your first post.
In that documentation, it does state that when using a very specific configuration, the Azure AD objects will not be deleted.
As Chris and yourself have already noted, under normal circumstances, de-scoping results in those objects being deleted from Azure AD. But if you meet the following (from the article), this deletion will not occur:
So, your first port of call is to ensure you meet all of these requirements (paying particular attention to the population of ms-ds-consistencyGUID).
If you meet these requirements then at least based on the documentation, AAD Connect will not delete the objects when de-scoped.
However, it has to be emphasized that this documentation is aimed at a test environment, which doesn't inspire me.
I'd consider creating a test user in your Active Directory that is then synchronised by AAD Connect to Azure before using group filtering (also mentioned in that article) to target just that one single user for cutting over to Cloud Sync.
Cheers,
Lain