I just deployed the latest 2013 iApp for Exchange 2013. We have 5 servers, and the iApp deployment went good and quick. However, we can not log into OWA or the ECP when more than one pool member is active. You get to the login page, you type your username and password and it looks like it's logging you in for a brief moment, then kicks you back to the logon page. If I go into the OWA pool, and disabled all but one of the members, you can log in and access your mailbox or ECP just fine. Anything you can think of to look at? I have a support case with F5, but sometimes people on here have ran into this before.

Hi, I have seen this before. In my case, it was because I had mismatched certificates configured on my client access servers. Confirm that all the CAS are using the same cert for IIS services, and that that cert matches the one you're choosing in the iApp configuration. Mike

each of my CAS servers have certs from our internal CA with servername.domain.com We are doing SSL offloading and our public cert for OWA, Autodiscover, etc is on the F5 only. If that was the case, why would it work with only one server active in the pool? I would think it would be the same problem regardless of how many pool members are active.

In order to know that you have an existing session, the servers need to be able to decrypt the auth cookie and for that they all need the same cert. Otherwise, they will return you the logon page. It works with a single pool member because that server has the correct cert. From http://theucguy.net/exchange-server-2013-load-balancing/: "The OWA client hands the cookie to the server with any new requests. In this case, it doesn’t matter if the new request is handled by a different CAS server, as that server is capable of decrypting the cookie with it’s private key, as all CAS servers have the same certificate. As the authentication cookie is successfully decrypted irrespective of which CAS 2013 server it hits, the user or client is not challenged to authenticate again with an FBA page."

OK, I have done that...and the same problem persists.

I assume you have reset IIS on all of your CAS? You may want to try killing all of the connections to that pool on BIG-IP as well. If that doesn't work, please let me know your F5 support case , so I can track it.

Microsoft Exchange 2013 iApp - Can't login to OWA or ECP if more than one server is active in pool

carter91_13591
Nimbostratus
Jul 04, 2014
OK, thanks.

Dell Professional Services has already confirmed CAS is configured correctly on the Exchange side. I can call MS, but that will be a pay by case, and would delay this even further until next week. All their experience deals with KEMP load balancers mostly, so the F5 piece is out of scope for them and let me us to solve.
- mikeshimkus_111
  Historic F5 Account
  Jul 07, 2014
  You'll need to continue to work through F5 support on this. Please do so until they either find a solution or escalate the case. The suggestions I've given are only based on my past experience and are no substitute for a proper investigation.
carter91_13591
Nimbostratus
Jul 07, 2014
Thanks Mike. I haven't not heard anything from F5 since Thursday. Patiently waiting.
carter91_13591
Nimbostratus
Jul 07, 2014
I got a call from a manager...but already have a case open with MS as well as a double check as you suggested. Leaving early today, thanks for your help so far.
cphillips19_137
Nimbostratus
Nov 10, 2014
Any update on this case? Did you ever end up solving your issue?
scarnes_82101
Nimbostratus
Jan 08, 2015
I would be interested in what the resolution to this was as well. We are seeing the same issue where we can only logon to OWA if one pool member is active even when the certs on CAS and LTM match.
mikeshimkus_111
Historic F5 Account
Jan 08, 2015
IIRC, the OP had to change their internal OWA URL to their CAS name while keeping the external URL the OWA FQDN. Not sure why that worked, since we've tested extensively with a single namespace for OWA and it works fine. If you run a "Get-ExchangeCertificate | fl" in PowerShell, does the cert you have assigned to IIS show up as valid?
scarnes_82101
Nimbostratus
Jan 12, 2015
Running get-ExchangeCertificate does show the cert status as valid and all of our OWA internal URLs are already are pointing to the CAS server name like https:///owa. The external URL is the OWA FQDN associated with the virtual server IP on the LTM.
carter91_13591
Nimbostratus
Jan 12, 2015
OK, somehow notifications for these were going to spam folder and just saw people have been asking what happened. Our main issue was co-existence with 2013 and 2010 at the same time. The CAS role in 2013 was not properly proxying requests back to 2010 until the URLS were changed. If you want to test using a HOSTs file before the cutover, the external URLs on 2013 must be your external name: owa.company.com and the internal URL must be the internal server host name: server1.company.com Don't change anything on 2010 yet. When you go to make 2013 your front end for all CAS requests in the environment, you must change the internal URL for the 2013 servers to be owa.company.com, and set the internal URL on the 2010 servers to be 2010servername.company.com. This always the proxy to 2010 to work. In our case, the F5 was hitting the 2013 servers, and a loop was getting created. My main problem with F5 at the time was the engineer was slow to respond to the case initially until a manager got involved. Unless you were already on the iAPP, it's a complicated mess of changing around URLS when trying got use it, and also be within co-existence with a previous version of Exchange. If you are purely a 2013 environment, it's straight forward.
Stefan_Klotz
Cumulonimbus
Feb 19, 2015
We also having the above described issue.

When we noticed that the issue is gone, when just one server is active in the pool, we tried to implement a sourceIP persistence profile with "Across Pools" enabled, as we are using a single virtual server with several logical pools (for owa, ad, rpc and so on). This seems to solve this issue, but it causes another one :(

It's not possible to logon to Outlook anymore. Removing the persistence profile let Outlook work again, but then the initial issue is there again.

Isn't there any solution or workaround available? Or at least a description, why this issue occurs?

Thank you!

Ciao Stefan :)
mikeshimkus_111
Historic F5 Account
Feb 19, 2015
The solution for the OP was to contact Microsoft and follow their instructions to change the internal URLs to match the CAS server name (instead of the external FQDN). IIRC, they were in a hybrid 2010/2013 deployment, as well.

For Exchange 2013, you don't need persistence for any service, although it shouldn't break anything. Do you certs match between CAS servers? Which version of Exchange are you running?