Forum Discussion

Rabbit23_116296's avatar
Rabbit23_116296
Icon for Nimbostratus rankNimbostratus
Sep 04, 2013

Exchange 2010 and EWS intermittent Issues

Using BIG-IP v11.3.0 (Build 2968.0) with Exchange 2010 SP3 and template f5.microsoft_exchange_2010_cas.2012_06_08.

 

Currently the same IP address used for OWA is being used for EWS. What happens is that EWS will work when starting Outlook, I can do free/busy lookups and then it would just stop working until I restart Outlook. Also when trying to look at a user's manager/direct reports it will also just stop working until restart (not sure if this is also EWS as expected or possibly the address book service proxy (configured on a static RPC port). If I point EWS in hosts to any of the pool members I dont have an issue.

 

So...I realise there's a new template but was wondering if this may not have something to do with source IP persistence?

 

application delivery
devops
iApps
iRules
microsoft

5 Replies

Sort By
  • mikeshimkus_111's avatar
    mikeshimkus_111
    Historic F5 Account
    Sep 04, 2013

    The source address persistence profile assigned to both the EWS and RPC virtual servers should persist requests for those services to the same CAS for the same client IP.

     

    How long does it take for EWS to stop working? When it does, do you see EWS connections going to a different pool member than the RPC connections? If you run Fiddler on the client or tcpdump on the BIG-IP, you should be able to see the HTTP response for the failed EWS requests.

     

    We recommend using the v1.2.0 iApp version in any case, since it has many fixes and added features over the version you are using.

     

    thanks

     

    Mike

     

  • Rabbit23_116296's avatar
    Rabbit23_116296
    Icon for Nimbostratus rankNimbostratus
    Sep 06, 2013

    Thanks - I notice when running wireshark that it is definitely the RPC address book service (configured on static ports) that is responsible for expanding things like manager and direct reports when looking at the GAL. All web services are cookie based persistence and all RPC, RPC MAPI and RPC Address Book are source IP based persistence.

     

    Now that I'm running a wireshark trace I am testing intermittently to see if a specific time window stops it from working. Will update when I know more.

     

  • mikeshimkus_111's avatar
    mikeshimkus_111
    Historic F5 Account
    Sep 06, 2013

    Sounds good. BTW, if you used the iApp, EWS is persisted on source IP, ActiveSync uses the Basic auth header value, and Outlook Anywhere uses auth header or source IP. All of the other HTTP services do use cookie.

     

    • Rabbit23_116296's avatar
      Rabbit23_116296
      Icon for Nimbostratus rankNimbostratus
      Sep 06, 2013
      OK I haven't phased in Outlook anywhere and ActiveSync yet because of architectural dependencies. You raise an interesting point though because I just went through the template and it presents me with the question - 'Are you deploying Outlook Anywhere? (includes EWS and OAB)' Then it only presents a single FQDN to use. I have not gone down this route yet as all traffic served through the F5 at the moment is RPC (internal), EWS (internal and external), OWA (internal and external) and Autodiscover, leaving ActiveSync and external Outlook Anywhere still going through multiple AD site NLBS that I'm in the process of decommissioning. These are the interfaces and what they are used for: Web App -- 10.187.62.21 ActiveSync -- 10.187.62.22 Autodiscover -- 10.187.62.23 RPC (ports 59523, 59524) -- 10.187.62.24 IMAP4S -- 10.187.62.25 So I could have multiple virtual servers per IP/port combos that would respect virtual server persistence profiles etc? This is something I never considered :) I did find this and not sure if it would affect our deployment as it is a simple LTM, no GTM - http://support.f5.com/kb/en-us/solutions/public/9000/800/sol9890.html Thanks for the reply.
    • mikeshimkus_111's avatar
      mikeshimkus_111
      Historic F5 Account
      Sep 06, 2013
      You can either have one virtual server that accepts traffic for all services and assigns persistence and pools using a single iRule, or separate virtual servers for each service. Persistence profiles can be set to match across virtual servers, so if I understand the question, the answer is yes, you could set up multiple virtuals maintain persistence across them as long as they share a common persistence profile where "match across" is set.