SOLVED

How to merge 2 Exchange 2016 organizations

Copper Contributor

Hello,

The info I've found so far on this topic is confusing to me.

Here's the scenario:

Company A is an Exchange 2016 organization

Company B is also and Exchange 2016 organization

 

Company A has purchased Company B.

We would now like to manage Company B's Exchange organization from Company A's EAC and have all mail flow through Company A's receive connectors.

 

Our first step was to establish a forest trust between the AD's of both companies. That's been 
done successfully.

 

Then as an interim step, for security reasons, we configured Send connectors for all respective email domains to traverse the site to site VPN between the company networks. Currently MX records and accepted domains 
are still separate for each Company. 

 

Can anyone offer the high level (or detailed) steps to now have Company B's Exchange organization 
managed by Company A via Company A's EAC?

 

End state would be the same MX record for all accepted domains but still have Company B's server (Company B is a single EX 2016 STD server) stay where it is and to be manageable from within Company A's EAC.

 

I searched a bit looking for steps to move the Mailbox DB, Public Folders, etc to the other organization but both of those steps look like one way tasks that due to the size of the MB DB would take too long and would force us to physically move lots of data. 

 

Thanks in advance

Ed

 

 

 

 

6 Replies

Are you aware of possibilities to manage two Exchange organizations from single EAC? I do not know such a possibilities. And I'm assuming your both organizations are on-premises only, and no hybrid setups at all?

 

So before giving any better deeper answers, it might help if you share a bit your thoughts about the goal? Do you expect to keep these organizations always separated or are you planning to merge them? I'm asking this, as your latest comment confuses me a bit. If you do merge you need to move all (relevant) mailbox data before you can remove the other organization. When you mentioned about your worries with amount of data move, there is possibility to move mailbox with parameter -CompleteAfter. That can be used to move mailboxes almost completed. It is kind of replicate mailbox to other site wiht available bandwidth. And then, when you and user is ready, finalize the move.

You can't merge those organizations; mailboxes and other configuration objects reside in one organization, and are managed from that organization. To integrate functionality, you need to establish mailflow but things like organization relationships as well regarding free/busy etc. It would help if you state if merging is a goal or not. Meanwhile, since both are on-prem and there is a trust, you can grant admins of orgA administrative permissions on orgB to manage its configuration.

@Michel de Rooij 

 

Merging is the ultimate goal, but we are trying to avoid a hard cut. It would be 
disruptive and time consuming so we'd like to move mailboxes over one at a time
while still maintaining mail flow.

The problem that I see right now is Company B's MX record will need to point to Company A's receive connector. When we do that, and we start moving mailboxes between servers, how do we route mail to the correct mailboxes for users in the Company B email domain?

 

if we migrate mailboxes one at a time, the email domain for Company B would need to exist in both organizations. How would mail get routed to the proper mailbox/server  in that case?


 

 

 

best response confirmed by epgalli (Copper Contributor)
Solution
So, compB's MX points to compA's organization; configure compB as an internal relay domain in compA, en configure a send connector for the respective domains pointing to compB's endpoints. If you have mail-users post-migration in compB (eg mailboxes moved from compB to compA), make sure you set targetAddress to a domain uniquely defined in compA (eg. when rebranding set to compA address). This, to prevent you having 2 locations with disjoint populations requiring internal relay for that domain pointing to each other (with bouncing NDRs). Alternativelt, introduce a mail routing domain - similar to Office 365 - such as mail.compb.com, which is an accepted domain in compA, internal relay in compB and set targetAddress in compB to those entries.

@epgalli 

Have you read these:

- Moving Mailboxes Between Exchange Organizations

- Easy cross-forest migrations on Exchange Server

- Prepare mailboxes for cross-forest move requests

 

Keep in mind, if you have Skype in use both sites, then that makes this a bit harder as Skype does not support cross-forest migration.

Thanks for all the feedback guys.

 

I think we have enough to get started on this one

 

 

1 best response

Accepted Solutions
best response confirmed by epgalli (Copper Contributor)
Solution
So, compB's MX points to compA's organization; configure compB as an internal relay domain in compA, en configure a send connector for the respective domains pointing to compB's endpoints. If you have mail-users post-migration in compB (eg mailboxes moved from compB to compA), make sure you set targetAddress to a domain uniquely defined in compA (eg. when rebranding set to compA address). This, to prevent you having 2 locations with disjoint populations requiring internal relay for that domain pointing to each other (with bouncing NDRs). Alternativelt, introduce a mail routing domain - similar to Office 365 - such as mail.compb.com, which is an accepted domain in compA, internal relay in compB and set targetAddress in compB to those entries.

View solution in original post