Highly Available Geo Redundancy with Outbound Send Connectors in Exchange 2003 and Later


This is something I’ve been meaning to write down for a while. I wrote an answer for this question to LinkedIn about a week ago and I’ve just emailed a MCM Exchange consultant with this – so here we go…

If you configure a Send Connector (Exchange 2007 and 2010) or Exchange 2003 SMTP Connector with multiple smarthosts for delivery to, then Exchange will round-robin across them all equally. This gives high availability, as if a smarthost is unavailable then Exchange will pick the next one and mail will get delivered, but it does not give redundancy across sites. If you add a smarthost in a remote site to the send connector Exchange will use it in turn equally.

So how can get get geographical redundancy with outbound smarthosts? Quite easily it appears, and it all uses a feature of Exchange that’s been around for a while. But first these important points:

  • This works for smarthost delivery and not MX (i.e. DNS) delivery.
  • This is only useful for companies with multiple sites, internet connections in these sites and smarthosts in those sites.
  • This is typically done on your internet send connectors, the ones using the * address space.

You do this by creating a fake domain in DNS. Lets say smarthost.local and then creating A records in this zone for each SMTP smarthost (i.e. mail.oxford.smarthost.local). Then create an MX record for your first site (oxford.smarthost.local MX 10 mail.oxford.smarthost.local). Repeat for each site, where oxford is the site name of the first site in this example.

Then you create second MX records, lower priority, in any site but use the A record of a smarthost in a different site (oxford.smarthost.local MX 20 mail.cambridge.smarthost.local).

Then add oxford.smarthost.local as the target smarthost in the send connector. Exchange will look up the address in DNS as MX first, A record second, IP address last), so it will find the MX record and resolve the A records for the highest priority for the domain and then round-robin across these A records.

If you have more than one smarthost in a site, add more than one MX 10 record, one per smarthost. Exchange will round-robin across the 10’s. When all the 10’s are offline then Exchange will automatically route to mail.cambridge.smarthost.local (MX priority 20 for the oxford site) without needing to disable the connector and retry the queues.

If you used servernames and not MX’s then it would round-robin amongst all entries, and so equally sent email to Cambridge for delivery. The MX option keeps mail in site for delivery until it cannot and then sends it automatically to the failover site.


Tags:

Comments

6 responses to “Highly Available Geo Redundancy with Outbound Send Connectors in Exchange 2003 and Later”

  1. Jeff avatar

    Brilliant. Thanks, Brian

  2. charlesgate86 avatar

    That’s cool,

    I have multiple accepted domain for example abc.com & xyz.com

    Can I configure in such a way that source domain(users@abc.com) should be using send connector(Smarthost1) and source domain(users@xyz.com) should use send connector(smarthost2) to route emails to target domains(*/specific)….?

    Let me know further for more details, Thanks!

  3. Brian Reid avatar

    @charlesgate86 – no that is not possible in the current product set without you writing a transport agent or using the one at http://routingruleagent.codeplex.com

  4. charlesgate86 avatar

    Thank You Brain for directing to the right place.

    I tested in my LAB with 2 accepted domain and creating 2 send connector and followed the instruction as mentioned and it worked superb as per requirement to direct different smart host.

  5. Nick avatar
    Nick

    Great article!

    Is this still valid for Exchange 2013? or does Exchange 2013 contain new features that will provide the same outcome? Thanks.

    1. Brian Reid avatar

      Yes, this works for all versions of Exchange Server from 2003 and onwards.

Leave a Reply to charlesgate86 Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.