final exchange persistence irule

foobar.example.com_deployment_guide_persist.irule

ltm rule foobar.example.com_deployment_guide_persist {
  ## iRule to select pool and persistence method when all Exchange Client
  ## Access HTTP-based services are accessed through the same BIG-IP virtual
  ## server. This iRule will use an HTTP header inserted by a BIG-IP Edge
  ## Gateway for persistence (if that header is present); otherwise it will
  ## set persistence according to traditional methods.


  ## Although it is possible to send all connections to the same pool,
  ## advanced health monitors generally check only a specific connection
  ## service. In this example iRule, we send each service to its own pool;
  ## those pools may (and likely will) contain the same servers.
  ## If you revert to simple monitors such as an HTTP GET against a default
  ## document, you can instead use a common pool.

  when HTTP_REQUEST {

  ## CHANGE ALL POOL NAMES TO MATCH THOSE IN YOUR ENVIRONMENT.
  ## YOU MIGHT CHOOSE TO USE THE SAME POOL FOR OWA, ECP and EWS.
  ## 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 foobar.example.com_combined_vs_as_pool

                ## A prior version of this iRule used cookie persistence,
                ## which for clients that do not support cookies resulted
                ## in no persistence. Although persistence is not actually
                ## required for ActiveSync, server-side load and client
                ## latency are both decreased by using persistence.
                return
            }

        "/ews*" {
        ## Exchange Web Services. MSFT recommends Cookie persistence for
        ## EWS, but also notes that some clients don't process cookies.
                #if { [HTTP::header exists "APM_session"] } {
                #       persist uie [HTTP::header "APM_session"] 7200
                #}
                #else {
                #       persist cookie
                #}
                ## If source IPs come from a large range, i.e. they
                ## aren't passing through a SNATing device such as a
                ## proxy or firewall, you can use the client IP as the
                ## persistence token. To do so, comment the section above
                ## and uncomment the following. You may also want to use
                ## source_addr persistence if clients that access your
                ## Exchange Client Access servers do not support HTTP cookies.

                persist source_addr 7200

                ## As an alternative, you can fall back to SSL session
                ## ID; to do so, comment the source_addr persistence
                ## line above and uncomment the following uie persistence line

                # persist uie [SSL::sessionid] 300

                pool foobar.example.com_combined_vs_owa_pool
                return
        }
        "/ecp*" {
        ## Exchange Control Panel.
                if { [HTTP::header exists "APM_session"] } {
                        persist uie [HTTP::header "APM_session"] 7200
                }
                else {
                        persist cookie
                }
                pool foobar.example.com_combined_vs_owa_pool
                return
        }

        "/oab*" {
        ## Offline Address Book. Persistence is not required for OAB
                pool foobar.example.com_combined_vs_owa_pool
                return
        }

        "/rpc/rpcproxy.dll" {
          ## Grab all requests for Outlook Anywhere; the following checks
          ## assign correct persistence methods.
                #if { [HTTP::header exists "APM_session"] } {
                  # persist uie [HTTP::header "APM_session"] 7200
                #}
                #else {
                  # switch -glob [string tolower [HTTP::header "User-Agent"]] {
                      #"msrpc" {
                      ### This User-Agent section matches most versions of
                      ### Outlook and Windows using Outlook Anywhere. The
                      ### OutlookSession cookie is new to Outlook 2010.
                      #   if { [HTTP::cookie exists "OutlookSession"] } {
                      #     persist uie [HTTP::cookie "OutlookSession"] 7200
                      #   }
                      #   else {
                      #     persist uie [HTTP::header "Authorization"] 7200
                      #   }
                      #}
                      #       
                      #"*microsoft office*" {
                      #### This section matches some versions of Outlook 2007 on Windows XP
                      #   persist uie [HTTP::header "Authorization"] 7200
                      #}
                      #default {
                      ### This section catches all other requests for Outlook
                      ### Anywhere, and sets a persistence method that does
                      ### not require the client to support HTTP cookies
                      #       
                      #   persist source_addr
                      #}
                    #}
                #}

          # All of the above magic refused to balance connections.
          # The root cause appears to be NTLM Authz headers that are
          # not unique (enoough).  We are unsure of what clients are the
          # cause but we have many managed workstations sourcing a single image.
          persist source_addr 7200
          
          # Internal M$ claims they run without persistence
          # This failed miserably for us - Outlook 2003 + 2007 
          # refused to stay connected.
          #persist none

          ## Finally, this assigns the Outlook Anywhere pool. If the preceding clients
          ## should be sent to separate pools, the pool statement should be removed
          ## here, and a separate pool statement placed in each of the preceding
          ## logic branches.

          pool foobar.example.com_combined_vs_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 foobar.example.com_combined_vs_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 cookie
          }
            pool foobar.example.com_combined_vs_owa_pool
          }
        }
}

  when HTTP_RESPONSE {
    if { [HTTP::header values WWW-Authenticate] contains "Negotiate" } {
      ONECONNECT::detach disable
      #log local0. "OC disabled for Negotiate my_ex_single_persist"
    }
  }
}