OWA has become one of the most coveted features in any Exchange installation. The ability to safely and securely access email from any web browser is hugely convenient and loved by all. However, the backend behind OWA, while normally straightforward, can present some configuration challenges for large organizations. Seemingly innocuous settings on load balancers, can have a huge impact on the operation of OWA, which as a web service is performing a bit of magic in delivering mail from multiple mailbox servers to users.
One particularly problematic issue is when using a load balancing infrastructure in front of OWA to balance users across multiple CAS servers. Under certain circumstances, load balancers can actually cause OWA sessions to be crossed so that users log in and briefly see another user’s mailbox contents for a finite but definitely tangible amount of time. While the breach may not be long, it is real and in some cases the errant user will even bee able to navigate the mailbox of the other user.
The issue arises in the way many load balancers cache content to improve performance in website loads and will be more prominent with large deployments with thousands of users rather than small deployments where caching of content will be at a lower volume. The load balancer in these cases actually caches chunks and sections of users mailboxes and the links etc, contained therein are logged in on the CAS server itself, so the load balancer, in an attempt to speed up the load time, will deliver another users content to a session without regard to the fact that the content in question needed to be authenticated to be accessed. Users will often not realize until it is too late, that they are in another users mailbox thanks to the malfunctioning load balancing infrastructure. Its easy to see how this scenario is problematic.
I haven’t seen this specific scenario addressed clearly and in plain language with most load balancers, and is for that reason that this post exists. Many load balancers will have a list of optimal settings, but its easy to see how these can be overlooked by administrators, who are used to deploying load balancing infrastructure for other static content and don’t realize the potential for these crossed sessions in OWA.
The solution, and this applies to nearly any load balancer out there, is simple. Any settings related to caching content of sessions or optimization needs to be disabled unless the load balancer you are working on has specifically stated that it has integrated settings for OWA. Ensure that no part of the OWA sessions are being cached on the device, and if you had it enabled and now need to disable, run whatever command is necessary to flush the cache after you are done.
Hope this post can help save someone hours of troubleshooting this issue as it is obscure.
Cheers.
QuickRun.net is free! Try it now.