Exchange 2010 Deployment Guide and ActiveSync

I asked support... Even he was confused... They're going to get back to me.

I do know that we'd be better off on 11.3.0 rather than 11.2.1HF6... but vCMP memory leaves us unable to do that at the moment.

H

Hi Hamish-

I'm sorry if my earlier answer created some confusion.

When I mention that the iRule has a misleading name, I'm referring to the "OA" part; the iRule supports not only OA (OutlookAnywhere), but ActiveSync, Autodiscover, etc.

However, the "Basic" part of the iRule is accurate. The other rule with a similar name (_sys_APM_ExchangeSupport_OA_NtlmAuth) was added in 11.3. So you need to have at least 11.3.0 to support NTLM through APM.

We'll add another note to the manual configuration sections of the Deployment Guide to clarify that point.

With 11.4, the iRules aren't used at all, though are still on-box for legacy purposes if upgrading from an earlier version. Instead, there's a new Exchange profile that APM uses that includes support for each service and protocol. The iApp template will set that up automatically if run on an 11.4.x system.

Cheers Dayne.

Which makes me wonder about EWS support... This iRule ONLY does basic auth. But basic auth for EWS is explicitly stripped out, unless you copy the iRule and modify iot (It's signed, so you can't modify it in place).

Is that by design? or just a simple over-sight? Or am I missing something? (In fact the doc seems to ignore EWS entirely. Especially in the requirements).

FWIW we did get it working. Basically enable the EWS BKEND basic auth variable, (Enable 401 caching while we're at it) and modify the VPE to include AD auth after splitting between exchange clients (non-interactive) and non-exchange clinets (interactive) so that interactive need to use securid.

[Note that doesn't take into account enforcing securid for all OWA. In theory you could get around the securid auth requirement by using EWS or acctivesync to setup a session, so you have to catch that later in an iRule to veriofy all access to /owa* has had a secureid authentication]

H

But not without issues... Sorry, this thread is going to end up like war & peace...

First a warning. DO NOT enable the AUTH caching. It's evil. It will break your service. (Did for me anyway) badly.

Basically as soon as the iRule detects ANY form of issue, it'll cache that in a table for the APM session. And return a 401 to the client. Which tells the client try again. So it does. At which point the iRule sees that the table has cached the bad auth result and just returns a 401 again. Resetting the table timer... Because that client is pretty much guaranteed to keep trying, it will fail forever. Trying to then disable the caching won't help BTW. There's no test before checking the table that caching is enabled. So disabling just stops NEW clients from experiencing the issue. Current sessions will continue to break. Seemingly forever (That's an exadgeration. but for users, even 5 minutes is forever, and my iPhone was broken for over an hour because I typed my passwd wrong once while trying to test it). because the PASSWORD is not checked it doesn't matter if you got it wrong, and now want to fix it. You'll still get the cached 401's... Oops..

Second issue. The iRule seems to have an issue with throttling of EWS. particularly for Mac OS 10.8 mail client.

I haven't traced this one out completely yet, but it would appear that on initial connection, mac mail works fine. it tries to connect, EWS bas to be basic auth, so it gets a 401. It replies with the auth, that passes through, exchange creates a session, all is happy. For a bit. Then throttling kicks in. After working for a bit (200 OK's coming back fine & dandy), exchange sends back a 401 Unauthorized. So it looks like the client then starts trying to re-authenticate. But because EWS sends back headers indicating it'll do NTLM, negotiate, AND Basic the mac client keeps trying NTLM (Evidenced by enabling debug for the APM logs). But the iRule on 10.2.1 doesn't do NTLM. It only does Basic. So it sends back a 401...

The APM debug logs at this stage show the same client going round in circles. Requests with NTLM a few times... 401's returned. Requests with no auth header... 401 returned... Sleeps for a bit. Repeat. Ad-infinitum. A 'long' period of not doing anything (sleep the laptop & go home), OR a restart of the Mac mail client seems to kick it into life again...

I'm hoping that if the exchange guys can get the throttling turned off, we'll get that fixed. But in the meantime, it would appear that the Mac mail client doesn't work seamlessly with BigIP 10.2.1... (i.e. Anything prior to 11.3.0 where you can use NTLM).

H

Oh... A suggestion... All the logging in the default _sys_APM_OA_Exchange_BasicAuth iRule is to the APM file at debug level. When the iRule is responding ITSELF (i.e. the 401's requesting basic auth), I think it would be advantageous to have it log a little higher priority by default...

Otherwise the response logs from the logging profile actually look like it's being serviced by the exchange servers. (You can't reliably tell from the RS logs when a 401 was generated by the iRule or the exchange servers. And if you don't have debug enabled on APM logs, you can't tell at all). (Yes, I could put in an HSL log line in the iRule by copy & edit. Which I probably would. but default logging of errors is ALMOST always a good thing IMO]

Of course having the logging profile accurately represent whether the response was from the selected pool member or not would be good too... Along with APM username availability... Hint...

** ALMOST == If I ever catch the person who dreamt up the default Java concept of logging 200+ meaningless lines for every exception and then keep running I probably won't be buying them a beer.

Suggestion 2. Some way to identify the user/session/connection with each of the debug lines... because it's multi-threaded you can't really relate lines to each other easily. You can KIND of follow it... Until you get into the Waiting ... bits... At which point it becomes a bit of a mess.