In my earlier blog posts Building Hosted Exchange Part I (overview), Building Hosted Exchange Part II (Active Directory) and Building Hosted Exchange Part III (Exchange and ABP’s) and Building Hosted Exchange Part IV (Global Settings) we’ve created a simple Exchange 2010 organization that’s capable of hosting multiple organizations, separated from each other and each having their own Address Books. There’s one last issue I want to point out and that’s message routing. Exchange sees the entire Exchange organization as just one entity and does not care at all about routing between tenants. This is true for SMTP routing as well as out-of-office messages (which are SMTP messages as well of course) for internal and external OOF messages.
Note: using the Address Book Policies you can do ‘GAL segmentation’ but this is a feature that’s only targeted towards Address Books. Transport doesn’t do anything with Address Book Policies!
So far we’ve setup the following environment when it comes to Exchange 2010 SP2:
Figure 1. High level hosted Exchange 2010 environment
When it comes to Active Directory we’ve created three Organizational Units for three customers and we’ve created three types of Address Lists and Address Book Policies:
Figure 2. Three OU’s in Active Directory for three customers
Figure 3. Three Address Book Policies for three customers.
Please check my blog post Building Hosted Exchange Part III (Exchange and ABP’s) for detailed information about the Exchange setup.
In this environment both inbound and outbound SMTP message (from and to the Internet) is working fine. Everything get delivered as expected. An Exchange 2010 Edge Transport Server is installed in the DMZ but an Edge Synchronization is not used. The Edge Transport Server handles anti-spam and can do anti-virus optionally when Forefront for Exchange is installed.
Now what happens when a user from customer1 sends a message to customer2? Since these customers are in the same Exchange 2010 SP2 organization Exchange will treat the message as an internal message. Suppose we have a recipient called Bill@customer1.com and John@customer2.com and Bill sends a message to John. When John checks the message header it is obvious it is an internal message:
Received: from HMBX01.exhosting.local ([fe80::60c2:4c72:1730:9fc3]) by
HHUB01.exhosting.local ([fe80::815d:2bdc:8db2:6a0b%11]) with mapi id
14.02.0283.003; Fri, 11 May 2012 00:14:06 +0200
Content-Type: application/ms-tnef; name=”winmail.dat”
From: Bill Schmuck Bill@customer1.com
To: John DeGreat email@example.com
Date: Fri, 11 May 2012 00:14:04 +0200
Accept-Language: en-US, nl-NL
Things gets worse when John double clicks Bill in the message, in this case in OWA:
OWA wants to retrieve information from Active Directory but isn’t allowed to (of course) and an Access is Denied message is shown:
“The Active Directory resource couldn’t be accessed. This may be because the Active Directory object doesn’t exist or the object has become corrupted, or because you don’t have the correct permissions.”
For us it’s clear it’s a permission issue, but John will most likely not understand the error message. Now Bill is out-of-office and John replies to this message he will get an out-of-office reply. Unfortunately Exchange also treats this as an internal recipient and John will receive the internal OOF message from Bill instead of the external OOF message.
There’s no default out-of-the-box solution to get around this. When you read the Microsoft guidance a Transport Agent is mentioned to resolve this. A Transport Agent is a (small) piece of software running on the Hub Transport Server and interacting with the actual transport service.
The transport agent that needs to be used in a hosting environment should pick up all SMTP messages and determine whether or not they are intra-tenant (recipient in the same tenant as the sender), inter-tenant (recipient in another tenant) or external (outside the Exchange environment, most likely somewhere on the Internet). The latter two should be picked up by the Transport Agent and send it outside the Exchange organization.
Now comes the Edge Transport Server: since the Edge Server is not tied to the internal organization using an Edge Synchronization the Edge Server can be used as a smart host for an Internet Send Connector inside the organization. All messages from the Transport Agent will be sent to the Edge Transport Server and processed there. Inter-tenant messages will be returned to the internal organization and delivered to the appropriate mailbox. From an Exchange perspective the message is now an external message and no ‘back link’ exists anymore to the Sender’s tentant.
The Transport Agent will also pickup the OOF messages and determine whether or not the internal OOF messages should be used (within the tenant) or the external OOF message (other tenants or the Internet).
When it comes to SMTP routing in a hosted Exchange 2010 SP2 environment (although the same issues arise in an Exchange 2010 SP1 /hosting environment!) there are a couple of culprits you have to be aware of. If you have a good .NET developer inside the company who knows how to program against Exchange Server 2010 this can be solved in a matter of days.
Another option is to buy a Transport Agent solution from a 3rd party vendor. I know Rickets Corporation is offering a solution for this (download a trial version here: http://www.rickettscorp.com/transportagent.php) and implement.com has a Transport Agent solution for this as well (more info on http://www.implement.com/hosted-exchange-2010-sp2-Multitenant-Transport-Agent/)