In this blog post, I will be talking about Exchange OWA FailbackURL, and how it is being used and configured to help you recover from failures.
Contoso has a main data center in JFK with all mailboxes there. People use owa.contoso.com to access their outlook web app, and this points to JFK data center.
You have a backup or recovery data center in LON. Now everything went down in JFK, and you have somehow get the databases mounted in LON data center. You are thinking that you need to change the IP address of owa.contoso.com to point to LON data center so that users can continue working using owa.
Now JFK site is back to normal and you changed the DNS entry for owa.contoso.com to point to the JFK CAS servers.
The client need to wait for the TTL for owa.contoso.com to expire (usually set the TTL to 5 minutes), and also after the cache expires as the browser will still cache the DNS entry for another 20 minutes.
So, a loop will happen here as the browser will go to owa.contoso.com, which will go to the secondary CAS NLB in LON data center, because of the browser cache, and the secondary CAS array in LON will send an OWA redirection message “Hey… You should be using https://owa.contoso.com for best performance”. Because the mailbox is active in the primary site (JFK) now and the OWA ExternalURL for the primary CAS array (in JFK) is https://owa.contoso.com.
The user may think “ODD, I just did log in at that site! Silly computer, let me log in again.”
Microsoft has added a nice option called OWA FailbackURL and it works like this.
The second time the user logs in to owa.contoso.com, he will probably still hit the secondary CAS array servers because of their browser cache still isn’t updated. The secondary CAS array servers are intelligent enough to see this 2nd logon attempt (via a web canary) and say “OH… this user’s DNS cache is old. They don’t know we failed back to the other datacenter. Send him the FailbackURL for the primary CAS servers”.
The user is then prompted with a slightly different page with a “CONTINUE” button and it explains to them that the mailbox is in the process of being brought online in different data center. He clicks continue, which takes him to the OWA FailbackURL (for example: owa2.contoso.com). The logon attempt now works.
So the Secondary CAS array will detect if the primary CAS servers has the OWA failbackURL configured, and if it is, it will redirect the client to it to end the loop. If there is no OWA failbackURL configured, then the secondary CAS array will send an error page to the client indicating that he should close his browser and try again.
For this to work, you need to include the owa2.contoso.com (which is the OWA FailbackURL) to your CAS certificate SAN entries. You also need a DNS entry or Alias for owa2.contoso.com to point to owa.contoso.com. You can configure OWA Failbackurl using the Set-OwaVirtualDirectory