none
FailbackURL RRS feed

  • Question

  • Has anyone set a Failback URL for their environment? If so, can you please provide an example.
    Tuesday, April 12, 2011 8:25 PM

Answers

  • I have helped a few customers configure FailbackURL in their datacenters. The FailbackURL looks like an OWA ExternalURL, but uses a different hostname and never has its DNS entry changed as part of any kidn of datacenter switchover event.

    Let's say you had Datacenter 1 in Boston, MA, and Datacenter 2 in New York City, NY, and Boston is considered the Primary site everyone knows.

    If Boston experiences a full site-level outage, one of the steps to bring services online is to change mail.contoso.com (which should have a low TTL) to point to the same IP address used by the NYC OWA ExternalURL.

    You may run out of NYC for a few days and then the Boston site is "Failed Back To" and databases are made active over there again. You'll change mail.contoso.com to point back to Boston. There is a period of time between your change made in DNS, and how long it takes to propogate across the Internet and refresh in a users's DNS cache on their machine.

    During this time of DNS uncertainty a user may go to mail.contoso.com and still hit the NYC IP address because their DNS cache didnt update yet. When they log in they'll get the OWA redirection message "Hey... you should be using https://mail.contoso.com/owa for best performance." because the mailbox is active in the Boston site and the OWA ExternalURL on the Boston CAS servers is https://mail.contoso.com/owa.

    The user may think "Odd, I just did log in at that site! Silly computer, let me log in again."

    The second time they log into mail.contoso.com, they'll probably still hit the NYC CAS servers because their DNS cache still isn't updated. The NYC CAS servers are intelligent enough to see this 2nd logon attempt (via a web canary) and then know "Oh hey... this user's DNS cache is old. They don't know we failed back to the other datacenter. Send them to the FailbackURL!"

    The user is then prompted with a slightly different page with a "CONTINUE" button and it explains to them their mailbox is in the process of being brought online in a different datacenter. They click continue, which takes them to the FailbackURL. They log in again (a 3rd time) and this time are successfully in OWA.


    Microsoft Premier Field Engineer, Exchange
    MCSA 2000/2003, CCNA
    MCITP: Enterprise Messaging Administrator 2010
    Former Microsoft MVP, Exchange Server
    My posts are provided “AS IS” with no guarantees, no warranties, and they
    Wednesday, April 13, 2011 3:47 AM

All replies

  • Define "Failback URL".


    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."
    Tuesday, April 12, 2011 8:54 PM
  • Failbackurl for OWA  set-owavirtualdirectory.

    As described in this blog

    http://blogs.technet.com/b/exchange/archive/2010/11/22/3411576.aspx

    Wondering if anyone used this and if so, did they just point it to one CAS and how the syntax for set-owavirtualdirectory -failbackurl would look like.

     

     

    Tuesday, April 12, 2011 8:59 PM
  • I haven't used this; it's pretty new.

    My read is that the URL has to have a different hostname from the ExternalURL so that it will have the appropriate effect, and that it should have the same value as ExternalURL (or InternalURL for that matter) except that the hostname part is different.

    Note that you'll have to add the new failover hostnames as additional SANs in your certificate.


    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."
    Tuesday, April 12, 2011 10:38 PM
  • I have helped a few customers configure FailbackURL in their datacenters. The FailbackURL looks like an OWA ExternalURL, but uses a different hostname and never has its DNS entry changed as part of any kidn of datacenter switchover event.

    Let's say you had Datacenter 1 in Boston, MA, and Datacenter 2 in New York City, NY, and Boston is considered the Primary site everyone knows.

    If Boston experiences a full site-level outage, one of the steps to bring services online is to change mail.contoso.com (which should have a low TTL) to point to the same IP address used by the NYC OWA ExternalURL.

    You may run out of NYC for a few days and then the Boston site is "Failed Back To" and databases are made active over there again. You'll change mail.contoso.com to point back to Boston. There is a period of time between your change made in DNS, and how long it takes to propogate across the Internet and refresh in a users's DNS cache on their machine.

    During this time of DNS uncertainty a user may go to mail.contoso.com and still hit the NYC IP address because their DNS cache didnt update yet. When they log in they'll get the OWA redirection message "Hey... you should be using https://mail.contoso.com/owa for best performance." because the mailbox is active in the Boston site and the OWA ExternalURL on the Boston CAS servers is https://mail.contoso.com/owa.

    The user may think "Odd, I just did log in at that site! Silly computer, let me log in again."

    The second time they log into mail.contoso.com, they'll probably still hit the NYC CAS servers because their DNS cache still isn't updated. The NYC CAS servers are intelligent enough to see this 2nd logon attempt (via a web canary) and then know "Oh hey... this user's DNS cache is old. They don't know we failed back to the other datacenter. Send them to the FailbackURL!"

    The user is then prompted with a slightly different page with a "CONTINUE" button and it explains to them their mailbox is in the process of being brought online in a different datacenter. They click continue, which takes them to the FailbackURL. They log in again (a 3rd time) and this time are successfully in OWA.


    Microsoft Premier Field Engineer, Exchange
    MCSA 2000/2003, CCNA
    MCITP: Enterprise Messaging Administrator 2010
    Former Microsoft MVP, Exchange Server
    My posts are provided “AS IS” with no guarantees, no warranties, and they
    Wednesday, April 13, 2011 3:47 AM
  • Thanks so much Brian for the detailed explaination. Appreciate it.
    Wednesday, April 13, 2011 2:20 PM
  • You're very welcome.
    Microsoft Premier Field Engineer, Exchange
    MCSA 2000/2003, CCNA
    MCITP: Enterprise Messaging Administrator 2010
    Former Microsoft MVP, Exchange Server
    My posts are provided “AS IS” with no guarantees, no warranties, and confer no rights.
    Wednesday, April 13, 2011 3:04 PM
  • Brian one quick question. If the datacenters are sharing the namespace (mail.contoso.com), active\active user distribution model, is failbackurl required?
    Wednesday, April 13, 2011 5:08 PM
  • More importantly, do they share the same AD site? If they do then we don'tr treat them as different datacenters and there is no way for Exchange's AD site specific logic to work.
    Microsoft Premier Field Engineer, Exchange
    MCSA 2000/2003, CCNA
    MCITP: Enterprise Messaging Administrator 2010
    Former Microsoft MVP, Exchange Server
    My posts are provided “AS IS” with no guarantees, no warranties, and confer no rights.
    Wednesday, April 13, 2011 5:11 PM
  • They are two seperate AD sites
    Wednesday, April 13, 2011 5:48 PM
  • Hi Mombu,

    Each Internet-facing site should have a separate namespace, as defined by the externalURL values. This is regardless of where the active databases/users are located. You can either have one Internet-facing site using mail.contoso.com, in which the CAS servers in that site would proxy requests from the Internet to the other site, or you could establish a second namespace for the second site, in which case the users in that site would use a separate URL, and access the CAS servers in that site directly from the Internet. For example, mail.na.conotoso.com and mail.eu.contoso.com.

    See "Understanding Client Access Server Namespaces" for more details:

    http://technet.microsoft.com/en-us/library/dd351198.aspx

    Adam

    Friday, May 20, 2011 3:34 PM
  • To Brian, Very good explanation. Thanks a whole lot !
    Tuesday, January 10, 2012 9:17 PM