Migrate AD User and AADConnect to new Forest (Same O365 tenant)

Copper Contributor

Hi guys, 

 

Over the last few weeks i've been reading a lot around Tenant-to-tenant migration, and we've been playing around with the new features and it's been pretty cool. 

However, I have a question around migrating AD User Objects and standing up a new AADConnect server in a new environment but still syncing into the same Azure AD & O365 tenant.

 

So in summary:

 

Current Set up:

* On-Premise Active Directory (AD users) in Forest A

* All users are synced via AAD Connect server in Forest A

* Hybrid with Exchange 2016 in Forest B (two-way trust with Forest A) 

* All mailboxes are migrated to Exchange Online

 

Target Set up:

Due to Business reasons (change in datacentre/supplier), we want to continue to use the existing O365 Tenant and Azure subscription, but need to migrate AD Objects (Source of Authority) and stand up a new AAD Connect server to sync the AD objects to the migrated mailboxes in the environment. 

 

So the Target environment would look like this:

 

* All AD Users (source of authority) are in Forest C (We will set up a Two-Way trust with Forest A)

* The AADConnect server to sync all objects to the O365 tenant will also need to be stood up in Forest C

* The EXO mailboxes in O365 should not be impacted.

 

AFAIK, there is limited documentation around this online, but if anyone has any experience around this, have used any articles, or can think of any gotchas, would be good to get your views.

I've done something similar with a few previous customers so have a high-level idea but would be good to see if anyone has done this - I know it will require an AD Migration cross-forest (maybe ADMT/3rd party like Quest) and I guess the UPN's will change for the users, but more around planning (coexistence/phased vs. cutover). etc.

 

Thanks

Ron 

 

7 Replies

anybody for anything? :)

1. "Move/Migrate user object from Forest A to Forest C and change UPN from a.local to c.local" - The potential issue that I see is duplicate Object IDs. I would suggest that you create a LAB as mentioned in below article which I feel is exact to what you posted and need to do.
You can use the office 365 E3 or E5 trail subscription for that.
https://anderseideblog.wordpress.com/2014/02/12/lab-migrate-office-365-synced-users-from-one-on-prem...

Once you are sure that you were successful in LAB scenario you can start your migration, since you will have hands on and will not be hovering here and there for help.

2. "The AADConnect server to sync all objects to the O365 tenant will also need to be stood up in Forest C " - You can install Azure AD Connect server in forest C in staging mode(non production) and Disable and remove dirsync from Forest A then “Reset” dirsync in Office 365 once the ADMT is done and all user objects are migrated successfully to Forest C. Look at the last section of the above article and you will understand automatically.



@saifs19802210  Hi Saifs, 

Thank you so much for your response.

So instead of using ADMT, we have created brand new users in Forest C. So at the moment, they are ForestA.Local UPNs. But these are not being synced YET.

In our New AADConnect in Forest C, we have added the Forest A users into the scope to be synced. At the moment, new AADconnect server is in Staging mode.

 

So the plan is: 

1. Add the users from Forest A OU's into Scope onto my new Forest C AADConnect in Staging Mode

2. Make the staging mode server in Forest C as Primary Server. Hopefully no change to users at this stage

3. Add a test number of users to Sync from Forest C. This should mean they are synced but not matching the cloud users YET. 

4. So I need to then manually change the UPN of the Forest A users from username@externaldomain.com to  username@tenantname.onmicrosoft.com and then change the Forest C synced users' UPN to username@externaldomain.com - If that doesn't work automatically, I will need to manually hardmatch the Forest C user to the cloud user by setting the Immutable ID

 

 

That should work hopefully.

My only concern is if Azure doesn't like the same custom domain name (Externaldomain.com) coming from 2 Forests - i don't think that should be an issue?

 

I only to say for point 2. Make the staging mode server in Forest C as Primary Server. Hopefully no change to users at this stage.

At this stage if you could only select a test OU to sync with custom domain (Externaldomain.com). Better you create one first in Forest A and sync to O365 and also assign a license to it. Just to show that this is a working user in our tenant.

Then when you are planning for switchover, just play with this user and turn off Azure AD Connect from O365 portal, move this user using ADMT to Forest C in Forest C syncing OU

Turn on the Azure AD Connect in Forest C and only sync test OU where this user is moved to. Finally start the sync and login into O365 portal to see the behavior.

Also for another point: 4. The only thing which comes in to my mind is duplication of accounts. But I suggest that is why bring the test user as I said above in scope of Forest C and create same new account of test user in forest C and then change UPN.

I mean playing with a test user will only help hear OR a LAB which I posted earlier since there are very less people in MS who might have done it hence I suggest play with test users for now and don't jump right in.

@LIT-RS - I'm not sure the matching will work as each sync'd user account from Forest A will have an immutable ID on the Azure side.

 

You'll need to clear that for each user in Azure before it'll connect to another on prem sync'd account.

@steve_elliott  Hi Steve,

Agreed - So plan is: Set-msoluser -UserPrincipalName user1@customdomain.com -ImmutableID "$null"

 

^ this will be performed on the user that is synced from Forest A. This will then make it "cloud only".

 

Immediately after that:

Set-msoluser -UserPrincipalName user1@customdomain.com -ImmutableID "%immutableID of the Forest C user's ObjectGuid converted"

 

^ this will then force (hard match) the cloud account to the Forest C AD user. 

 

Is that would you meant?  

@LIT-RS  - Yep. You just need to clear the immutable ID for the user.

 

Then when you bring Forest C sync online (assuming it's going to be the same UPN) - matching will  happen automatically.

 

If you are keeping the same UPN's the approach I've personally take would be something like :

 

Forest A - Disable AD Connect tenant wide using powershell - All accounts will convert to cloud only

Disconnect / Uninstall AD Connect on Forest A

Run MSOL command against all users in tenant, again using PS

Bring AD Connect online in Forest C

Sync - UPN's will match up and sync