Forum Discussion
Frank_Sweetser_
Nimbostratus
NimbostratusSingle 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?
- 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.
Frank_Sweetser_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?- I am using source address persitence for fallback.
- 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.
- Frank_Sweetser_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? =) - Frank_Sweetser_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.... 
hoolioCirrostratus
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- 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 
brad_11480I 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?- dennypayne
Employee
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
