Exchange 2010 Deployment Guide and ActiveSync

I'm wondering if the deployment guide is missing the _sys_APM_activesync iRUle addition on page 59... For Separate VS's, it's listed... But not for the combined... Or is the detection supposed to be done elsewhere?

More reading and investigation required...

H

Hi Hamish.

I'm sorry you're having difficulties with ActiveSync.

A couple of things:

1) Are you manually deploying or using an iApp? (we strongly suggest using an iApp) 2) If using an iApp, make sure you're using version 1.2 of the CAS iApp for Exchange 2010 and 2013, available from downloads.f5.com in the 1.0.0.61 iApp bundle. 3) The version of BIG-IP you're using (11.2.1) was released about a year ago. The current version (11.4, soon to be 11.4.1) has seen a lot of changes to APM, most of them introduced in the 11.3 timeframe. I'd highly recommend upgrading to at least the 11.3.x branch. I know you're on a recent hotfix, but not all features and fixes get backported to prior releases.

Also, do you have a support case open with F5? If so, please provide me with your case number and I'll look at details of your configuration. (And if not, please open a case.) In the meantime, I'll see what I can do to reproduce your error here, though knowing more about whether you set up manually vs. using an iApp, and whcih iApp you used if you went that way, would help me out a lot.

I believe you're using an outdated version of the Deployment Guide. Page 59 of the current version doesn't contain information on configuring the APM component for ActiveSync; that's mentioned on page 62, and more info on the config is starts on page 76.

I can see that we need to do some cleanup and clarification on the manual section, since it's hard to walk through in any kind of clear progression. However, I think you'll find that if you use version 1.2 of the iApp, all of this is just done for you.

Please let us know about the items we've asked about above, and please try the iApp if you haven't done so already.

Manually. I like to understand how it's hanging together. No case opened with F5.

FWIW if you read the deployment guide, on page 58 there's no _sys_APM_activesync iRule specified for the combined VS... But is IS specified a few pages further on for the separate VS implementation on the activesync VS...

If you put that iRule in place, then activesync traffic now passes through the VS. The question is really more around, is the deployment guide correct? or wrong. And if it's correct, where is the APM form bypassed for an 11.2.1HF6 install of combined LTM/APM and one VS?

i.e. it could simply be that I haven't read the guide correctly... Or a missing line in that guide...

H

I think there's a disconnect between myself and the deployment guide...

If you read it enough times, i think you can almost fill in the blanks. But there doesn't seem to be detailed manual config on page 82... You're obviously supposed to modify one of the other configs... I just have to work out which one...

All the others have detailed info... Sigh... Trust me to need one that doesn't :)

H

Hello Hamish-

I believe you have helped us identify a problem in our documentation. Thank you for that and I'm sorry it's caused you problems. We're working to get this straightened out now. On first glance it looks like we have some legacy information in the guide; I don't believe it's ever correct to use the _sys_APM_activesync iRule; that's there for backwards support of configurations migrated forward from 10.x. I will gt confirmation of this for you one way or another, though.

In the meantime, could you do me a favor and use the 1.2 version of the iApp to set up a parallel deployment so you can compare configurations and functionality?

https://downloads.f5.com/esd/serveDownload.jsp?path=/big-ip/big-ip_v11.x/11.2.1/english/iapp-templates/&sw=BIG-IP&pro=big-ip_v11.x&ver=11.2.1&container=iApp-Templates&file=iapps-1.0.0.61.0.zip

You'll have to choose a new IP address for the virtual server (or, better, temporarily move your other one), but otherwise should be able to point to the same CAS servers, reuse the same cert and key, etc.

