Forum Discussion
Finalizing migration from Connect Sync to Cloud Sync
Hello,
The Connect Sync server synchronizes multiple domains to the same tenant.
We have followed the migration approach outlined in the article, for one of the domains:
https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/tutorial-pilot-aadc-aadccp
How best to remove that domain configuration from the Connect Sync without potentially impacting hybrid objects?
Is it just as simple as removing the domain through the Connect Sync wizard?
It looks like I do not have an option to disable that domain's sync configuration temporarily.
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
7 Replies
Deleting the AD connector - deletes the objects synchronized by it from Entra ID.
Deleting the AD connector, and connector space only for the Entra ID connector does not delete the synced objects.
These objects can be added to Cloud Sync.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.
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
Just so I understand, you have multiple on-premises domains configured to sync into Entra ID from within the same Entra Connect Sync instance, and want to only stop sync for one of the domains via Connect Sync because you've moved that one domain to Cloud Sync?
If that is correct, removing that one domain from Connect Sync would impact all synced objects and mark them as deleted.
I would complete transition to Cloud Sync and then decom the Connect Sync by configuring staging mode, then uninstall from server and lastly remove from Entra ID (health monitoring).
