Two Sites, One Domain
This is for Exchange 2003 ONLY. For the version for Exchange 2007, click here: Two Sites One Domain - Exchange 2007
You may come to a situation where you have two separate Exchange or SBS servers that need to share the same public domain name. 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 SMTP 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.
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 SMTP Connectors 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.
- Create a recipient policy (if it doesn't already exist) 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.
- 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.
SMTP Connector Method
The SMTP Connector method requires similar steps to the above. However it will only work for Exchange servers. If you want to mix server versions then use the DNS method outlined above.
- Create an SMTP Connector for each site in the primary site. So in London you would have an SMTP 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.
- Where you have existing SMTP connectors, adjust the cost of the * in Address Space to 10 - see below.
Existing SMTP Connectors
If you already an SMTP connector in place then you will need to make an adjustment to its configuration.
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 an SMTP 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 an SMTP 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 an SMTP 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 recipient policy (or email address policy AND accepted domain for Exchange 2007) - 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
The key is that it should NOT be the default policy on any site.
- 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 recipient 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.
The result of this should be that all users have two email addresses - the default one ending in example.com and a secondary one that ends location.example.local.
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
If you want to secure internal traffic between the servers then you can. On Exchange 2003 you will need additional IP addresses and SSL certificates.
In ESM create a second SMTP virtual server and and ensure that it is bound to your second IP address but is still using port 25. Then apply a valid SSL certificate to it. The key thing is that the certificate needs to be the same NAME as you have used in the MX records entered in to the DNS above. Therefore that will probably mean using your .com rather than a .local.
When you configure the DNS records in your internal DNS, use the second IP address, rather than the primary.
Then create SMTP connectors as outlined, but enable the option to use TLS.