ADDS trusted A. OnPrem EX2013 B.Office 365 into new ADDS and New 0365 Tenant?'s%20(each%20with%20their%20own%20forest%20and%20single%20domain)%20that%20have%20operated%20in%20a%20trusted%20ADDS%20forest%20configuration.%20Each%20forest%20contains%20their%20own%20respective%20mail%20system.%20One%20has%20on-premise%20Exchange%202013.%20The%20other%20ADDS%20forest%20has%20O365%20and%20uses%20Azure%20AD%20Connect%20to%20sync%20on-premise%20ADDS%20users%20to%20o365.%20These%20mail%20systems%20are%20utilizing%20Galsync%20(enow)%20to%20support%20cross%20forest%20GAL's.%3CBR%20%2F%3EWe%20are%20not%20(yet)%20using%20o365%20SharePoint%2C%20one%20drive%2C%20or%20other%200365%20services%20other%20than%20email.%20*We%20will%20later%20in%20the%20new%20named%20entity.%3CBR%20%2F%3EWe%20are%20now%20going%20to%20merge%20these%20two%20environments%20(ADDS%20forest(s)%20%2F%20domain(s))%20into%20a%20new%20named%20ADDS%20entity%20(forest%20and%20domain)%20-%20and%20new%20o365%20tenant.%20This%20new%20named%20entity%20will%20utilize%20many%20of%20the%20o365%20offerings.%3CBR%20%2F%3EI%20have%20migrated%2Fmerged%20trusted%20forests%2C%20and%20Exchange%20on-premise%202010%2F2013%20systems%20together%20via%20ADMT%20and%20mailbox%20moves.%20This%20looks%20to%20be%20a%20bit%20more%20challenging.%3CBR%20%2F%3EHas%20anyone%20performed%20a%20similar%20migration%2Fmerge%3F%20Would%20they%20be%20will't%20believe%20we%20could%20rename%20the%20existing%20tenant%20-%20correct%3F%3C%2FP%3E%3CP%3EWe%20will%20migrate%20both%20into%20a%20new%20forest%20-%20yes.%26nbsp%3B%'t%20be%20renamed%20as%20of%20now.%20Okay%2C%20there%20a%20few%20ways%20to%20achieve%20the%20target%20state%2C%20In%20my%20opinion%20the%20simplest%20one%20would%20be%20using%20a%20third%20party%20migration%20tool%20like%20Bittitan%20etc.%20Lets%20say%20your%20forest%20setup%20is%20A-F-B%20where%20A%20is%20forest%20with%20exchange%202013%2C%20B%20is%20forest%20with%20office%20355%20and%20F%20is%20the%20final%20forest.%20The%20high%20level%20approach%20incase%20of%20'third%20party'%20migration%20tool%20would%20be%3A%3CBR%20%2F%3E1.%20Install%20Aadconnect%20in%20forest%20F%20with%20new%20tenant.%20FILTER%20OUT%20masexchmailboxguid%20from%20synchronization.%20Add%20the%20new%20domain%20in%20new%20tenant.%3CBR%20%2F%3E2.%20Migrate(copy)'t%20want%20to%20sync%20mailbox%20guid%20from%20on-premises.%3CBR%20%2F%3EThis%20is%20just%20a%20high%20level%20overview%20to%20get%20you%20started%2C%20a%20lot%20more%20can%20go%20into%20this%20discussion%20to%20fill%20out%20any%20gaps.%3C%2FLINGO-BODY%3E
Occasional Contributor

We have two company's (each with their own forest and single domain) that have operated in a trusted ADDS forest configuration. Each forest contains their own respective mail system. One has on-premise Exchange 2013. The other ADDS forest has O365 and uses Azure AD Connect to sync on-premise ADDS users to o365. These mail systems are utilizing Galsync (enow) to support cross forest GAL's.
We are not (yet) using o365 SharePoint, one drive, or other 0365 services other than email. *We will later in the new named entity.
We are now going to merge these two environments (ADDS forest(s) / domain(s)) into a new named ADDS entity (forest and domain) - and new o365 tenant. This new named entity will utilize many of the o365 offerings.
I have migrated/merged trusted forests, and Exchange on-premise 2010/2013 systems together via ADMT and mailbox moves. This looks to be a bit more challenging.
Has anyone performed a similar migration/merge? Would they be willing to share how they did it?
Any insight, links, or thoughts are very much appreciated.
I found something similar in a forum on reddit -
Thanks in advance,

