OWA 2010: "Options" button does not work.

Hi Josh, which version of the Exchange iApp are you using? Have you taken a client side capture of the HTTP traffic? If so, can you see which request is getting hung up?

 

 

Can you post a sanitzed copy of your combined persistence iRule here?

 

thanks

 

Mike

Mike,

We are running f5.microsoft_exchange_2010_cas.2012_06_08.

I have not taken a client side capture yet, but I can do that if we need to.

Here is a copy of the iRule:

 
when HTTP_REQUEST {
     OAB and Autodiscover do not require persistence.

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

    "/microsoft-server-activesync" {
         Direct all ActiveSync clients to a common pool; use Auth
         header value if it exists (Basic auth only, which is the
         default); otherwise we fall back to client IP
        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 FC-EX2010-DC1-CAS_as_pool 
          COMPRESS::disable
         CACHE::disable
        return
    }

    "/owa*" {
         Outlook Web Access
        if { [HTTP::header exists "APM_session"] } {
            persist uie [HTTP::header "APM_session"] 7200
        } else {
            persist cookie insert
        }
         pool FC-EX2010-DC1-CAS_owa_pool
        return
        }

        "/ecp*" {
             Exchange Control Panel.
            if { [HTTP::header exists "APM_session"] } {
                persist uie [HTTP::header "APM_session"] 7200
            } else {
                persist cookie insert
            }
             pool FC-EX2010-DC1-CAS_owa_pool
            return
        }

        "/ews*" {
             Exchange Web Services. 
            if { [HTTP::header exists "APM_session"] } {
                persist uie [HTTP::header "APM_session"] 7200                                
            } else {
                persist source_addr
            }
             pool FC-EX2010-DC1-CAS_oa_pool
              COMPRESS::disable
             CACHE::disable
            return
        }

        "/oab*" {
             Offline Address Book. Persistence is not required for OAB
             pool FC-EX2010-DC1-CAS_oa_pool
            return
        }

        "/rpc/rpcproxy.dll" {
            if { [HTTP::header exists "APM_session"] } {
                persist uie [HTTP::header "APM_session"] 7200
            } elseif { [string tolower [HTTP::header "Authorization"]] starts_with "basic" } {
                persist uie [HTTP::header "Authorization"] 7200
            } else {
                persist source_addr
            }

             Finally, this assigns the Outlook Anywhere pool. 
             pool FC-EX2010-DC1-CAS_oa_pool 

             If the HTTP profile assigned to your virtual server enables Compression
             or RAM Cache, you should un-comment either or both of the following lines
             to turn off the respective feature(s) for Outlook Anywhere connections.
             If you are using Web Accelerator, un-comment both lines.
              COMPRESS::disable
             CACHE::disable
            return
        }

        "/autodiscover*" {
             Requests for Autodiscovery information. No Persistence.
             pool FC-EX2010-DC1-CAS_ad_pool
            return
        }

        default {
             This final section takes all traffic that has not otherwise
             been accounted for and sends it to the pool for Outlook Web App
            if { [HTTP::header exists "APM_session"] } {
                persist uie [HTTP::header "APM_session"] 7200
            } else {
                persist source_addr
            }
             pool FC-EX2010-DC1-CAS_owa_pool 
        }
    }
}

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

There are a few post-config steps that need to be done, like changing any "persist cookie insert" statements in the iRule to "persist cookie insert timeout 0". This is due to a bug where the BIG-IP cookie has an expiration time, even though the cookie persistence profile indicates that it should be a session cookie. If your cookie has timed out, the next request might go to a different CAS and cause problems.

 

 

There's a release candidate version of the iApp that takes care of all these post-config steps: https://devcentral.f5.com/wiki/iApp.Microsoft-Exchange-2010-and-2013-iApp-Template.ashx

 

 

Is it possible to redeploy using this version of the template?

Mike,

 

 

Can I "upgrade" the existing deployment or do I need to delete the old instance and manually re-configure using the new iApp template?

 

 

Thanks,

 

 

Josh

We recommend doing a parallel deployment. The only thing that will conflict is the VIP address. You can create a new instance with the new template using a different IP address for the virtual server, then switch DNS to point to that IP; or you can reconfigure the existing deployment with a different IP, then create a new instance using the production IP address. Then you can delete the old instance.

Mike,

 

 

Running into a problem. I run two instances of the iApp - one for CAS services, and one just for MAPI/RPC services. The CAS instance works fine until I configure a new instance just for MAPI. Then, the CAS HTTPS related services become unavailable.

 

 

Chrome displays: Error 103 (net::ERR_CONNECTION_ABORTED): Unknown error.

 

 

Any ideas?

 

 

Thanks,

 

 

Josh

It seems to maybe be related to both iApp instances using the same SNAT pool (More than 6000 clients)? But, this worked fine in earlier versions of the iApp.

 

 

Josh

Actually, the newer version of the iApp uses unique object names for the SNAT pools. Do you have the same addresses in those pools?

 

 

When you say that the HTTP services become unavailable, do you mean that the pool members are being marked down? Or are they healthy, but clients just can't connect to them?

Actually, I'm having problems with the health monitors on various CAS services too. I reverted to the old iApp, and all monitors work fine.

 

EDIT - It's the EAV monitors that are failing on the new iApp (RC). My AD and OA pools are being marked as down.

 

Which monitor type are you using, simple or advanced? Can you compare the monitor send/receive strings from both the new and old deployments? Are they continuously marked down, or are they flapping?