2

We are seeing an odd issue with a newly deployed Exchange 2016 in an Active-Active configuration. There are two sites, each with 2 Exchange servers. The DAG spans the 4 servers, with Active mailboxes at each site. We are using the Unbound namespace model, with the External URL being different than the Internal URL.

The issue is when a user attempts to connect to a mailbox that is hosted on the opposite site to what they are located. The connection is established, and the user is presented with the login dialog, then after logging in, the URL redirects to the External URL and the user is prompted for login again.

My initial thought was Exchange is incorrectly interpreting the connecting subnet as being outside of its subnet, so therefore external. From what I've read, Exchange is site-aware, so it should know that the other sites subnet is internal. We've checked the AD Sites and Services for any errors of misconfigurations, but the subnets are configured correctly.

nltest /server:<servername> /dsgetsite returns the correct site for each of the Exchange Servers.

So what could be causing the URL to redirect to the External one?

rawk_77
  • 21
  • 2

1 Answers1

3

I am going to be blunt here. Your design and implementation is flawed.

Why are you using two different URLs? I haven't implemented that design for many years, because it confuses the end users and can cause more problems than it resolves.

Active/Active DAG rarely works in the way that most people think it does/should specifically if you lose the link between the two sites (which is the most common scenario) then one site will be down.

As you have four servers I would switch to two DAGs, one active server in each site. The other passive server acts as the FSW. Give each site its own URL, with the same URL being used internally and externally for all services (ActiveSync, Autodiscover (Which is AD site aware), EWS, OWA).

That is a design that is proven to work, is acceptable to end users and is best practise.

Sembee
  • 2,854
  • 1
  • 7
  • 11
  • +1, as I always use same URL. It's the DNS that do the job, internally or externally to direct to the correct place. – yagmoth555 Mar 21 '17 at 13:21
  • The Site resilience scenario you mention was proposed, but we have a 3rd site acting as the fsw with reliable redundant links. The object here was to prevent fail-over to the secondary site unless absolutely necessary. At any rate, the different URLs was a requirement by the customer, and we may yet have to switch it to that scenario, but it is listed as a supported architecture – rawk_77 Mar 21 '17 at 15:55
  • Are you sure the links are redundant? Do they leave the building in two different ways using two different carriers? In a lot of locations in the world that isn't possible. External FSW is an unnecessary risk in my view. The design I have outlined would have stopped failover to the other site unless necessary. While the two URLs is listed as a supported architecture, it isn't best practise. It takes a lot to get me to go away from best practise - in fact no client has been able to provide me with a compelling reason to do so. – Sembee Mar 21 '17 at 16:10
  • Fair enough. I see your point and i don't totally disagree. The question I'm looking for help on is with the URL switching when connecting across sites. I will test using the same internal and external URL's, but would still like to know whats causing the redirect. – rawk_77 Mar 21 '17 at 16:22