OWA keeps redirecting back to login page

There are many questions or issues that people usually have when it comes to Client Access in relation to load balancing in your exchange organization. Coming to work this morning we were facing an issue that had a direct relation to changes that was made in our load balancer F5. Here I would like to provide some information when it comes to Client Access relations with Load Balancing.

Anytime you think about load balancing just remember that Client Access Services in Exchange 2016 ONLY authenticates and proxies to the back-end services, in other words, it doesn’t matter which front-end service you connect to, you will always establish a proxy to the mailbox server where your database copy is hosted.

For large Exchange organizations, you will usually have some sort of load balancing to distribute the network and application traffic across multiple Exchange Servers in order to manage availability and capacity.

A simple example of a load balancer will be the diagram below. In this diagram, you see that the client is making a connection to the exchange organization and that the client connection is coming to the virtual IP that is hosted in F5, and the load balancer has a pool of three Exchange Servers that are members of the pool, so the load balancer distributes the connection to a particular server.

Distribution happens in multiple different ways such as round robin, least connections, weighted round robin, and adaptive mechanisms. But the most important concept when it comes to load balancing is the concept of persistence. This ensures that the application's traffic connects to the same host throughout the entire session, which is also known as affinity.

As mentioned above in Exchange 2013 and 2016, when a user attempts to access their mailbox, the server proxy requests back to the Mailbox server actively serving the user's mailbox, which means that services such as OWA are rendered for the user on the Mailbox itself and we do not need persistence or affinity.

Load balancers can also perform health checks to check the availability of Exchange Server or a specific protocol. If for any reason one of the Exchange Servers fails the health check, it is removed from the pool for sending services to that server.

Another important topic to understand here is the differences between layer 7 and layer 4 load balancing. As we know from the good old OSI model Layer 4 is the IP layer and Layer 7 is the application. So in this case, if we are talking about layer 4 load balancing we are dealing with IP addresses and port numbers.

Layer 7, on the other hand, is dealing with the application side. The traffic, in this case, deals with information such as host names, applications and virtual directories. In a layer 4 single namespace design the health check only checks one virtual directory and in most cases, it is the OWA virtual directory. The issue with this is if that particular virtual directory health check fails, the entire server is considered as down. To completely solve this issue you can use a different namespace for each of the virtual directories which bring its own complications.

A single namespace Layer 7 load balancing is more appropriate if would like to use a single namespace and have the full ability to do a health check on each of the virtual directory services. In this model, the load balancer decrypts and inspects the application traffic and determines which virtual directory and hostname you are connecting. In this case, the load balancer can check each service and even if one is not healthy it can still check others if a connection is made to that service.

So in our case this morning, the issue was that when users would go to OWA and upon login, they would see the mailbox for a second but then would get redirected back to the login page. Digging deeper into this I figured that although we have exchange 2016, the load balance model that is configured in our F5 is persistence based (Most probably because there is an SSL Offloading set up in F5).

So when a change was made to add additional Exchange Servers to the pool, the persistence for some reason was broken and dropped resulting in the client making a connection, establishing a session and authenticating to a server, then being load balanced to another server upon the next session resulting in an endless loop of getting redirected back to the main login page. Assigning the persistence profile back to the server pool resolved the issue.

At this time I am working to see how to implement a load balancing model to not require session affinity or persistence.

I hope this simple explanation can help somebody out there figure the same issue they might be facing.

Please feel free to post your suggestions or point out if I am missing something here.

Author: Riaz Ansary - Experts Exchange Profile Page.