Outlook Web App 2013 Issue

0

With both real servers enabled i will immediately get logged off Outlook Web App 2013. OWA will work normally if I disable either real server

10 comments

Avatar
Barry Gleeson Official comment

This type of issue may be resolved by configuring Persistence on the Virtual Service. This will ensure requests passing through the loadmaster from the same client will be sent to the same Real Server.
However, with Exchange 2013 this should not be required,
see http://blogs.technet.com/b/exchange/archive/2014/03/05/load-balancing-in-exchange-2013.aspx

This problem may arise if the two CAS servers use different Certificates (even if they have the same name) so I would recommend checking the Serial Numbers of the Certificates on each CAS server.

Avatar
0
Derek Kiely

Sounds like a persistence issue, what persistence have you set on the VS?

Avatar
0
Carlos Campos

Persistence: None

Avatar
0
Derek Kiely

Have you used our Exchange 2013 deployment template? https://support.kemptechnologies.com/hc/en-us/articles/202000786-Microsoft-Exchange-2013-Templates - for the configuration? As a test if you enable persistence does this resolve the problem? If so then it is an exchange configuration issue.

Avatar
0
Martin.Harrow

I have exactly the same problem.  I used the Exchange 2013 Templates to setup access to two CAS servers (Decrypt/Reencrypt).  ActiveSync works with Persistence=None and Scheduling=Round Robin; but OWA does not work: after login, it starts, then goes back to the login screen, then it never works.  After many hours, I have setup the KEMP with Persistence=None and Scheduling=Fixed Weighting; I have set CAS1=Weight=1000 and CAS2=Weight=100.  OWA seems to work OK.

I am not happy, because I am not certain why it was failing before. The Certs are the same everywhere (Wildcard - is that a problem?).

I would like to find the error in the logs, but I cannot.

 

 

 

Oct 21 23:22:08 MAGDEEIPLB01 kernel: L7: ffff880020f6fa50: updating persist 0 1
Oct 21 23:22:08 MAGDEEIPLB01 kernel: L7: ffff880020f6fa50: Parse_http_header
Oct 21 23:22:08 MAGDEEIPLB01 kernel: L7: ffff880020f6fa50: Parse_http_header: finished
Oct 21 23:22:08 MAGDEEIPLB01 kernel: L7: ffff880020f6fa50: add_header Request: POST /owa/plt1.ashx
Oct 21 23:22:08 MAGDEEIPLB01 kernel: L7: ffff880020f6fa50: add add slen = 1380 state = 2
Oct 21 23:22:08 MAGDEEIPLB01 kernel: L7: ffff880020f6fa50: conn release 7
Oct 21 23:22:08 MAGDEEIPLB01 kernel: L7: ffff8801003ad990: conn release 7
Oct 21 23:22:08 MAGDEEIPLB01 kernel: L7: ffff880020f6fdd0: http_client_read
Oct 21 23:22:08 MAGDEEIPLB01 kernel: L7: ffff880020f6fdd0: Parse_http_header
Oct 21 23:22:08 MAGDEEIPLB01 kernel: L7: ffff880020f6fdd0: Parse_http_header: finished
Oct 21 23:22:08 MAGDEEIPLB01 kernel: L7: ffff880020f6fdd0: HTTP/1.1 request2: GET /owa/auth/logon.aspx
Oct 21 23:22:08 MAGDEEIPLB01 kernel: L7: ffff880020f6fdd0: staying with the current destination
Oct 21 23:22:08 MAGDEEIPLB01 kernel: L7: ffff880020f6fdd0: client_read: pass_header 1
Oct 21 23:22:08 MAGDEEIPLB01 kernel: L7: ffff880020f6fdd0: l7_mangle_header
Oct 21 23:22:08 MAGDEEIPLB01 kernel: L7: ffff880020f6fdd0: l7_mangle_(replace)header failed '/owa/auth/logon.aspx?url=https%3a%2f%2fmail13.xxx.com%2fowa%2fuserspecificresourceinjector.ashx%3flayout%3dmouse%23ver
%3d15.0.1104.5%26appcacheclient%3d1&reason=0'

 

