Exchange 2013 load balancing per preferred architecture

Hi Geoff-

I'm one of the F5 engineers that creates and validates our Exchange guidance and iApp.

To answer your questions:

1. Our monitors (as configured by the iApp) have two modes that you can choose between: simple and advanced. 'Simple' does use the healthcheck.htm URIs for each service you're deploying. 'Advanced' substitutes in monitors that do actual logins using real accounts that you provide (for Autodiscover and ActiveSync, we actually use both the full-login monitors and the healthcheck.htm monitors when in Advanced mode). We don't find Microsoft's Managed Availability to be very effective. For instance, a CAS server can have no access to a Mailbox server (for any number of reasons) and still report healthy services. You can demonstrate this easily enough by turning off all Mailbox servers in your environment; you'll be able to successfully connect to the healthcheck.htm URI all day long. The flip side of that is that full-login monitors, which do take into account the ability to connect all the way through to the Mailbox servers on each protocol, also can erroneously mark CAS servers down if the mailbox database associated with the monitored account is down, or the account is locked. That's one reason we suggest using two separate monitors with different accounts.
2. There are no problems that have been reported to us using Kerberos with SSL Offload.
3. I'm not sure I've ever heard of a customer using L4 and nPath routing for Exchange. You lose almost all of the features by which BIG-IP LTM adds value: per-application monitoring, SSL Offload, content caching, content compression, OneConnect (TCP multiplexing), etc. Although Microsoft shows L4 as a supported configuration, it's not ideal for all the reasons they call out, and they don't mention nPath in any document I've seen for Exchange. You also don't have the option in the future of adding things like pre-authentication (via BIG-IP's APM module).

I'm curious about your objections to iApp templates "and $$$"; iApps are an integral part of BIG-IP version 11.0 and later, and don't add to cost in any way. Actually, since they simplify both initial setup and application lifecycle management, while allowing those who may not be familiar with BIG-IP to set up and maintain otherwise-complex environment, they can be seen to be a cost-reduction tool in the vast majority of cases. That has been, and remains, one of our primary goals. If there's a specific feature or set of features that you believe the Exchange iApp should include, please feel free to respond to this thread or send your request to 'solutionsfeedback@f5.com'.

I hope that information was helpful.

-Dayne