Exchange 2013 High-Availability Questions


  • Hi

    Was going through the following Technet article:

    Under the topic Site Resilience it says “To eliminate the WAN as a single point of failure when you need to provide site resilience for multiple datacenters that each have an active user population, you should deploy multiple DAGs, where each DAG has a majority of voters in a separate datacenter. When a WAN outage occurs, replication will be blocked until connectivity is restored. Users will have messaging service, because each DAG continues to service its local user population.

    Now in the article about DAC à

    It seems that if we have a single DAG with members in two Active data centers, configuring DAC will prevent the DAG from entering the Split-brain syndrome. It specifically says:

    In a multi-datacenter configuration, this behavior could cause split brain syndrome, a condition that occurs when all networks fail, and DAG members can't receive heartbeat signals from each other. Split brain syndrome can also occur when network connectivity is severed between datacenters. Split brain syndrome is prevented by always requiring a majority of the DAG members (and in the case of DAGs with an even number of members, the DAG's witness server) to be available and interacting for the DAG to be operational.  

    So does that means, if we have single DAG configured for multiple data centers and we enable DAC for the DAG, the recommendation of having separate DAGs is NULL/VOID……..or am I missing something very important here…Please help me understand.


    Also, Do we need name of the VIPs on the SSL Certificate in case we use Load Balancing solution (either Windows NLB or Hardware Load Balancer). For example, if we are using WebMail.ABC.Com as our name to provide access to Exchange services and our VIP is names as MIA-NLB-01.ABC.Com, do we need only WebMail.ABC.Com on the certificate (using which the clients access Exchange services) or we need MIA-NLB-01.ABC.Com on the certificate as well?


    Taranjeet Singh


    Friday, September 20, 2013 1:10 AM

All replies

  • Hi people.....please share your views on the above questions.


    Friday, September 20, 2013 2:25 PM
  • Those are really two different concepts. If you have multiple datacenters with *active* Users in each, then you would want to create multiple DAGs so that each user population could connect to their mailboxes in the event of a WAN failure between the data centers.

    On the other hand, a DAG stretched across a WAN link is vulnerable to a WAN failure and typically assumes that there is a primary and secondary datacenter that you switchover to when the primary datacenter is down.. You enable DAC mode to mitigate the split-brain problem.

    In other words, If I had active users in 2 datacenters, I would not implement a single DAG stretched across the WAN link.  

    As the the other question, the cert needs subject names for any URLs you set for client access ( OWA, AutoDiscover, EWS etc...) if its webmail.... then thats what you need. As long as webmail exists in DNS and points to the VIP, it will work.

    Twitter!: Please Note: My Posts are provided “AS IS” without warranty of any kind, either expressed or implied.

    Friday, September 20, 2013 5:51 PM
  • Thanks Andy

    That clears mud for me. but can't we get away with the single DAG stretched across two sites issue (in active/Active case) when WAN connectivity goes by ensuring the Witness is in some third site and both the sites hosting Active databases can reach then. May sound silly but just want to clarify the concept. We have 4 MBX servers in each of the two data centers. 

    Also, wanted to clarify that, if for example we have configured our Exchange 2013 servers in split-DNS topology and my single CAS Namespace (internal as well as external) is BYOD.ABC.Com. We want our users to be able to access OWA internally using a more meaningful name say (We do not offer OWA from Internet). What would be the following virtual directories be stamped with:

    1. OWA InternalURL - should it be BYOD.ABC.Com (Name of LB solution or i:e the name users will be typing in web browser)

    2. EWS InternalURL (as I understand, OWA and EWS should be same)?

    3. Powershell InternalURL

    4. Since, we are planning for single CAS Namespace (BYOD.ABC.Com), we planned to stamp this URL on all the Internal as well as External VDs on all CAS servers. Will this configuration work, if client requests comes on   


    Taranjeet Singh


    Friday, September 20, 2013 7:27 PM
  • Any ideas please......


    Friday, September 20, 2013 11:33 PM
  • What this is stating and how I have my environment implemented; is to create an Active/Active DAG, but to ensure you do not have split brain is to place your File Share Witness is in a 3rd highly connected site. My environment consists of 2 DAGs with 10 servers each, 5 per DAG in each datacenter. I deployed 5 copies of each database and have 120 databases per DAG. I maintain a primary FSW in one location that is not one of the two datacenters and an alternate witness server in another. My DAGs are enabled for DAC mode and in this design, should the circuits between Datacenter go dark, the FSW will maintain quorum and users will failover to one side of the DAG.

    To answer your questions on URLs.

    1. Should be the easiest for the end user, such as or, but if you choose to have a separate URL for internal vs. external, that is not an issue with 2013.

    2. I don't implement OWA and EWS the same, the only one that has to be the same is ECP. ECP and OWA have the same address the only difference is one is /owa and the other /ecp. If you change the ECP VD, you will be prompted to remember to change the OWA. I also split off ActiveSync on its own URL.

    3. PowerShell internal url should be the name of the server. PowerShell leveraged Kerberos for authentication and therefor it must be tied to a computer object. I haven't spent too much time looking into SPNs for Kerberos and PowerShell but I am sure there are alternate options.

    I like to use PowerShell ISE and leverage profiles there to connect to Remote PowerShell.

    Here is a good article on creating an ISE profile.

    In that profile, I add this code, which prompts me to which CAS server I would like to connect to, removing the need for a unifying URL.

      "Connect to Exchange",
            $User = Get-Credential
            $Server = Read-Host "Connect to what Exchange Server?"
            $connectpoint = "http://$Server.<domain>.com/PowerShell/"
            $ExSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri $connectpoint -credential $User 
            Import-PSSession $ExSession -AllowClobber

    4. Having the same namespace internally and externally will work. Autodiscover does most of the work regarding which VD to send them, it looks at things like if you are domain joined or not, if you’re IP is part of an AD site that is in the Site scope for that CAS server. You shouldn't have any issues.

    Friday, September 20, 2013 11:52 PM
  • Hello

    My question is for a OWA client that uses web browser to access mailbox. so the scenario is that I have my OWA virtual directory configured with InternalURL as BYOD.ABC.Com, whereas I want to give different and more meanigful URL to users like Webmail.ABC.Com. In the DNS I'll point this URL to the VIP of Exchange 2013 but, will this configuration work just by pointing it to VIP or do I need to have the some other means to get this work.

    Does the URL which users use to access webmail needs to be stamped as InternalURL on the OWA virtual directory?


    Taranjeet Singh


    Saturday, September 21, 2013 4:04 AM
  • You can just point it to the VIP and that should work. In the scenario you stated, I would create your internal URL to but give the users and that would work. Really the external OWA URL doesn't matter so long as the protocol is 443, you plan using the same method of authentication for both and the namespaces, whatever and how many there may be are included in the SSL cert. What is going to direct the users to their virtual directory such as OWA or ECP, is the contents of the trailing slash /owa or /ecp.

    The simplest solution is to create your external resolvable OWA URL on your hardware load balancer and have it do a silent redirect to the internal once you set on your Virtual Directory. I would even have it redirect all http OWA requests to 443.

    If there are plans to user separate authentication, then you would need to separate virtual directories for each OWA.

    Saturday, September 21, 2013 4:41 AM