Linking 2 forests so email domain can be used in both

Posted on 2011-09-06
Last Modified: 2012-05-12

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?
Question by:he_who_dares
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
LVL 12

Accepted Solution

Nenadic earned 500 total points
ID: 36488000
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.

Author Comment

ID: 36586351
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.


Featured Post

Is Your AD Toolbox Looking More Like a Toybox?

Managing Active Directory can get complicated.  Often, the native tools for managing AD are just not up to the task.  The largest Active Directory installations in the world have relied on one tool to manage their day-to-day administration tasks: Hyena. Start your trial today.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Find out what you should include to make the best professional email signature for your organization.
Unified and professional email signatures help maintain a consistent company brand image to the outside world. This article shows how to create an email signature in Exchange Server 2010 using a transport rule and how to overcome native limitations …
To show how to generate a certificate request in Exchange 2013. We show this process by using the Exchange Admin Center. Log into Exchange Admin Center.:  First we need to log into the Exchange Admin Center. Navigate to the Servers >> Certificates…
The video tutorial explains the basics of the Exchange server Database Availability groups. The components of this video include: 1. Automatic Failover 2. Failover Clustering 3. Active Manager
Suggested Courses
Course of the Month7 days, 23 hours left to enroll

617 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question