Exchange 2010 ActiveSync error with the latest Exchange iApp template

To help narrow down the problem, could you provide some more details on your deployment: Are you deploying Exchange 2010 or 2013? Did you choose a single HTTP virtual server for all services, or separate? Are you using SNAT? Is the BIG-IP behind a NAT?

I've seen something similar which came down to Transfer-Encoding and HTTP::rechunk, but I thought that had gone away in recent template versions.

Thanks eeyOre. Here's my settings: Deployment: - Exchange 2010 - Single HTTP virtual server for all services - Yes, SNAT, and running in SSL bridging mode (re-encryption) - BIG-IP is not behind NAT

do you have any idea? Thanks a lot.

Hi, are ActiveSync clients experiencing problems, or does it only happen when using testexchangeconnectivity.com to check the service?

Does testexchangeconnectivity.com indicate the server HTTP response (500, 404, etc) in its logs?

You will need to use tcpdump/ssldump to capture and decrypt traffic on BIG-IP while the problem is happening: http://support.f5.com/kb/en-us/solutions/public/10000/200/sol10209.html

The connectivity analyzer should show you the OPTIONS request that it sent to the CAS; looking for that request and its corresponding response in the packet capture should give us clues about what's going on.

Mike

Thanks for all of your help. AFter tcpdump/ssldump, i found some hints:

1. The FolderSync doesn't work, no matter a real ActiveSync device or testexchangeconnectivity.com
2. Here's the http flow:

Request 1: (there're other details, but I posted the important msgs only) OPTIONS /Microsoft-Server-ActivSync/ HTTP/1.1\r\n Authorization: Basic XXXXXXXXXXXXXXXXX\r\n

Response 1: HTTP/1.1 200 OK\r\n (That means the authorization is correct)

Request 2: POST /Microsoft-Server-ActiveSync/?Cmd=FolderSync&User=XXXXXXXX&DeviceId=2006028807&Devicetype=TestActiveSyncConnectivity HTTP/1.1\r\n

Response 2: HTTP/1.1 401 Unauthorized\r\n

However, it's stranged, becuase 1. The account must be corrected. (I examined the decrypted message and found the a/c and passwords are correct) 2. ActiveSync works fine without passing through the load balancer. There's only ONE member in the virtual server at this moment, but still got this problem 3. Seems the connection is lost so that the Authorization status can't be passed to next request

Because there's sensitive information in the tcpdump so I don't want to post all the messages here. If you're F5 support persons, would you mind giving me your F5 email address so I can send the dump to you directly?

Thanks a lot!!

Hello. I am having this exact issue with a Exchange 2010 deployment on ver 11.2. I have the virtual server configured for a single vip for all https access. I did not use the iapp, instead I manually configured everything. So far everything else seems to be working except activesync. Was there any resolution of this issue?

Hi Jlee, can you post the ActiveSync section of your combined persistence iRule here?

thanks

Mike

Thanks for responding. I downloaded the irule from www.f5.com/solution-center/deployment-guides/files/exchange-persist.zip Here is the section from the irule for ActiveSync: when HTTP_REQUEST {

 Offline Address Book and Autodiscover do not require persistence.

switch -glob -- [string tolower [HTTP::path]] {

    "/microsoft-server-activesync" {
         ActiveSync.
        if { [HTTP::header exists "APM_session"] } {
            persist uie [HTTP::header "APM_session"] 7200
        } elseif { [HTTP::header exists "Authorization"] } {
            persist uie [HTTP::header "Authorization"] 7200
        } else {
            persist source_addr
        }
        pool outlook-activesync-https_pool
        COMPRESS::disable
        CACHE::disable
        return
    }

There is a section at the end of the irule that I am not sure of the purpose. It is listed below: when HTTP_RESPONSE { if { [string tolower [HTTP::header values "WWW-Authenticate"]] contains "negotiate"} { ONECONNECT::reuse disable ONECONNECT::detach disable this command disables NTLM conn pool for connections where OneConnect has been disabled NTLM::disable } this command rechunks encoded responses if {[HTTP::header exists "Transfer-Encoding"]} { HTTP::payload rechunk }

First, you should add a wildcard to the URI that we're checking for ActiveSync:

"/microsoft-server-activesync*" {

The purpose of the last section is to disable OneConnect if a Negotiate header is seen, because the proper OC/NTLM behavior is triggered by seeing the NTLM header first. Shouldn't have anything to do with ActiveSync, which uses Basic auth.

Are you seeing the same issue where the POST request does not include the Basic auth header?

Yes, we are seeing the same issue as the previous person. The post does not include the basic auth header and we get a 401 response. FYI, it works correctly when we go directly to the server.

Have you confirmed that the Basic auth header is not being sent when bypassing BIG-IP?

I ask because according to the ActiveSync protocol specification, the auth header is required:

http://msdn.microsoft.com/en-us/library/ee159244(v=exchg.80).aspx