Forum Discussion
AAD Connect is syncing two domains that are federated. Want to stop syncing one
Hi, Ken.
There's a few ways of achieving this, each with its own pros and cons.
Option 1: Delete the unrequired forest
Note: Unselecting the unrequired forest approximates this option but not completely. It's better to remove the unrequired forest than to only unselect it.
Pros
- Easy to action
- Doesn't disturb your remaining forest within AAD Connect
Cons
- Soft-deletes all users within the Azure tenant that originated from the deleted forest
- When those soft-deleted users are restored, their password is not preserved
- Synchronised groups will be lost as they are hard-deleted, not soft-deleted
References
- Customize an installation of Microsoft Entra Connect | Microsoft Learn (note the Remove button)
- Connectors in the Microsoft Entra Connect Sync Service Manager UI' | Microsoft Learn (aka the "ugly" way)
Option 2: Reinstallation and toggling tenant sync enablement
Pros
- Users from the unrequired forest are not deleted meaning no user password impact
- Synchronised groups are not lost
- Cleaner AAD Connect environment (this is subjective, but that's my opinion)
Cons
- Disabling the sync takes 72 hours meaning you cannot move quickly through this process
- You need to be accurate with re-establishing the sync configuration for the remaining forest or else it goes pear-shaped
References
Option 3: Reinstall AAD Connect and using cross-forest matching
This requires planning (and possibly some preparation work on the Active Directory attribute data) - you shouldn't just wing it.
Pros
- Users from the unrequired forest are not deleted meaning no user password impact
- Synchronised groups are not lost
- Cleaner AAD Connect environment (this is subjective, but that's my opinion)
Cons
- Time investment in the planning
- Attribute value conflicts between forests preventing the use of this model at all
References
We don't know anywhere near enough about both your environments to make concrete suggestions, but my personal bias is towards option 3 where possible.
If the unrequired forest is large, I wouldn't personally be looking at option 1 as that's a lot of users to disrupt, but again, that's just my preference.
I deliberately haven't covered the steps of each process. There's a lot of documentation out there already on that front.
Cheers,
Lain
Hi, Ken.
There's a few ways of achieving this, each with its own pros and cons.
Option 1: Delete the unrequired forest
Note: Unselecting the unrequired forest approximates this option but not completely. It's better to remove the unrequired forest than to only unselect it.
Pros
- Easy to action
- Doesn't disturb your remaining forest within AAD Connect
Cons
- Soft-deletes all users within the Azure tenant that originated from the deleted forest
- When those soft-deleted users are restored, their password is not preserved
- Synchronised groups will be lost as they are hard-deleted, not soft-deleted
References
- Customize an installation of Microsoft Entra Connect | Microsoft Learn (note the Remove button)
- Connectors in the Microsoft Entra Connect Sync Service Manager UI' | Microsoft Learn (aka the "ugly" way)
Option 2: Reinstallation and toggling tenant sync enablement
Pros
- Users from the unrequired forest are not deleted meaning no user password impact
- Synchronised groups are not lost
- Cleaner AAD Connect environment (this is subjective, but that's my opinion)
Cons
- Disabling the sync takes 72 hours meaning you cannot move quickly through this process
- You need to be accurate with re-establishing the sync configuration for the remaining forest or else it goes pear-shaped
References
Option 3: Reinstall AAD Connect and using cross-forest matching
This requires planning (and possibly some preparation work on the Active Directory attribute data) - you shouldn't just wing it.
Pros
- Users from the unrequired forest are not deleted meaning no user password impact
- Synchronised groups are not lost
- Cleaner AAD Connect environment (this is subjective, but that's my opinion)
Cons
- Time investment in the planning
- Attribute value conflicts between forests preventing the use of this model at all
References
We don't know anywhere near enough about both your environments to make concrete suggestions, but my personal bias is towards option 3 where possible.
If the unrequired forest is large, I wouldn't personally be looking at option 1 as that's a lot of users to disrupt, but again, that's just my preference.
I deliberately haven't covered the steps of each process. There's a lot of documentation out there already on that front.
Cheers,
Lain
