Forum Discussion
CumulonimbusAPM + GTM issue with OWA 2013
Hi,
I am deploying Exchange 2013 with :
- LTM to load balance Exchange CAS servers
-
APM to authenticate users with:
- shibboleth as SAML IDP
- Kerberos SSO
- GTM for Datacenter load balancing
- ASM will be enabled in next step
LTM + APM are working well, but when enabling more than one VS in GTM pool (with Lb method Round Robin), the user is load balanced to both DC during the same session.
It seems that the javascript code "window.location.refresh" force a browser refresh which cause a new DNS request.
It is the second deployment with the same issue. for the first one, I defined LB method with "static Persist".
What is the best practice for this kind of deployment?
Stanislas
3 Replies
Seth_CooperEmployee
Hi,
This is common when using APM and GTM as the GTM could send the session to the wrong APM who doesn't know anything about the original session on the first APM.
Have you seen deployment guide?
https://www.f5.com/pdf/deployment-guides/f5-apm-gtm-dg.pdf
So the recommended way to "pin" the users to one APM is to do a redirect to a subdomain (or different DNS name) and then all request from GTM for that subdomain resolve to the APM intended.
It would work like this. User request app.company.com and then either with iRule or VPE redirect you would send them to dc1.app.company.com which would point to a specific APM and then all future requests should be send to this address instead of app.company.com and there is then no way for the session to be kicked to dc2.app.company.com.
Please let me know if you have any more questions.
-Seth
Stanislas_Piro2Seth,
I did not find this deployment guide. I was searching for Exchange issues. obviously, I was on the wrong way!
The problem with this solution is the user may connect next time to the dc02.app.company.com instead of app.company.com according to the browser history.
Thank you for this quick answer.
Stanislas
@Stanislas - I'm curious, was this breaking hard for you with the static persist lb method, or were you only having issues with a handful of users? With static persist you should've ran into issues with particular users whose LDNSs were being load balanced - ie coming from multiple sources. At which point you could have tried adjusting the Static Persist CIDR (32bit by default). Often the LDNSs being load balanced have the same first two or three octets - but not always. Same deal with the WIP persistence, you can specify the CIDR to be used for the persisting the LDNSs making the queries on your behalf. Topology could have been another option, though I'm not a huge fan of the geoip DB ever since F5 moved away from quova to digital envoy. DE has definitely advanced it's data over the past few years, but I still find issues here and there.
Seth is correct, using the redirect method you ensure a user can't hit the wrong APM. As you pointed out, users are bound to re-use it. At which point you'll need to build another WIP and for that redirect URL and use Global Availability as your lb method, otherwise you're right back where you started.
What did you end up going with?
