daknetworks.com

In my recent article USING MANDRILL WITH EXCHANGE 2013, I show how to add Mandrill to Exchange as a SEND CONNECTOR. Further questions become:

1: How do I use it as a load balancer. In other words, how do I set it up so that some of the email goes through the second SEND CONNECTOR?

2: How do I use it as a failover? In other words, how do I set it up so that if the first SEND CONNECTOR doesn't route email, it re-routes through the second SEND CONNECTOR?

 Let's address each individually.

Load Balancer

The problem is this, multiple equal cost send-connectors will not balance. Or as I read, "When the cost of the Send Connectors and the proximity to their source servers are the same, Exchange will simply choose the one with the alphanumerically lower connector name, and will not load balance the outgoing email across both connections."

The actual way to load balance is when multiple smart hosts are configured on a single Send Connector the outgoing email will be correctly load balanced.

The problem becomes, if you try this in reality, you must use the same USERNAME & PASSWORD for all SMARTHOSTS, which isn't a possibility. And secondly, you cannot load balance both the local connection and a smarthost.

The workaround solution for crappy software is (reprinted from http://www.c7solutions.com/2012/05/highly-available-geo-redundancy-with-html):

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.

Failover

Failover seems to be answered via the same path. The idea is create 1 send connector. The first MX record in the fake SMARTHOST in the SEND-CONNECTOR is back to the local system. The second MX record in teh fake SMARTHOST is to the remote SMARTHOST.

As per http://technet.microsoft.com/en-us/magazine/jj159083.aspx

First of all, ensure you have DNS A records for your mail gateways in place. Next, come up with a random name for your soon-to-be-created MX record in DNS. In this example, I chose allsmarthosts.forest1.local. Create the required MX records in DNS.

As with plain MX-based routing, Exchange will use the MX record with the higher priority, as long as it’s available. Now the only thing left to do is to reconfigure the Exchange Send Connector to read allsmarthosts.forest1.local as the only smart host.

By doing so, Exchange will use primary.forest1.local for outbound mail, as long as it’s available. Once it goes down or becomes unreachable, Exchange will start using secondary.forest1.local as the smart host. That’s what a little DNS trickery can do for you.

 Conclusion

The idea of this is to use MANDRILL if for some reason mail is not being sent through the local connection (for example, blacklist). I didn't implement the solutions above simply because I don't think it will work with a SMARTHOST that requires a USER/PASS. I'm not willing to try. That's suicide by client.

In the end, software is set to work in a certain way. When it doesn't, trying to find workarounds is nearly impossible and seemingly pointless. The end result is that EXCHANGE 2013 isn't set to work this way. I wanted this to happen automatically. Since it doesn't, I'll just have to manually switch SEND CONNECTORS if the need arises. Maybe it doesn't matter a whole lot in an ever-increasing cloud world.