Linking 2 forests so email domain can be used in both


To give a top level overview of what we're trying to achieve.

Company1 is merging with Company2.

Both company's use Exchange 2003 and hosted services for filtering e.g Mimecast.

There will be a new email domain setup that we need users in both firms to be use as their primary smtp address.

Company1 will be using Mimecast to accept inbound/outbound mail and company2 will be getting rid of their hosted filtering solution.

First of all we want to put in new MX records for to point to Company1 mimecast service so it can accept mail.

The mail will then be routed to Company1 Exchange organisation and from there to Company2's Exchange organisation.

Now at the moment there are no trusts in place but this will be done in the near future.

Also looking at Quest's collaboration services to do GAL/freebusy sync across the 2 Exchange organisations in the 2 forests.

Just looking for advice on the best way to go about getting this all in place.

Is it even possible to do this across 2 Exchange organisations sitting in 2 separate forests?
Who is Participating?
NenadicConnect With a Mentor Commented:
To answer the last question - absolutely. It is a very common scenario in mergers, migrations, consolidations etc. There are a number of ways to achieve this. I will try to be as generic as possible, though, to explain concepts that can then be modified to your specific situation.

To more detail, then... There are three basic requirements to this coexistence:
A) Address Book lookups, so that users in one Exchange Organization can find users in the other to send them email or book meetings with them.
B) Flow of email from one side to the other.
C) Free/busy lookups for scheduling.

To resolve all four of those you need the following:
1. Each company already has a Global Address Book comprising users with mailboxes, distribution lists and any contacts you may have.
2. Each company should have Contacts for users and DLs in the other company (this achieves requirement A)
3. Contacts should have details of where email for them should be sent (this achieves part of requirement B, but begs more explanation later on)
4. Each company should have transport rules (Connectors) that determine that all mail set to destinations described above should go to Exchange Servers of the other side. (much like you have Internet connectors pointing to Mimecast probably). (this completes the requirement B)
5. A mechanism for looking up Free/Busy Public Folders on the other company's PF servers (this achieves requirement C).

If you intend to use Quest, the process to accomplish above is relatively straightforward as these are addressed by the application. But, some of the items you still need to determine are listed below:

You have to have separate namespaces for each company to ensure that you have no routing loops. You could leverage existing company addresses for this. Basically, you would add the domain space as default to both sides, but maintain email addresses of old companies. You then create a Connector on each side where on Company A side it says that all email with addresses should go to Company B servers and vice versa.

Once you have above on both sides, you need to populate each side with details of recipients from the other. So User A in Company A becomes Contact A in Company B. In Company A, User A would have the following:
- Reply to address:
- SMTP address:
In Company B, Contact A would have the following:
- Email address:
- Proxy address:
This would allow Company B to consider User A a valid recipient, but it would also enable it to know to deliver messages for User A to Company A's Exchange Servers (based on the Connector you created earlier).
This would be done on both sides.

Finally, Quest, or another application (Binary Tree, GALSync+IORepl etc) will cover the calendar scheduling after trusts, connectors and GAL update have been performed.
he_who_daresAuthor Commented:
Hi sorry for the late reply on this.

I am looking into the shared namespace part at the moment.

Im thinking along these lines:

1) Setup an additional recipient policy and put the shared namespace ( in this and set to non-authoritive for that address.
2) that way i think it should lookup in AD for the and if they are in our Exchange envirnoment then it gets delivered.
3) if the user doesnt have a mailbox in our environment then our Exchange will look for an SMTP connector to route mail for
4) that connector could contain the Exchange server in the other company and forward to them.
5) they could do the same setup their end.
6) this way mail should route between the 2 exchange organisations.

For the recipient policy i put in i would eventually want to apply to all users, but i have the "Default Policy" set to mailnickname=* at the mo.

Will it be a problem to set the new recipient policy to mailnickname=* as well but set it higher priority so it gets applied after the Default policy?

My problem with just changing the primary smtp in "Default Policy" to the is that you cant set it as  non-authoritive.

Does that seem ok?

This part might have to be handled in separate post

On top of that, i had actually implemented Exchange 2010 which nobody has migrated to yet.

However, i converted the address policies and address lists to convert them from LDAP to OPATH filters, which means that 2003 doesn't have control of policies now, thats gone to the 2010 hub role.

I dont know if this is going to cause a problem now adding or amending policies and wonder whether its best to try and reverse that so 2003 does have control again as we are now looking to decommission 2010 and rebuilt it in the other companies domain as we are looking to do a cross-forest migration with all users here going to their domain and decommissioning ours.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.