If you would like to read the other parts in this article series please go to:
- Deep dive into rich coexistence between Exchange Forests (Part 1)
- Deep dive into rich coexistence between Exchange Forests (Part 3)
- Deep dive into rich coexistence between Exchange Forests (Part 4)
- Deep dive into rich coexistence between Exchange Forests (Part 5)
- Deep dive into rich coexistence between Exchange Forests (Part 6)
- Deep dive into rich coexistence between Exchange Forests (Part 7)
- Deep dive into rich coexistence between Exchange Forests (Part 8)
- Deep dive into rich coexistence between Exchange Forests (Part 9)
- Deep dive into rich coexistence between Exchange Forests (Part 10)
- Deep dive into rich coexistence between Exchange Forests (Part 11)
- Deep dive into rich coexistence between Exchange Forests (Part 12)
- Deep dive into rich coexistence between Exchange Forests (Part 13)
- Deep dive into rich coexistence between Exchange Forests (Part 14)
- Deep dive into rich coexistence between Exchange Forests (Part 15)
Introduction
In part 1, we had a look at the lab environment that lay the ground for this articles series. I showed you a conceptual diagram of the Exchange forests and explained the basic configuration of each forest and the servers within it. In part 1, we also enabled DNS name resolution between the forests, which is a vital step when it comes to multi-forest coexistence.
In this part 2 of this articles series, we will continue where we left off in part 1. We will first establish trust relationships between each forest and then configure cross-forest connectors in order to get mail flow working.
Establishing Trust Relationships between Forests
As mentioned, we need to establish trust relationship between the 3 Exchange forests. A trust relationship is recommended when it comes to cross-forest availability as it allows users to retrieve free/busy information on a per user basis. In addition, a forest trust relationship is a requirement if you plan on sharing calendars cross-forest.
To establish a trust relationship from Exchange forest 1 (Exchange 2010 forest), we need to logon to the Domain Controller and launch the Active Directory Domains and Trusts (ADDT) console from the Administrative tools folder.
Note:
You can also establish the trust using the native Netdom tool. For more information see this topic on Microsoft TechNet.
In the ADDT console, right-click on the forest name (in this example e2k10forest.dk) and then select “Properties” in the context menu as shown in Figure 1.
Figure 1: Opening the property page for the Exchange 2010 forest domain
On the property page, click the “Trusts” tab and then “New Trust”.
Figure 2: Property page for the Exchange 2010 Forest Domain
On the welcome page, click “Next”.
Figure 3: New Trust Relationship wizard – Welcome page
Now enter the name of the forest with which you want to establish a trust. In this case Exchange forest 2 (Exchange 2007 forest) and then click “Next”.
Figure 4: New Trust Relationship wizard – Trust Name
On the “Trust Type” page, select “Forest trust” and then click “Next”.
Figure 5: New Trust Relationship wizard – Trust Type
On the “Direction of Trust” page, select “Two-way” and click Next”.
Figure 6: New Trust Relationship wizard – Direction of Trust
On the “Sides of Trust”, since we want to create a two-way trust, select “both this domain and the specified domain” and click “Next”.
Figure 7: New Trust Relationship wizard – Sides of Trust
We now need to specify the name and password of an account that has administrative previleges in the specified domain. Click “Next”.
Figure 8: New Trust Relationship wizard – Authentication account
Since we want forest-wide authentication both ways, select “Forest-wide authentication” on the “Outgoing Trust Authentication Level-Local Forest” and click “Next”.
Figure 9: New Trust Relationship wizard – Authentication type
Again select “Forest-wide authentication” and click “Next”.
Figure 10: New Trust Relationship wizard – Authentication type
On the “Trust Sleections Complete” page, click “Next”.
Figure 11: New Trust Relationship wizard – Trust Selections Complete
The trust has now been created. Click “Next”.
Figure 12: New Trust Relationship wizard – Trust Creation Complete
To make sure the two-way trust has been created properly, select “Yes, confirm the outgoing trust” as shown in Figure 13.
Figure 13: New Trust Relationship wizard – Confirming Outgoing Trust
Do the same in order to confirm the incoming trust and click “Next”.
Figure 14: New Trust Relationship wizard – Confirming Incoming Trust
Finally click “Finish” to exit the “New Trust Wizard”.
Figure 15: New Trust Relationship wizard – Completing trust
We have now established a two-way trust relationship between Exchange Forest 1 (Exchange 2010 forest) and Exchange Forest 2 (Exchange 2007 forest).
Figure 16: List of Trust relationships
To establish a two-way trust relationship between Exchange forest 1 (Exchange 2010 forest) and Exchange Forest 3 (Exchange 2003 forest), repeat the above steps with the only difference being the name of the forest you want to establish the trust (in this example e2k3forest.dk instead of e2k7forest.dk).
Figure 17: New Trust Relationship wizard – Trust Name
Okay when it comes to trust relationships we now have everything settled for Exchange forest 1 (Exchange 2010 forest).
Figure 18: List of Trust relationships
However, we still need to have a trust relationship established between Exchange Forest 2 (Exchange 2007 Forest) and Exchange Forest 3 (Exchange 2003 forest). To do so, open the ADDT console from a Domain Controller in Exchange Forest 2 and then repeat the above steps.
Configuring Cross-Forest Connectors
We have now reached the time where we need to configure cross-forest connectors between the Exchange forests. This is needed so that Exchange users in each forest can email recipients in the other forests and vice versa. If we do not create dedicated cross-forest connectors, the transport servers in each domain will use the connector that has “*” as address space, which most likely means Exchange will try to route the emails messages to the Internet.
To prepare Exchange Forest 1 (Exchange 2010 forest) for cross-forest mail flow, logon on one of the Exchange 2010 servers and then launch the “Exchange Management Console”.
Expand “Server Configuration” > “Hub Transport” and then open the property page for the “Default <server> Receive connector”. On the property page, click the “Permission Groups” tab. Under the “Permissions Groups” tab, tick “Anonymous users” so that non-authenticated mail servers can send mail to the Exchange 2010 forest.
Figure 19: Enabling Anounymous users on the default receive connector
Now expand “Organization Configuration” > “Hub Transport” and then click the “Send Connectors” tab. Under the “Send Connector” tab, right-click somewhere in the white space and select “New Send Connector” in the context menu.
Figure 20: Creating a new send connector
We will first create a send connector that points to the Hub Transport server in Exchange Forest 2 (Exchange 2007), so we’ll name the connector “To Exchange forest 2 (Exchange 2007 forest)”.
Click “Next”.
Figure 21: Naming the New Send Connector
On the “Address space” page, click “Add”.
Figure 22: Adding Address Space for Exchange 2007 Forest
Enter the SMTP domain for Exchange Forest 2 (Exchange 2007 forest), which in this example is “e2k7forest.dk” then click “OK” and “Next”.
Figure 23: Adding Address Space for Exchange 2007 Forest – 2
On the “Network settings” page, select “Route mail through the following smart hosts” and click “Add”.
Figure 24: Specifying smart host in Exchange 2007 Forest
Enter the IP address of the Hub Transport server in Exchange Forest 2 (Exchange 2007 forest), and click “OK” and “Next”.
Figure 25: Specifying smart host in Exchange 2007 Forest – 2
Click “Next”.
Figure 26: Authentication setting page
And “Next”.
Figure 27: Source server page
Click “New” to create the send connector.
Figure 28: Completing creation of the send connector
To exit the “New Send Connector” wizard, click “Finish”.
Figure 29: Completion page
Now launch the “New Send Connector” wizard again. Repeat the above steps but with the following differences.
Name the send connector “To Exchange Forest 3 (Exchange 2003 forest)”.
Figure 30: Naming the New Send Connector
Under the “Address space” page, add the Exchange 2003 SMTP domain which in this example is “e2k3forest.dk”.
Figure 31: Adding the SMTP address space for the Exchange 2003 forest
Under “Network settings” add a smart host that points to the Exchange 2003 front-end server.
Figure 32: Adding the smart host for the Exchange 2003 forest
We now have two send connectors in Exchange Forest 1 (Exchange 2010 forest) and the forest has been prepared for cross-forest SMTP mail flow.
Figure 33: List of Send Connector in Exchange 2010 Forest
Now logon to an Exchange 2007 server in Exchange Forest 2 (Exchange 2007 forest) and first enable “Anonymous users” on the default receive connector just like we did in the Exchange 2010 forest.
Figure 34: Enabling Anounymous users on the default receive connector
Now create two send connectors in this forest. One that points to Exchange forest 1 (Exchange 2010 forest) and one that points to Exchange Forest 3 (Exchange 2003 forest). We now have two send connectors in Exchange Forest 2 (Exchange 2007 forest) and the forest has been prepared for cross-forest SMTP mail flow.
Figure 35
Okay, we only have one remaining forest to prepare and that is Exchange Forest 3 (Exchange 2003 forest), where the steps are slightly different.
Logon to one of the Exchange 2003 servers and then launch the “Exchange System Manager”. In the ESM, expand “Servers” > “front-end server” > “Protocols” and click “SMTP”. Under “SMTP”, open the property page for the “Default SMTP Virtual Server” then click the “Access” tab and “Authentication”. Notice that, unlike Exchange 2010 and 2007, Exchange 2003 has anounymous access enabled by default (Figure 36), which means we don’t have to make any modifications to the “Default SMTP Virtual Server”.
Click “Cancel” twice.
Figure 36: Anonymous users enabled by default in Exchange 2003
Click the “Connectors” node and then select to create a new “SMTP Connector”
Figure 37: Creating a new SMTP connector
Since this is the connector that will point to Exchange Forest 1 (Exchange 2010 forest), we will call it “To Exchange Forest 1 (Exchange 2010 forest)”.
Set the bullet in “Forward all mail through this connector to the following smart hosts” and then enter the IP address of the Hub Transport server in the Exchange 2010 forest (in brackets) as shown in Figure 38.
Under “Local bridgeheads”, click “Add” and then select the Exchange 2003 front-end server.
Figure 38: Configuring the Exchange 2003 SMTP Connector
Now click the “Address Space” tab. Click “Add”.
Figure 39: Address space tab for the SMTP connector
Select “SMTP” then click “OK”.
Figure 40: Selecting SMTP
Enter the SMTP domain name of the Exchange 2010 forest which in this example is “e2k10forest.dk” and click “OK” twice to create the SMTP connector.
Figure 41: SMTP domain for Exchange 2010 forest
Now repeat the above steps but name the SMTP connector “To Exchange Forest 2 (Exchange 2007 forest )” and point to the Hub Transport server as smart host in the Exchange 2007 forest.
Figure 42: Configuring the second SMTP connector
Under the “Address Space” tab enter the SMTP domain for the Exchange 2007 forest, which is “e2k7forest.dk”
Figure 43: Adding SMTP domain for Exchange 2007 domain to SMTP connector
We have now configured cross-forest SMTP mail flow.
Verifying E-Mail Flow between Forests
In order to verify that e-mail flow works properly between the forests, logon to OWA or Outlook using a test account and then send an email message to a recipient in the two other forests. Perform this step in each forest and make sure you receive the test e-mail message as shown in Figure 44, 45 and 46.
Figure 44: Test Messages received in Exchange Forest 1 (Exchange 2010 forest)
Figure 45: Test Messages received in Exchange Forest 2 (Exchange 2007 forest)
Figure 46: Test Messages received in Exchange Forest 3 (Exchange 2003 forest)
This concludes part two of this articles series, but do not panic, part 3 will arrive sooner than you think.
If you would like to read the other parts in this article series please go to:
- Deep dive into rich coexistence between Exchange Forests (Part 1)
- Deep dive into rich coexistence between Exchange Forests (Part 3)
- Deep dive into rich coexistence between Exchange Forests (Part 4)
- Deep dive into rich coexistence between Exchange Forests (Part 5)
- Deep dive into rich coexistence between Exchange Forests (Part 6)
- Deep dive into rich coexistence between Exchange Forests (Part 7)
- Deep dive into rich coexistence between Exchange Forests (Part 8)
- Deep dive into rich coexistence between Exchange Forests (Part 9)
- Deep dive into rich coexistence between Exchange Forests (Part 10)
- Deep dive into rich coexistence between Exchange Forests (Part 11)
- Deep dive into rich coexistence between Exchange Forests (Part 12)
- Deep dive into rich coexistence between Exchange Forests (Part 13)
- Deep dive into rich coexistence between Exchange Forests (Part 14)
- Deep dive into rich coexistence between Exchange Forests (Part 15)