Forum Discussion
Exchange 2010 and BigIP v11.1??
I was wondering if someone had a similar setup that is working without issue so I could compare some settings and such to see if I can get this working.
Thank's
Brent
23 Replies
- brent112_11716
Nimbostratus
Yeah, the last engineer on the case gave it to me to try, it didnt fix any issues though.Thanks for looking into it.
- mikeshimkus_111Historic F5 AccountBrent,
I think I may have replicated the issue in my environment, at least the behavior seems similar. Under the properties of your combined Exchange 2010 https virtual server, can you set the fallback persistence profile to this:
EXCHANGE_2010_SP2_VS_source_address_persistence_profile
The default persistence profile should be cookie.
Let me know if that helps.
Mike - mikeshimkus_111Historic F5 AccountTo clarify, the default persistence profile should be the cookie profile created by the iApp...
- brent112_11716
Nimbostratus
When i attempt to do that I get this error. ( I am trying this on the test VS i created first as to not affect production)01070372:3: Persistence mode (Cookie) called out in rule (/Common/EXCHANGE_2010_SP2_VS_TEST.app/EXCHANGE_2010_SP2_VS_TEST_combined_vs_persist_iRule) requires a corresponding persistence profile for virtual server (/Common/EXCHANGE_2010_SP2_VS_TEST.app/EXCHANGE_2010_SP2_VS_TEST_combined_https). - mikeshimkus_111Historic F5 AccountFor that virtual the default persistence profile should be EXCHANGE_2010_SP2_VS_TEST_cookie_persistence_profile
and the fallback persistence profile should be EXCHANGE_2010_SP2_VS_TEST_source_address_persistence_profile
You shouldn't get that error unless you try to remove the cookie profile from the virtual server altogether. - brent112_11716
Nimbostratus
ah, sorry. It was too early in the morning when i read your last post. I have set the FAILBACK to source_address_persistence_profile.What do you expect this to fix, the authentication prompt issues?
Brent
- mikeshimkus_111Historic F5 AccountWhat I found in testing is that Exchange wants the EWS connection to go to the same CAS server as the RPC connection. If they connected to different servers, I had authentication problems. The source persistence profile is set to "match across services", which should send all connections from that IP to the same node (even if you're using two different pools, it'll work as long as the pool members are the same in both).
You can see which nodes you're persisting to by logging into the BIG-IP, then typing:
tmsh
ltm
show persistence persist-records all-properties - brent112_11716
Nimbostratus
This is our production environment (without the setting you told me to make and IP's changed for security) would something like this below in the persistent record cause issues? Where the users is pointed to multiple servers? (172.10.x.156 and 172.10.x.164)
172.5.x.115 1 0 Source Address Affinity EXCHANGE_2010_SP2_VS_rpc EXCHANGE_2010_SP2_VS_rpc_pool 172.10.x.156:135 63 seconds
172.5.x.115 1 0 Source Address Affinity EXCHANGE_2010_SP2_VS_combined_https EXCHANGE_2010_SP2_VS_owa_pool 172.10.x.164:443 27 seconds
172.5.x.115 1 1 Source Address Affinity EXCHANGE_2010_SP2_VS_combined_https EXCHANGE_2010_SP2_VS_owa_pool 172.10.x.164:443 32 seconds - mikeshimkus_111Historic F5 AccountCheck your inbox, I just PM'd you.
- Techgeeeg
Nimbostratus
Hi Brent,
Are you currently using Analytic profile on ur combined virtual server????? IF yes remove it and then try out the things. I dont have much to prove logically but the insert cookie persistence that is avaliable on F5 LTM I feel have a bug . Where ever it is used it seems to be causing one issue or the other.
Regards
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com
