Forum Discussion
Migrate AD User and AADConnect to new Forest (Same O365 tenant)
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-forest-to-another-forest/
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?
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
- 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.
