Forum Discussion

Frank_Sweetser_'s avatar
Frank_Sweetser_
Icon for Nimbostratus rankNimbostratus
Apr 23, 2008

Single virtual IP address for all Exchange 2007 HTTP services?

I've been reading through the Exchange 2007 deployment guide at

 

 

http://www.f5.com/pdf/deployment-guides/f5-exchange07-dg.pdf

 

 

Overall I think I have a pretty good handle on how that configuration is put together, but there's a snag with it against our current configuration. Right now, users use a single hostname ('exchange') for all three of the web based services (OWA, Outlook Anywhere, and ActiveSync). In the deployment guide, however, each of the three services sits behind a different virtual IP address.

 

 

I'm assuming that this is done because of the different persistence requirements. Specifically, OWA and ActiveSync can use cookie based persistence, but Outlook Anywhere can't, so it uses an iRule to key off of the "Authorized" HTTP header instead.

 

 

Can anyone suggest a way that I might be able to set up a persistence profile that works with all three services behind a single virtual IP, rather than having to reconfigure and retrain our entire user base?

10 Replies

  • Steve_Brown_882's avatar
    Steve_Brown_882
    Historic F5 Account
    I have Exchange 2007 behind a single VIP with all using cookie persitence as primary persistence. Works perfectly. If think that using fall back persistence may be the answer.
  • Ah, fallback persistence makes sense! I assume that since (according to the deployment guide) Outlook won't support setting cookies, the F5 will detect that and instead use the fallback profile?

     

     

    Can I ask what persistence profile you're using as the fallback one?
  • Marcus_Slawik_8's avatar
    Marcus_Slawik_8
    Historic F5 Account
    If you have a fallback persistence configured (which is btw always sourceIP) then an entry will always be made in the persistence table when somebody hits that VIP. So if the primary persistence fails for whatever reason the sourceIP persistence will jump in. This can lead to problems if the users are behind a proxy server.
  • In that case, it sounds to me like the ideal solution would be an iRule that does something along the lines of this:

     

     

    if ( user agent == outlook ) {

     

    use "Authorized" header for persistence

     

    } else {

     

    use cookie persistence

     

    }

     

     

    Does that sound correct? And if so, anyone have any suggestions on what the actual iRule might be? =)
  • Well, scratch that idea...

     

     

    http://www.25hoursaday.com/weblog/CommentView.aspx?guid=0f5a5e02-a301-4ef2-9da3-e434fd81bb83

     

     

    It looks like requests originating from Outlook 2007 are indistinguishable from IE 7 generated ones.

     

     

    Thanks, Microsoft....
  • Maybe you could just look for the authorization header with a value to persist off of and otherwise use source address persistence?

     

     

    Below is a related post. I'm not sure how well the rule listed worked for the poster, but maybe that could be a starting point.

     

     

    http://devcentral.f5.com/Default.aspx?tabid=53&forumid=5&tpage=1&view=topic&postid=20320

     

     

    Aaron
  • Deb_Allen_18's avatar
    Deb_Allen_18
    Historic F5 Account
    Fallback persistence can use any configured persistence profile, not just srcIP, and the only problem this configuration might create would be some clumping for clients without valid cookies that originate at the same sourceIP.

     

     

    Also, Authorized header is not the same as User-Agent header, so I think Aaron's last post is the answer you're looking for, fs...

     

     

    /deb

     

     

     

     

  • I tried using sourceIP as the fallback persistence when the primary persistence of 'insert cookie'. What I found was that it would always use the fallback persistence (sourceIP).

     

     

    Opened case and what was explained to me was something to the effect that since there is no entry in the persistence tables on the big-IP for 'insert cookie', it will always go into the fallback, method that is specified.

     

     

    Unfortunately, I need to be able to enter into a fallback persistence mode if the client is not accepting cookies. Any ideas?

     

     

  • I don't think that was explained to you very well...there is no entry for cookie persistence because there is no need to keep a table for that. The virtual server "knows" to look for the cookie when the client returns if it is set to use cookie persistence. It still puts an entry in the source IP persistence table, just in case the client does not have the cookie (because it didn't accept it or whatever). Then it can use the fallback source IP persistence if required.

     

     

    So, just because you are seeing entries in the source IP persistence table does not mean that cookie persistence isn't working. How are you verifying that cookie persist isn't what's being used?

     

     

    Denny