Avatar
0
Barry Gleeson

If fixed weight resolves the issue this would definitely point to issues with the CAS Array. (However this would not be a recommended solution)

As per https://technet.microsoft.com/en-us/library/jj898588(v=exchg.150).aspx, Exchange 2013 should not require Persistence/Affinity. This means a client should be able to login in using one CAS and then send a subsequent request through a different CAS without having to login again.

"Now that session affinity isn’t required, you have more flexibility, choice, and simplicity with respect to the load balancing architecture you deploy. Load balancing without session affinity lets you increase the capacity and utilization of the load balancer, because processing isn’t used to maintain more involved affinity options such as cookie-based load balancing or Secure Sockets Layer (SSL) session ID."

With Persistence(affinity) set to none the Loadmaster will simply send requests to the next CAS array based on scheduling (e.g Round Robin) and this should work.

A simple workaround to the issue you are seeing would be to use Source IP persistence - meaning users with same IP will be sent to same CAS server and this should resolve. However as mentioned this should not be required and in order to fully address the issue you would need to investigate configuration of the CAS servers. The most common issue here is the Certs as mentioned.

Fixed weighting may not be the best solution as this will send all requests to the higher weight as long as this Real Server is available. i.e all requests to CAS1

 

 

 

Avatar
0
Martin.Harrow

Barry, thank you for the good feedback.  I agree that my work around should not be needed. But my Exchange expert tells me that CAS1 and CAS2 are identical. 

I tried Persistence=Source IP, and this did not work.  But I also had a problem with the Healthchecks, and the KEMP was putting my CAS servers offline/online very often.  I had to increase the Healthchecks timeouts.

For now, I am happy to keep Fixed weighting - because I have a small number of users of OWA/ActivSync.  Most of my users connect through another VS at L7, and will use both CAS1&2.

 

BIG PROBLEM: the Kemp logging did not really help me. It did not clearly tell me that clients were being switched from CAS1 to CAS2.  The logs also did not tell me why the HealthChecks were failing, I need to know why, in case I have a problem.

Thanks

 

 

Avatar
0
Barry Gleeson

Clients being switched from CAS1 to CAS2 is normal (unless there is persistence) so this doesn't necessarily trigger any special logs. There are L7 debugs which can be enabled under :

System Configuration-Logging Options-System Log Files-Debug Options-Enable L7 Debug Traces   
 
which I think you already have but this should indicate the Real Server Client Requests are sent to.
 
Health check failures should also be seen in these logs.
 
In your particular case, If you would like more analysis it may be best to create a Customer Support Ticket and we can help.
Avatar
0
Martin.Harrow

Barry, thanks for the further feedback.  Yes, the L7 Debug logs are good.  You make a good point: swapping between CAS servers is normal, therefore you do not report it. Nevertheless, it would be good if I could see which RS is being used in the Messages log.

For the Healthcheck, I see only the failure:

 l4d: Removing RS 172.18.144.112:443 from VS 192.168.119.111:443(DMZ-Email-Decrypt-Reencrypt) - Connection Failed - server unavailable

I do not see the reason why, or any details of which Healthcheck failed and why. That would be good.

For my case, I have a new installation. It could be that the CAS setup is not perfect. I have asked my Exchange expert, but he needs eveidence of what is wrong.

 

If need be, I will open a support ticket.

 

Martin

 

Avatar
0
jvangent100

Sorry to revive a year old post, but I have the exact same problem. Now it was suggested it was due to certificates not being the same, but they are the same.

 

I am using this with several subvss for exchange by service and Lync. Setting both ECP and OWA to fixed weighting (not changing any of the actual weighting) seems to resolve the issue.

 

Now some of you guys say, it is due to a misconfiguration, well, it's not non matching certificates. The two cas servers have been behind an ARR for about two years, so I'm dying to hear what the problem might be in this case.