Forum Discussion
ADCONNECT - Migration between domains with a single Tenant
Hello everyone, guys I have the following scenario.
Domain A with Adconnect synchronizing users with Tenant.
The need came to migrate users to a new B domain. This new domain has already been installed Adconnect and is also synchronized with that same Tenant.
A trust was performed between domain A and B.
Steps I'm following:
Migro the user using domain A ADMT to B.
In domain A, I put this user not to be synchronized, so the user is moved to users deleted from Office 365 and restore this account. From that moment this account is an account without synchronization.
In the new domain, I get the newly migrated user's objectguid and “apply” the cloud user who reconnected before. At this point this user becomes a synchronized domain B user with the sequence below:
ldifde -d "CN=Teste1,OU=teste,DC=domain,DC=local" -f c:\temp\teste1.txt
result: XdLa+SSiBku4aUYcbeyXyz==
Set-MsolUser –UserPrincipalName email address removed for privacy reasons -ImmutableId " XdLa+SSiBku4aUYcbeyXyz=="
So far all perfect. However, I need to keep the user (which has already been migrated) from the domain to the same until the migration of all AD objects is completed.
It turns out that when ADCONNECT SYNC runs in domain A, even though this user is in one or not to synchronize he performs a delete on the Office 365 account.
I know I would solve this situation excluding the migrated user from the domain A.
Has anyone been through this situation? Is there a way for ADONNECT to make a by-pass by or or group?
Hi, Dinto.
I'm unclear on your AAD Connect configuration, but what you've described reads as though you have AAD Connect installed and synchronising in both domains as shown below:
If my interpretation of what you've said is incorrect and you only have a single AAD Connect instance synchronising to your Azure AD tenant, stop reading as none of what follows will apply to you. (It also means I'm not sure what the issue you're trying to solve is.)
If my interpretation is correct though, then your current configuration is not a supported topology for AAD Connect:
Instead, you should have a single AAD Connect installation that is connected to both Domain A and Domain B, and then manages the synchronisation to your Azure tenant.
Note: You can install two or more AAD Connect instances, however, only one can be performing synchronisations. Any extras must remain in staging mode only.
It sounds like your original installation was performed using the express defaults and therefore uses the objectGUID as the anchor. Obviously, what you're doing now to work around this choice is fiddling with the Azure AD immutableId to get the migrated account aligned..
This isn't a good, scalable approach.
We don't have enough detail on your ADMT-based migration, but if we can assume for a moment that a unique attribute from Domain A is being preserved on the Domain B account, then what you should be doing is uninstalling and then re-installing AAD Connect (one approach), where during the new installation you should be choosing that specific attribute on the screen below:
As described here:
For example, if the sAMAccountName is the same for a user both in Domain A and Domain B, then you could elect to specify sAMAccountName as the "match using" attribute in the screen above.
Note: I'm not saying you should use sAMAccountName. I'm just using it as a very basic example. You are free to pick any attribute that is common across both domains, so long as its value is truly unique within the originating domain (naturally, it's deliberately not going to be unique across domains).
It doesn't matter if the "new" AAD Connect installation is done in Domain A or Domain B, so long as you stick to the supported scenario of having only a single AAD Connect server synchronising to Azure AD.
Here's a diagram of what it should look like using Domain A as the synchronisation point (I can appreciate you might prefer to use Domain B if the longer-term plan is to decommission Domain A):
Continuing to use the example joining attribute of sAMAccountName, what happens now is that:
- The "original" user from Domain A is synchronised into AAD Connect;
- The migrated "copy" of that same original user is synchronised in from Domain B;
- Instead of creating a new "user" (technically, a metaverse entry but we'll call it a user) in AAD Connect for the Domain B user, the Domain B user is joined to the already-existing Domain A user, meaning there's just the single user being synchronised between AAD Connect and Azure AD.
Alternative to re-installing AAD Connect over the existing installation
You might not want to touch your existing installation, which is fair enough.
Instead, you can install a new installation - let's say in Domain B (again, this is all for you to decide), however, you'd then need to switch the original AAD Connect installation in Domain A into staging mode so that you are running a supported configuration.
A high level process for achieving this might look like:
- Install a new AAD Connect instance into Domain B but leave it in staging mode;
- Make sure during installation you selected an attribute common to both Domain A and Domain B to match on (as described above);
- Let the new Domain B AAD Connect installation run its full imports and syncs, then search for some already-migrated users within the Metaverse Search page of the Synchronization Service application and check that it contains at least three connectors:
- One pointing to Domain A;
- One pointing to Domain B;
- One pointing to the Azure tenant;
- If you have configured everything correctly and see these three connectors for your sample users, you can progress to the next point. If you do not see the three connectors you should stop here and figure out which configuration item is not set up correctly;
- Switch the original AAD Connect installation in Domain A into staging mode;
- Switch the new AAD Connect installation in Domain B out of staging mode, which simply means it will take over syncing to and from your Azure tenant.
Again, this is only a high-level overview of one alternative approach.
What does doing any of this achieve?
It means you:
- Are running a supported configuration;
- Do not have to perform any weird manual/scripted transformation of attributes, either in Active Directory or Azure Active Directory (such as for immutableId), which means you:
- Have established a sustainable, scalable, hands-off configuration.
Cheers,
Lain
2 Replies
Hi, Dinto.
I'm unclear on your AAD Connect configuration, but what you've described reads as though you have AAD Connect installed and synchronising in both domains as shown below:
If my interpretation of what you've said is incorrect and you only have a single AAD Connect instance synchronising to your Azure AD tenant, stop reading as none of what follows will apply to you. (It also means I'm not sure what the issue you're trying to solve is.)
If my interpretation is correct though, then your current configuration is not a supported topology for AAD Connect:
Instead, you should have a single AAD Connect installation that is connected to both Domain A and Domain B, and then manages the synchronisation to your Azure tenant.
Note: You can install two or more AAD Connect instances, however, only one can be performing synchronisations. Any extras must remain in staging mode only.
It sounds like your original installation was performed using the express defaults and therefore uses the objectGUID as the anchor. Obviously, what you're doing now to work around this choice is fiddling with the Azure AD immutableId to get the migrated account aligned..
This isn't a good, scalable approach.
We don't have enough detail on your ADMT-based migration, but if we can assume for a moment that a unique attribute from Domain A is being preserved on the Domain B account, then what you should be doing is uninstalling and then re-installing AAD Connect (one approach), where during the new installation you should be choosing that specific attribute on the screen below:
As described here:
For example, if the sAMAccountName is the same for a user both in Domain A and Domain B, then you could elect to specify sAMAccountName as the "match using" attribute in the screen above.
Note: I'm not saying you should use sAMAccountName. I'm just using it as a very basic example. You are free to pick any attribute that is common across both domains, so long as its value is truly unique within the originating domain (naturally, it's deliberately not going to be unique across domains).
It doesn't matter if the "new" AAD Connect installation is done in Domain A or Domain B, so long as you stick to the supported scenario of having only a single AAD Connect server synchronising to Azure AD.
Here's a diagram of what it should look like using Domain A as the synchronisation point (I can appreciate you might prefer to use Domain B if the longer-term plan is to decommission Domain A):
Continuing to use the example joining attribute of sAMAccountName, what happens now is that:
- The "original" user from Domain A is synchronised into AAD Connect;
- The migrated "copy" of that same original user is synchronised in from Domain B;
- Instead of creating a new "user" (technically, a metaverse entry but we'll call it a user) in AAD Connect for the Domain B user, the Domain B user is joined to the already-existing Domain A user, meaning there's just the single user being synchronised between AAD Connect and Azure AD.
Alternative to re-installing AAD Connect over the existing installation
You might not want to touch your existing installation, which is fair enough.
Instead, you can install a new installation - let's say in Domain B (again, this is all for you to decide), however, you'd then need to switch the original AAD Connect installation in Domain A into staging mode so that you are running a supported configuration.
A high level process for achieving this might look like:
- Install a new AAD Connect instance into Domain B but leave it in staging mode;
- Make sure during installation you selected an attribute common to both Domain A and Domain B to match on (as described above);
- Let the new Domain B AAD Connect installation run its full imports and syncs, then search for some already-migrated users within the Metaverse Search page of the Synchronization Service application and check that it contains at least three connectors:
- One pointing to Domain A;
- One pointing to Domain B;
- One pointing to the Azure tenant;
- If you have configured everything correctly and see these three connectors for your sample users, you can progress to the next point. If you do not see the three connectors you should stop here and figure out which configuration item is not set up correctly;
- Switch the original AAD Connect installation in Domain A into staging mode;
- Switch the new AAD Connect installation in Domain B out of staging mode, which simply means it will take over syncing to and from your Azure tenant.
Again, this is only a high-level overview of one alternative approach.
What does doing any of this achieve?
It means you:
- Are running a supported configuration;
- Do not have to perform any weird manual/scripted transformation of attributes, either in Active Directory or Azure Active Directory (such as for immutableId), which means you:
- Have established a sustainable, scalable, hands-off configuration.
Cheers,
Lain
- LainRobertson
Thanks for the answer!
