Think Load Balancing Before You Ditch Your Exchange DAG Administrative Access Point

With Exchange 2013 SP1, Microsoft introduced an alternative to the traditional failover cluster on which DAGs are based: no virtual IP, no Cluster Name Object, no worries. For
details see https://technet.microsoft.com/en-AU/library/dd979799(v=exchg.150).aspx.

Backup is the most quoted reason why you may still want to have an administrative access point. Backup software needs an always-on resource to connect to in order to back up
Exchange. And that is, conveniently, the cluster administrative access point. However backup software vendors are catching up with the times and they don't really need a
cluster resource anymore.

So why would you still want to have one? Well, think of inbound SMTP load balancing, and, implicitly, High Availability (HA).

Have you ever tried to load-balance SMTP? If so then you've probably encountered some or all of the following:

• In the Exchange transport logs, all SMTP traffic appears to be coming from a single IP address - that of the load balancer. How do you tell the "real" source without looking at the e-mail headers?
• You have a number of internal devices that need to send unauthenticated e-mail to any recipient, including external ones. Think open relay with restricted access. But if all traffic seems to come from the load balancer, then the only way to allow your multifunction device to scan a document to an external mailbox is to authorise the load balancer as approved source of unauthenticated SMTP traffic. Or you need to send e-mail alerts to an external party as par of your support agreement. Suddenly you have a security problem and a career challenge (you'll cause your organization's servers to be blacklisted in no time and you'll need to explain that to your manager).
• Enable source routing on the load balancer. Bingo, your Exchange server sees the real source. Open relay issue solved. But hey, that will result in asymmetrical routing. Not ideal and usually difficult to diagnose if issues arise. So by solving one problem you introduced another one...

Most of these, and some other aspects, are documented in Paul Cunningham's blog at http://exchangeserverpro.com/issues-with-load-balancing-smtp-traffic/.

The alternative: hang on to your cluster administrative point. The benefits:

• You can send SMTP traffic from internal sources straight to the DAG administrative access point, bypassing the load balancer. No open relay issues, no transport log analysis issues.
• No asymmetrical routing issues.
• Multi-role servers are becoming the norm. In fact, with Exchange 2016, it is the only option. Therefore as long as you have at least one online DAG member, you'll also have implicitly a Hub Transport server too to accept SMTP traffic which will be reachable via the - guess what - thine good olde DAG administrative access point. Therefore service is maintained even if individual DAG members fail.

The solution has one obvious drawback: all inbound SMTP traffic will be processed without any load balancing, by a single Exchange server, the one which holds the name and IP address of the DAG
administrative access point.

As at the time of this post I am yet to see an Exchange infrastructure whith such a heavy inbound SMTP traffic that load balancing (not to be confused with HA) would be a necessity. Therefore the only drawback that I can spot is so insignificant that it can be safely discounted in most environments.

Having said that, I learned to "never say never". If you know of any circumstances where this workaround would not work then please drop me a comment.

Cheers,
Zoltan