I've got the Big IP F5 virtual load balancer set up in my exchange 2013 lab getting ready for our migration in a few months and am having an issue. I've got an exchange 2007 environment set up to mimic what we have in production with multiple cas servers behind a VIP. Everything works fine. I've also got our exchange 2013 lab environment set up to run in coexistence with multiple CAS servers behind another VIP. If I log in a test account into exchange 2013 owa (through the VIP) that is an exchange 2007 mailbox, it redirects to the legacy owa (not using APM but letting exchange handle the redirection)and they can log in and get to their legacy mailbox. If I move that same users mailbox to exchange 2013 and then have them log in to owa it does nothing. Just acts like its about to load something then takes you right back to logon screen. If I open the account in outlook its fine. If I bypass the F5 and go to owa directly off one of the CAS servers then its fine, logs them right into owa mail. I've got the latest Exch 2013 template and have re-done it multiple times with different settings but nothing seems to change. My cert is valid but even not using ssl still the same thing. I'm kind of stuck here and I dont have a solid background with F5 BigIP so any help in troubleshooting this is greatly appreciated. Thank you.
Does it happen only with the migrated accounts? Or does OWA 2013 not work even with the mailbox that was originally created on Exchange 2013? Do you have analytics profile enabled in your deployment by any chance? If yes, I suggest disabling it.
If "native" Exchange 2013 mailbox works with OWA and migrated does not, I suggest opening a support case and providing HTTPwatch dumps of working and non-working logs so that they can be compared in the troubleshooting effort.
I have the same issues when I keep only one CAS on the pool it works fine but if connect a second CAS server on owa pool, owa session are being disconnected after 10s.
Does Anyone solve this?
Do yo have an update on this issue?
Nothing has changed. Still having the same issue.
Did you add persistence to see if it solved the issue? Second, did you open a case and get any feedback?
Finally, is your CAS server also the mail server (DAG)? I'm just researching the few cases (as in mine) where persistence resolves this issue or similar issues.
Is this issue resolved? I'm having the same issue. As far as i know there should be no default persistence profile on the load balancer because Exchange deals with the matter, perhaps through some kind of server side CAS synchronization? Correct me if i'm wrong.
Choosing a default persistence profile however does solve the issue.
Has this issue been resolved. I am have similar issue for internal user Iapp that I setup. However I repeated the Iapp for external users and they can login on first try. All settings are the same as far as I can tell, but it works external users and fails for internal users.
In our Exchange 2010 environment we use a SAN certificate for client side SSL and per-CAS-server self-signed certificates for server SSL. This works fine thanks to LTM persistence. Connections end up on one and the same server.
The SAN certificate for client SSL contains something like this:
The self signed certificate for server SSL contains only the name of the CAS server:
In Exchange 2013, without LTM persistence, using the same certificate structure would not work. Connections tend to end up on different CAS servers. Using per CAS server self-signed certificates will screw up encryption consistency, resulting in rebuilding connections between LTM and CAS, and thus producing re-appearing logon screens.
Using one and the same SAN certificate on LTM for client SSL, and on all CAS servers solves this. In our situation, the SAN contains the following names:
Note that the server SSL profile on the LTM does (in our case) not contain the SAN certificate. Somehow LTM and CAS servers agree on using the SAN certificate for server side encryption.
Filed an F5 SR on this on 29-th oct but no answer yet.
I am having the same issues,
I add persistence, to the VIP and it solved it. But.. it caused another issues, sometimes i cannot click on Rely, rely app, or create new message using it.
Did anyone resolve this?
I would like to 2nd Hygor's solution of enabling SSL persistence. It seems to have worked in my environment as well to resolve the symptom of OWA re-prompting users when there is more than one member in the server pool.
Hi Perry, good to hear it's working. But the fact is that for Exchange 2013 it should be working fine without any persistence:
Unlike previous versions of Exchange, Exchange 2013 no longer requires session affinity at the load balancing layer.
To understand this statement better, and see how this impacts your designs, we need to look at how CAS2013 functions. From a protocol perspective, the following will happen:
1. A client resolves the namespace to a load balanced virtual IP address.
2. The load balancer assigns the session to a CAS member in the load balanced pool.
3. CAS authenticates the request and performs a service discovery by accessing Active Directory to retrieve the following information:
Mailbox version (for this discussion, we will assume an Exchange 2013 mailbox)
Mailbox location information (e.g., database information, ExternalURL values, etc.)
4. CAS makes a decision on whether to proxy the request or redirect the request to another CAS infrastructure (within the same forest).
5. CAS queries an Active Manager instance that is responsible for the database to determine which Mailbox server is hosting the active copy.
6. CAS proxies the request to the Mailbox server hosting the active copy.
Another handy article about this is on Kemp's website: https://kemptechnologies.com/white-papers/what-know-about-exchange-2013-and-Load-Balancing/
That is why we changed from different per-CAS-server self-signed certificates (like in Exchange 2010) to one and the same SAN certificate on all CAS servers, containing the names of all CAS servers and the used URLs. This makes changing to another CAS server possible, and it solved our problem with rebuilding connections between LTM and CAS, and thus producing re-appearing logon screens.
Thanks for the response. I'm glad there is no need to enable persistence once the correct certificates are reissued.
To follow up, the solution of putting the same cert on all CAS members worked. I no longer have to use persistence.
The only question I have is whether it's necessary to put the DNS name of each individual CAS server in the Cert SAN name list?
What would happen if you just used the exchange service names:
And leave off all of these?:
When does Exchange reference the CAS server name directly instead of the typical URLS that a user references when connecting to Exchange? After reviewing documentation, I'm not certain that it's required but I would like to hear feedback from Erik and anyone else who might be reading this.