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.

neither works, migrated or newly created accounts if I go through the F5, also, unless it is enabled by default I have not enabled any analytics profile

Ok, how did you setup Exchange? Did you leverage the deployment guide and iApp from here? https://clouddocs.f5.com/api/iapps/Microsoft-Exchange-2010-and-2013-iApp-Template.html I assume you did not try to setup SSL offload, as Exchange 2013 does not support it by default. I am guessing that there could be an issue happening with the SSL re-encryption. If you did not use an iApp, I suggest you set it up using the link provided. If you did set it up with an iApp, then I suggest trying to remove advanced profiles from the OWA Virtual server one by one to see at which point it starts working. By advanced profiles I mean NTLM, OneConnect, HTTP Compression, Web Acceleration, HTTP, and finally SSL. Once you find out which profile is causing the issue, it'll be easier to find a resolution. You should also feel free to open a support case to troubleshoot this.

Issues with Exchange 2013 owa

Michael_Koyfma1
Cirrus
Oct 03, 2013
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.
- rich1977_120837
  Nimbostratus
  Oct 03, 2013
  neither works, migrated or newly created accounts if I go through the F5, also, unless it is enabled by default I have not enabled any analytics profile
- Michael_Koyfma1
  Cirrus
  Oct 03, 2013
  Ok, how did you setup Exchange? Did you leverage the deployment guide and iApp from here? https://devcentral.f5.com/wiki/iapp.Microsoft-Exchange-2010-and-2013-iApp-Template.ashx I assume you did not try to setup SSL offload, as Exchange 2013 does not support it by default. I am guessing that there could be an issue happening with the SSL re-encryption. If you did not use an iApp, I suggest you set it up using the link provided. If you did set it up with an iApp, then I suggest trying to remove advanced profiles from the OWA Virtual server one by one to see at which point it starts working. By advanced profiles I mean NTLM, OneConnect, HTTP Compression, Web Acceleration, HTTP, and finally SSL. Once you find out which profile is causing the issue, it'll be easier to find a resolution. You should also feel free to open a support case to troubleshoot this.
- rich1977_120837
  Nimbostratus
  Oct 04, 2013
  Well, turns out the virtual server for owa was never assigned the owa pool that was created by the iapp. That shouldnt be the case correct? If I deploy an iapp it should assign the pool to the virtual server that it created for it right? Once I assigned the virtual server to the owa pool (my cas servers) everything of course works fine. Thanks for your input michael but I am curious if I will need to assign the pool to the virtual server everytime I create a deployment using an iapp because none of my virtual servers created for exch13 had a pool assign to them.
Michael_Koyfman
Cirrocumulus
Oct 03, 2013
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.
- rich1977_120837
  Nimbostratus
  Oct 03, 2013
  neither works, migrated or newly created accounts if I go through the F5, also, unless it is enabled by default I have not enabled any analytics profile
- Michael_Koyfman
  Cirrocumulus
  Oct 03, 2013
  Ok, how did you setup Exchange? Did you leverage the deployment guide and iApp from here? https://clouddocs.f5.com/api/iapps/Microsoft-Exchange-2010-and-2013-iApp-Template.html I assume you did not try to setup SSL offload, as Exchange 2013 does not support it by default. I am guessing that there could be an issue happening with the SSL re-encryption. If you did not use an iApp, I suggest you set it up using the link provided. If you did set it up with an iApp, then I suggest trying to remove advanced profiles from the OWA Virtual server one by one to see at which point it starts working. By advanced profiles I mean NTLM, OneConnect, HTTP Compression, Web Acceleration, HTTP, and finally SSL. Once you find out which profile is causing the issue, it'll be easier to find a resolution. You should also feel free to open a support case to troubleshoot this.
- rich1977_120837
  Nimbostratus
  Oct 04, 2013
  Well, turns out the virtual server for owa was never assigned the owa pool that was created by the iapp. That shouldnt be the case correct? If I deploy an iapp it should assign the pool to the virtual server that it created for it right? Once I assigned the virtual server to the owa pool (my cas servers) everything of course works fine. Thanks for your input michael but I am curious if I will need to assign the pool to the virtual server everytime I create a deployment using an iapp because none of my virtual servers created for exch13 had a pool assign to them.
Makengo_134399
Altostratus
Dec 09, 2013
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?
marco_octavian_
Nimbostratus
Jul 25, 2014
Makengo,

Do yo have an update on this issue?

Thank you,
Makengo_134399
Altostratus
Jul 25, 2014
Nothing has changed. Still having the same issue.
marco_octavian_
Nimbostratus
Jul 28, 2014
Makengo,

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.

Thank you,
ErikM
Cirrus
Oct 06, 2014
Hi

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.

Erik
Walt_Seidel_151
Nimbostratus
Nov 13, 2014
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. Walt
ErikM
Cirrus
Nov 14, 2014
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:

DNS Name=webmail.xyz.nl
DNS Name=autodiscover.xyz.nl
DNS Name=imap.xyz.nl
DNS Name=pop.xyz.nl

The self signed certificate for server SSL contains only the name of the CAS server:

DNS Name=CAS-server0944
DNS Name=CAS-server0944.xyz.nl

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:

DNS Name=webmail.xyz.nl
DNS Name=autodiscover.xyz.nl
DNS Name=imap.xyz.nl
DNS Name=pop.xyz.nl
DNS Name=CAS-server1.xyz.nl
DNS Name=CAS-server2.xyz.nl
DNS Name=CAS-server3.xyz.nl
DNS Name=CAS-server4.xyz.nl
DNS Name=CAS-server5.xyz.nl
DNS Name=CAS-server6.xyz.nl
DNS Name=CAS-server7.xyz.nl
DNS Name=CAS-server8.xyz.nl
DNS Name=CAS-server9.xyz.nl

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.
Sebastian_Mania
Nimbostratus
Aug 10, 2015
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?
- Hygor
  Nimbostratus
  Sep 09, 2015
  Hi Sebastian, i'm using ssl as my default persistence, and everything is working fine. i'm using 11.5.1 HF 7. After that i was able to login at the owa page and create messages, reply, etc. Regards
- Sebastian_Mania
  Nimbostratus
  Sep 09, 2015
  Yeah, i made the same change. Works good now. THanks
- Sebastian_Maniak
  MVP
  Sep 09, 2015
  Yeah, i made the same change. Works good now. THanks