Problem with EWS using iapp template 1.40 for Exchange

Hi Mark, if possible can you post the output of "Get-WebServicesVirtualDirectory | fl" here? I'm interested in seeing the internal/external URLs and auth methods you have configured for EWS.

I assume you are not use APM, correct?

Also, which versions of those browsers are you testing with? I'm not running into this issue testing with IE11, Chrome 43, or FF 38.

I'll need to get that from the Exchange server guys, but basically all virtual directories are being sent to the same pool, and NTLM authentication is being used. This is on the internal side, using the template choice of "load balance and optimize CAS traffic" There's no APM involved here and the irule in question is the unmodified Exchange-internal_combined_pool_irule7. I did add log statements to verify what part of it I was hitting when I use the uri of /ews/exchange.asmx. I just noticed I have experimented with enabling and disabling cache in the /ews portion of the irule. That hasn't made any difference.

extracts from irule that are involved below..... "/ews*" { Exchange Web Services. log local0. "using EWS" pool /Common/Exchange-internal.app/Exchange-internal_oa_pool7

        CACHE::disable
        return

when HTTP_RESPONSE { if { [string tolower [HTTP::header values "WWW-Authenticate"]] contains "negotiate"} { log local0. "is ews going here" ONECONNECT::reuse disable ONECONNECT::detach disable NTLM::disable } if {[HTTP::header exists "Transfer-Encoding"]} { HTTP::payload rechunk } }

I do get the log message of "is ews going here", which matches what I see in the headers in the browser. Further testing yesterday leads me to believe I need to look at the ssl client profile to support extensions being used by IE that are recognized when going direct to the server that are not being recognized by the LTM. What's odd is that in my uat environment with an LTM and iapp template of the same version, it works....

The NTLM profile is there to ensure correct auth when OneConnect is used. If a Negotiate auth header is seen in the response, OneConnect can't deal with it and causes multiple auth prompts, so we disable both that and the NTLM profile. You may want to try disabling Negotiate auth on the EWS virtual directory to see if that helps.

Hi Mark,

Did you manage to resolve that problem. If so, how?

Regards Sadik