Two Sites, One Domain

Home > Exchange 2010

Introduction - Using the Same Domain on Two Completely Separate Exchange Installations

You may come to a situation where you have two separate Exchange or SBS servers that need to share the same public domain name, plus have users in the "other" site in the GAL. If you cannot find a way to connect the sites and merge them in to a single domain and Exchange organisation then you need to find a solution that allows email to flow between the sites.

There are actually two ways that this can be done - DNS and Send Connectors. For both methods, the recipient configuration is the same, all that is different is how the server is setup. However in both cases while they work they do not scale very well. Once you get above three or four sites you should start to consider merging in to one domain and one Exchange organisation - which is how Exchange is designed to work.

This is an enhancement of the share SMTP address space procedure, allowing users to appear in the GAL, but does NOT include free/busy information.

Server Configuration

DNS Method

The DNS Method uses additional entries in your internal DNS to direct the traffic. IT has the advantage of allowing you to add other things for each site to the DNS, and therefore keeping some configuration internal. If you are mixing mail servers, for example Exchange and a mail server on a Linux variant, then the DNS method is your best option as it is OS independent - as long as the other mail server is using Windows for DNS of course. If it is not, then you can configure something similar in a local DNS server that the Linux server uses.

If you are using a Send Connector to route email via a smart host then you should read the notes later in this article.

Decide which server is going to be the primary. This is the one that will receive all the email. You can use one of the others for a secondary server if you wish.
Setup MX records for your primary domain pointing to these servers, remembering to get the weighting correct.
Add an Accepted Domain on each server for your primary domain. Make sure that the option about exchange being responsible for all email delivery to this address is enabled. It should be the primary recipient policy.
Also create an email address policy for the accepted domain.
Create sub domains for each site in the DNS of each server.
Therefore if you had three sites of London, Paris and Madrid then you would have
- london.example.local
- paris.example.local
- madrid.example.local
While working in the internal DNS of each server, create MX records with the external IP address of the other server.
Therefore the London site will have DNS zones for paris.example.local and madrid.example.local and in those will be a DNS entry for mail.paris.example.local and mail.madrid.example.local. Each of those would also be set as MX records.
These MX records do NOT appear on the Internet, but traffic will flow on them because your local machine is looking up the MX records from the location DNS.

NOTE: It is important that your DNS is configured correctly. The server should be configured to use your active directory domain controllers for DNS - no external DNS servers should be used.
If you need to use external DNS servers for performance reasons then configure these as forwarders on the active directory DNS servers.

Send Connector Method

The Send Connector method requires similar steps to the above. However it will only work for Exchange servers. If you want to mix server types then use the DNS method outlined above.

Create a Send Connector for each site in the primary site. So in London you would have a Send connector for Paris and Madrid.
Set each connector to use a smart host for the delivery, with the address space of location.example.local. The smart host should be the server that is hosting the email for that location. So for paris.example.local it would be the host name of the server in Paris. You can use an IP address, but remember to enclose it in [] - [192.168.10.10]
Repeat on the other servers.
In Exchange 2010 where you have existing Send connectors, adjust the cost of the * in Address Space to 10 - see below.

Existing Send Connectors

You will already have a Send Connector which will also require an adjustment.

If you are using the DNS method and the existing connector is being used simply for sending email by DNS, then you don't need to change anything. The server will do a DNS lookup as normal and send the email using the information that it finds.

However if you are using a Send connector to send email via a smart host because you are on a dynamic IP address or other connection where remote sites will not accept direct email delivery, then you will need to adjust the existing connector by changing the cost of the * Address space to 10.
With the DNS method, leave the option to use DNS, not a smart host. The connector will then use a direct connection (found from your internal DNS) for inter-site traffic and the settings on the original SMTP connector for all other email.

If you are using a Send Connector because you have no other option - usually because your ISP blocks connections to port 25 (smtp) on any server other their own, you will have to adjust this solution. You will have two options.

Setup a VPN between the other sites. Then configure a Send Connector with a lower cost using the internet IP address or dns name (that resolves to an internal IP address) as the smart host.
Switch to using your public DNS for the location information (so london.example.COM) and then adjust your public DNS settings at your domain name registrar to make the sub domains valid on the Internet. They will also require MX records pointing to the relevant server. Ask whoever looks after your domain name how this can be setup.

Adjusting the User Accounts

For this method to work, the user accounts on all servers require some additional settings.

On each server, add a new additional email address policy AND accepted domain - but don't make it default. This new recipient policy should match the location.
Continuing with our example:
- In London, it would be london.example.local
- In Paris it would be paris.example.local
- In Madrid it would be madrid.example.local
- On the primary server create a mail enabled contact for all users located on the other servers. When creating the contact, initially put in the email address for it's home address (london.example.local). Once created, wait a moment for email address policy to stamp the account. You should find that the contact now has two email addresses, @example.com and @london.example.local. Do not add local users as they will already have an email address.
  
  Repeat on the other two servers.
  - London will have mail enabled contacts for Paris and Madrid.
  - Paris will have mail enabled contacts for London and Madrid.
  - Madrid will have mail enabled contacts for London and Paris.

Sanity Check

As this can cause an email loop if not configured correctly, there is a sanity check that you can make to ensure that you have it correct.
On the properties of the contact, click on the tab "Exchange General". In the email address box, it should say smtp then username@location.example.local. If it says username@example.com then it is wrong and needs to be changed.
On the email addresses tab, the default email address should be @location.example.local

End Result - Features and Benefits

The net result of this procedure is

Email for your primary domain can be delivered to any server and it will be routed correctly this is useful for backup queuing of email if the other server is down.
Users can type in the full public email address (username@example.com) from any site and it will be routed correctly.
Users from all three sites will appear in the GAL.
You can create distribution lists on all three sites with the same membership.
By using mail enabled contacts the email destined for the other sites is not stored on your server - taking up no storage space on the server.
The sites only need an internet connection - no direct site connection required.

It can take a while to initially configure, but once done, very easy to maintain if you have limited servers.

Secure Internal Traffic

You do not need additional Receive Connectors as Exchange 2010 will do opportunist TLS. However you do need to ensure that the SSL certificate you are using has the name you have configured the other sites to use as one of the additional names. Using the example names above, the London site would need to have mail.london.example.local in its list.
You can then create an additional Send Connector to require the use of TLS when sending to the remote sites.

Create a Send Connector

Exchange 2010