7 Replies

Hey @Kevin Watkins ,

Couple of questions here, Are you planning to keep on-premises exchange post merger ? or is it just going to be office 365 with objects being synchronized from on-premises active directory with AADConnect ? are there plans to consolidate on-premises active directory as well ( like AD user migration from one on-premises active directory to another) ? AADconnect does support synchronizing objects from two different on-premises active directories via single AADconnect server ( There are a few prerequisites though). 

Howdy @harveer singh Thank you for the response. To answer your questions: 1) We do NOT plan to keep any on-premise exchange post merger. 2) It will be office 365 with objects being synchronized from on-premises active directory with AADConnect. 3) YES - The plan is to consolidate on-premises (both forests) active directory as well ( like AD user migration from one on-premises active directory to another) Would you please tell me more re: AADconnect does support synchronizing objects from two different on-premises active directories via single AADconnect server ( There are a few prerequisites though). Thanks again for your help :)

Hey @Kevin Watkins ,


Here is an article which explains about adding an additional directory in AADConnect :

There are other links in the article talking about prerequisites like Trust between the forests, conditional forwarder etc. You can achieve the configuration without trust as well, the article is a bit old (and has a few ads now agggh) but still works well. Will drop response to your other query in some time a bit occupied right now.



Hey @Kevin Watkins ,


Sorry to keep you waiting, a few more question for you, are you planning to migrate both the ADs ( one with exchange 2013 and the other with Dirsync) to a new forest all together, or are you simply merging the two forests ? Going with merge would certainly remove quite some complexity and would make the plan a bit simpler.  Also is it a compliance requirement to move away from the office 365 tenant you already have? If you can stick to the same tenant and simply add the new domain in the same tenant , it would again ease your work and you wont have to perform a tenant to tenant mailbox migration ( I am assuming you have mailboxes in office 365 for the other forest). 


Hello @harveer singh 

I don't believe we could rename the existing tenant - correct?

We will migrate both into a new forest - yes.  It will be a new company name.  We need a new tenant name to follow the name for the new company. 







Yup, a tenant can't be renamed as of now. Okay, there a few ways to achieve the target state, In my opinion the simplest one would be using a third party migration tool like Bittitan etc. Lets say your forest setup is A-F-B where A is forest with exchange 2013, B is forest with office 355 and F is the final forest. The high level approach incase of 'third party' migration tool would be:
1. Install Aadconnect in forest F with new tenant. FILTER OUT masexchmailboxguid from synchronization. Add the new domain in new tenant.
2. Migrate(copy) users on-premises from Forest A and B to new forest F using ADMT/other, preserve the object guid but project the users with new upn in the target forest F.
3. Now once you have users in Forest F, sync them to office 365 without mailbox guid, next when you assign a license in office 365, mailbox would be provisioned and office 365 mailboxes will be ready for data to be imported.
4. Now use third party tool to pull data directly into mailboxes from exchange and office 365 forest. Using a third party tool would allow you to do an incremental migration as well, so the users in exchange and old office 365 remain in production to the very last day, incase the migration runs for a few weeks. Lastly you will have to remove the old domain from old tenant and add it into the new tenant.
As i said this is one of the methods to achieve this, I suggest using a third party tool as one of your sources is office 365 and for migrating out of office 365 thirdy party tools serve better.

If you want to take the hybrid route there is added complexity, approach from forest B with office 365 remains the same as above, things would change for exchange forest though, high level overview:
Install Aadconnect in forest F, add forest A as remote directory(article previously shared), once users are synced, setup hybrid, move all mailboxes to office 365, decom exchange on-premises, move users from forest A to destination forest deleting source, so that Aadconnect sees only one instance of user object. Please note that with this approach you will also have to manage mailbox guids for two forests seperately, as exchangemailbox guid must be synced to office 365 for hybrid migration, but for office 365 to office 365 migration you don't want to sync mailbox guid from on-premises.
This is just a high level overview to get you started, a lot more can go into this discussion to fill out any gaps.