You'll discover that, in your configuration, we assign _sys_APM_ExchangeSupport_OA_BasicAuth (a misleading name; it supports all the services) as the supporting iRule, and don't use the _sys_APM_activesync one at all. (There's one case when we do, but it doesn't apply to your configuration and I think we're going to change that anyway, based on your feedback). We do actually mention on page 79 of the guide that the "ExchangeSupport" iRule is required whether or not you're deploying OutlookAnywhere, but that's far from obvious.

We're going to do a complete audit of our manual configuration tables to make sure they match the tested-to-work-correctly configuration of the iApp. That might take a week or so to test correctly in all the possible configurations (Exchange is complex, as you know), so I definitely think you should use the iApp for the moment.

Cool. Thanks Dayne. Nice to know I'm not completely senile :)

I'll try & get the iApp version installed soon as I can to compare.

H

Hello again, Hamish-

I have confirmed that the _sys_APM_activesync iRule should never been assigned, even when deploying ActiveSync on its own virtual server (which you aren't doing anyway). We're updating the Deployment Guide to reflect that and should have an update posted this afternoon.

We will have a more-complete overhaul of the Deployment Guide manual configuration section in the next week or two, with an eye towards making it easier to step through.

The iApp (version 1.2) already does the right thing on a single virtual server, and also always does the right thing when using BIG-IP 11.4 and higher, but on BIG-IP versions 11.0-11.3 incorrectly assigns the _sys_APM_activesync iRule to the ActiveSync virtual server [and only that one] when separate IP addresses are chosen for each virtual server. We have an internal bug filed against the iApp to correct the behavior in the next release.

The Deployment Guide contradicts the behavior of the iApp. As of this afternoon's update, the DG will have information consistent with what the iApp does, and a suggestion for a workaround for those using the iApp in the specific affected versions and deployment scenarios.

Again, I'd like to apologize for the trouble this has caused you. Please do let us know how version 1.2 of the iApp works for you. Given your scenario, I believe it will do the right thing.

Works much better with the iRUle in place... Now just have to convice the windows guys that the 401's coming back from the servers need looking at :)

H

OK... So looking at this some more. And I can't follow the iRule _sys_APM_ExchangeSupport_OA_BasicAuth and what it's trying to do with regards to /ews (Exchange Web Services) and authentication.

The Exchange has basic auth disabled. So I believe it's expecting NTLM authentication headers coming through (In the Authorization header). But from running through the code, it looks like the authorization header is then REMOVED in the ACCESS_ACL_ALLOWED event... when EWS_BKEND_BASIC_AUTH is NOT defined (This is the default BTW)...

Which removes the NTLM authentication... e.g.

when ACCESS_ACL_ALLOWED {
    log -noname accesscontrol.local1.debug "$static::ACCESS_LOG_PREFIX [HTTP::method] [HTTP::uri] [HTTP::header Content-Length]"

     MSFT Exchange's EWS request handler always requesting NTLM even the connection has been
     already authenticated if there is a HTTP Basic Auth in the request.
    if { [ info exists f_exchange_web_service ] && $f_exchange_web_service  == 1 }  {
        if { $static::EWS_BKEND_BASIC_AUTH == 0 } {
            log -noname accesscontrol.local1.debug "$static::ACCESS_LOG_PREFIX Removing HTTP Basic Authorization header"
            HTTP::header remove Authorization
        }
     }
}

So the backend won't be getting ANY authentication presented (Which coincides with some traffic dumps taken by analytics showing no authorization headers and the subsequent 401 Unauthorized being returned). Shouldn't the code here be testing for BASIC auth and ONLY removing the header if it's BASIC auth being specified? or am I missing something?

The strange thing is, activesync works fine...

** Note I've looked at the iApps, and they don't appear to work on the Lab/VE... Which is my test environment... For some reason I can't see any of the _sys_APM*** iRules

Actually, I read the statement...

You'll discover that, in your configuration, we assign _sys_APM_ExchangeSupport_OA_BasicAuth (a misleading name; it supports all the services) as the supporting iRule, and don't use the _sys_APM_activesync one at all. (There's one case when we do, but it doesn't apply to your configuration and I think we're going to change that anyway, based on your feedback). We do actually mention on page 79 of the guide that the "ExchangeSupport" iRule is required whether or not you're deploying OutlookAnywhere, but that's far from obvious.

to mean the 'BasicAuth' part of the name is misleading... But I'm starting to wonder now, if APM supports anythign BUT BasicAuth on exchange... WHich makes me wonder, what exactly type of auth do you support (for activesync and ews) by default when Basic auth is disabled?

or am I missing something somewhere?