Creating a two node Exchange 2013 DAG

Introduction

I’m not sure how you got sucked into reading this post, but since you’re here I might as well tell you how to make your Exchange 2013 Mailbox role deployment highly available by using a Database Availability Group and I’m going to shorten that to DAG because it’s a nightmare to type.  Let’s get rockin’.

Before we get too deep into it, let’s first make sure you’re on the right plane.  This flight will take you through configuring a DAG in Exchange 2013 with two nodes in the same site to make your Mailbox role highly available.  In a later post I will be covering how to make your Exchange 2013 Mailbox role deployment site resilient by adding additional nodes in a remote location.  If you’re still with me, buckle your seatbelt and keep your hands inside the cabin at all times.

Server Safety Check

Before we can take off, we need to do a pre-check routine on all our servers because the last thing we want is to get cruising at 38,000 users and then have it crash.  Let’s discuss the operating system requirements.

Operating System

DAGs utilize Windows Failover Clustering so you’re going to need a Windows OS that supports that and since Exchange 2013 can only be installed on Server 2012 and Server 2008 R2 SP1, we’ll focus on those.  If you’re running 2008 R2, you’ll want Enterprise or Datacenter.  If you’re running Server 2012, you can use Standard or Datacenter.  There’s nothing worse than installing Exchange only to find that you put the wrong OS on there when you go to configure the DAG.  Just in case you’re wondering, Microsoft does not support upgrading the OS once Exchange has been installed so your only option is to uninstall Exchange, install the correct OS, and then reinstall Exchange or build a new server with the correct OS.  After you’ve got the correct OS, you’ll want to install the most current updates.  Let’s talk about NICs, man!

The Network

DAGs need to replicate and clients need to connect, so it’s only natural that you’d need two NICs to create a DAG.  Microsoft supports a single NIC but it’s recommended you use two so you can separate the replication traffic from the client traffic.  You don’t want the reseeding of a database to affect your users’ experience.  Let’s talk about the two NICs real quick.  The first thing I like to do is name them appropriately.  I usually name my replication NIC REPL and my client NIC MAPI, that way there’s no confusion in this next step I take, and that’s to put them in the correct binding order.

SS5-ConfigServerNetwork

The MAPI NIC needs to be listed first.  This is how you do that.

  1. From the command prompt, type in NCPA.CPL to open up the Network Connections screen.
  2. Press the Alt key and that will display the File menu, then click on Advanced and select Advanced Settings…
  3. On the Adapters and Bindings tab, order the adapters so that MAPI is first and REPL is second.

Note:  If you’re using network teaming, ensure the MAPI team is listed first and the REPL team is listed second.

SS13-ConfigServerNetwork

Quick note about Network Teaming.  I’m a fan of it because I don’t want a NIC failure to cause a database failover.  NIC teaming is supported on client and replication networks but you have to configure each team so that only one NIC in the team is up and the other NIC is in standby, which means Active/Passive.  HP calls this Network Fault Tolerant only (NFT) and it’s a property of the team.  Not sure what other server manufacturers call it because I only work on real servers!  Kidding, calm down.

Last thing I want to point out is the IPv6 check box on each NIC.  Everywhere I go I see admins unchecking this box because they don’t “support” IPv6.  First point is, unchecking that box doesn’t truly disable IPv6.  Second point is, if you’re having issues with Exchange connectivity, chances are having the checkbox checked is not your issue.  Lastly, Microsoft does not test Exchange with that box unchecked, so technically you’re in an unsupported configuration by unchecking it.  All that was said to say, leave it alone even though you really, really want to uncheck it.  Let’s focus on the Client network NIC.

Client Network

This is the highlander of NICs because it gets it all, default gateways, DNS settings, and priority, and there can only be one!  You’ll configure this just like you would any other NIC card for a server.

Replication Network

The replication network needs to be on a different subnet than the client network or the DAG won’t see them as two separate networks, obviously.  For this post, I used 10.1.1.0/24 for my MAPI network and 192.168.1.0/24 for my replication network.  If you have a separate network for backups or administration, I would use that.  I wouldn’t create a dedicated network just for Exchange replication unless you have to.  DAG replication networks can share.  It learned how to in kindergarten.  If you want to use more than one replication network, then each replication network will need to be on different subnets as well.  There are a few things you need to do with this network.  Let’s go through that because you get to uncheck stuff, just not the IPv6 box

  1. From a command prompt, type in NCPA.CPL to open the Network Connections window
  2. Right-Click the Replication NIC and go to Properties
  3. Uncheck Client for Microsoft Networks and File and Print Sharing for Microsoft Networks
  4. Select IPv4 and click Properties
  5. Input your IP Address and Subnet mask.  Do NOT put in a Default Gateway or DNS servers.
  6. Click on Advanced…
  7. Click on the DNS tab and deselect Register this connection’s addresses in DNS
  8. Click on the WINS tab and select Disable NetBIOS over TCP/IP

Wow that was a lot of steps.  Ensure you click Ok to save all that crap!

Alright, we’ve got our servers ready for the DAG, now it’s time to install Exchange.  If you need help doing that, I’ve covered how to install Exchange on Server 2012 HERE.  Go ahead and knock that out.  I’ll wait.

Creating the DAG

Now the real fun begins!  We get to create stuff.  Let’s open up the Exchange Admin Center (EAC) and click on Servers –> database availability groups.

SS1-CreatingDAG

As you can see I already have a DAG but don’t worry, I didn’t get started without you.  I’m going to create another one cleverly named DAG02.  Click on the ‘+’ sign so we can create a new DAG.

SS2-CreatingDAG

In the new database availability group windows, You’ll give this a name, pick a witness server and give it an IP.  Let’s talk about each of those real quick.

DAG Name

This name needs to be unique in the environment because once you join the first server to the DAG, a Cluster Name Object (CNO) will be created in Active Directory with this name.  This CNO can be pre-staged, meaning you can create it manually before Exchange does.  You might want to do that in scenarios where you don’t have rights to create Computer objects in Active Directory.   At the time I’m writing this, Technet states that in Exchange 2013 RTM if you’re DAG members are running 2012 that you have to pre-stage the CNO, but my testing has proven otherwise.  Regardless, stay on the safe side and pre-stage the CNO if you’re OS is 2012.  Here is the link to a good blog by the Exchange team that covers pre-staging the CNO.  Pre-Staging CNO.  It’s for Exchange 2010, but it’s the same process for 2013.

 Witness Server

You have to pick a server to host a share for the DAG.  This share is only needed when there is an even number of nodes in the DAG, and it’s not utilized until you need it to maintain quorum.  I’ll explain that in more detail in my Nerd Knowledge section below.  Skip it if you don’t care.  If you plan to have an odd number of nodes in your DAG you have to configure it regardless because Exchange will use it to adjust the quorum configuration automatically as you add and remove nodes from your DAG.

The next question is, “Jerrid, who should I give the honor of being the witness to?”  Good question!  We’ll, if you are separating your CAS and Mailbox roles out, pick a CAS server.  In fact, if you leave the witness server blank and there is a CAS server in that site, Exchange will automatically pick it.  If you’re not separating out the roles, then you have to pick a server.  A good candidate would be a server that’s not going to be rebooted a lot but I wouldn’t have a dedicated witness server, it’s a waste of resources, so pick an existing file server or a server that’s within your area of control.  Before you decide to pick a Domain Controller, review the witness bullet points below.

  • Witness Serve must be in the same forest and not be a member of the DAG
  • Witness Server must have the Exchange Trusted Subsystem (ETS) group added to the local administrators group.  If this is a Domain Controller, it needs to be added to Domain\Administrators.  This is why you might want to not pick a domain controller.  This gives the ETS administrative rights to the entire domain, not just that server.  Granted ETS has crazy rights already, but putting the ETS in the Administrators group for the domain might make your security folks nervous.
  • Witness Server must be running Server 2012, Server 2008 R2, Server 2008, Server 2003 R2, or Server 2003.

Few more notes about the Witness server.  It does not need to be highly available, meaning don’t put it on a cluster, and a server can serve as the witness server for multiple DAGs but each DAG needs it’s own witness share.  Also, you don’t need to specify a path when creating the DAG.  Leave it blank and Exchange will create the proper folder structure.  Lastly, I’m assuming you’re installing two or more nodes in one physical site.  If you plan to put nodes in other sites, then you’ll want to pick a Witness server in the site that holds the majority of your users.

Nerd Knowledge:  I mentioned that the Witness server is only used when there is an even number of nodes and only utilized when it’s needed to maintain quorum, and those of you that are nerds like me, I wanted to explain that a little more.  Like I mentioned before, a Witness server is only used when there is an even number of nodes in the DAG, but Exchange will want to configure one so that it can automatically adjust the quorum configuration as you add and remove nodes.  For example, if you have two nodes, under Failover Cluster Manager you’ll see the quorum configuration set to Node and File Share Majority.  If you add a third node, the quorum configuration will change to Node Majority and the Witness server is not used at all.

Now to address the other statement of the Witness server only being utilized to maintain quorum.  A DAG must “have quorum” to mount databases and if it loses quorum, you’re environment will go down.  To maintain quorum there must be enough votes in the DAG and each server is a voting member.  For example, if you have a two node DAG the number of votes to stay up is 2.  That can be found by taking the number of nodes in the DAG, dividing it by 2, and then adding 1.  In a two node DAG that looks like this (2 nodes / 2) +1 = 2.  Again, that means in a two node DAG we need two votes to maintain quorum and keep our databases mounted.  I know what you’re thinking, “But, Jerrid, we only have two members in our DAG and we need two votes.  Doesn’t that mean we can’t lose a server without dismounting all of our databases?”  Fair question, baby bird, so let me feed you.  This is where the Witness server comes into play.  In a two node DAG, in normal operation, a Witness server is not used because we don’t need it.  We have our two voting members up, but if we lose one of those nodes, the surviving node will try to lock the witness server.  If it successfully locks the witness server, it becomes special and gets a second vote, which gives us our two required votes to maintain quorum and life is good.  However, if you reboot the witness server in this scenario, you’ll lose quorum and your mailboxes will dismount.  Even worse, they won’t mount again until you either “shrink” your DAG, or get both nodes back up.  That might sound confusing and I can cover that in another post because the length of this is getting out of control, but just remember that if you have one of your two DAG members down, don’t reboot your witness server or your surviving node.

Wow, that’s a lot, but I need to explain one more example to ensure we fully understand this.  Let’s assume we have six nodes in our DAG.  To maintain quorum we need four votes (6/2) + 1 = 4.  We have an even number of nodes so we need a witness server, but we won’t use it until we need it to maintain quorum.   If we lose one or two of the six nodes, we still have enough votes, so right now we don’t need the witness server.  If we lose a third node, one of the surviving nodes will try and lock the witness server.  Whoever grabs it first wins and that surviving node gets an extra vote making it 2 +1 +1 = 4.  Make sense?  I hope so, cause I lost my own attention two paragraphs ago!  Let’s move on.

DAG IP Address

This is the IP address used by the DAG.  It uses DHCP by leaving it blank or you can specify a static IP address here.

Now that you’ve put in all the information, click Ok. Finally!!

You can now see the DAG in the EAC, and if wanted to be a true nerd, you can open ADSIEDIT and go to CN=Database Availability Groups,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=<Org Name>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<Domain>,DC=<Com>.  You should see the msExchMBDatabaseAvailabilityGroup object.

SS4-CreatingDAG

You should also check the witness server to ensure the file share was created.

Adding Servers to the DAG

Now that we have an empty DAG and a witness server, we need to add servers to it.  This is done by highlighting the DAG in the EAC and clicking the Managed DAG membership.

SS5-CreatingDAG

On the manage database availability group membership screen, click the ‘+’ sign to add servers to the DAG.

SS6-CreatingDAG

Select the servers you want to add to the DAG.  You can select multiple servers here.  I’m adding two servers at the same time.  I’m skipping RED-15EXCH02 because it’s running 2008 R2 and the other two servers I’m adding are running 2012.

When you add the first Exchange server to the cluster, that server creates the CNO in Active Directory if you didn’t pre-stage it.  Microsoft has reported that if you add Exchange servers to the DAG too quickly and Active Directory does not have time to replicate, the second Exchange server might not see the CNO and then create it’s own.  This might be another reason to pre-stage the CNO before adding a node to the DAG or at least make sure you force replication after you add the first node to the DAG to replicate around the CNO.

SS7-CreatingDAG

Once the servers have been added to the DAG, you should see something like this.

SS10-CreatingDAG

Now that we’ve created our DAG, we can take a look at it by opening up the Exchange Management Shell (EMS) and running Get-DatabaseAvailabilityGroup DAG02 -Status | FL.  That should give you something like this.  You can notice a few things from this screenshot.  You can see that Compression and Encryption are enabled between DAG members in other sites if we decided to extend this DAG to another location.  Note that it’s a DAG property not a network property so that means it’s either enabled for all networks in the DAG or none of them.  Another thing worth noting is the port that the DAG replicates on, 64327.  This is helpful when there is a firewall between your Exchange servers.

SS17-CreatingDAG

Now your screenshot might look a little different than mine because I ran Set-DatabaseAvailabilityGroup DAG02 -DatacenterActivationMode DagOnly.  This prevents a split brain cluster from forming, so that makes this setting a must in all DAGs.  I highly recommend you set it too.

Lastly, you can see that our witness server is configured and what server is hosting the Primary Active Manager.

Let’s take a quick look at the Failover Cluster Manager to see what happened there.

SS14-CreatingDAG

From above screenshot, you can see that we have a cluster named after the DAG and our two servers are added as nodes.  You can also see that the cluster configuration is Node and File Share Majority.  Remember, it’s because we have an even nodes in the cluster.  If we added a third node, it would configure the cluster to use Node Majority.

Quick Tip:  If you’re worried about your cluster configuration, witness server, or your DAG settings in general, try running Set-DatabaseAvailabilityGroup DAG02 from EMS.  That’s right, no parameters.  It will make sure you didn’t do anything stupid.  I use this like Roy uses, “Have you tried turning it off and on again?”  If you don’t know who Roy is and have never heard that phrase, you need to stop reading this post, open a Netflix account, if you don’t already have one, look up “IT Crowd”, watch the “The Speech” episode on Season 3, and come back here and post about how funny it was and how much you want to thank me for telling you about it.  Sometimes I curl my hair and in the biggest Irish accent say, “Have you tried running Set-DatabaseAvailbilityGroup on the DAG again?”

One last thing I’d like to point out here are the DAG networks.  If you open up the EMS, and run Get-DatabaseAvailabilityGroupNetwork, you’ll see your DAG networks.  Remember that I have two DAGs, but you should see something similar to DAG02’s networks DAG02\MapiDagNetwork and DAG02\ReplicationDagNetwork01.  Why did it put a ’01’ at the end of the replication network and not the MAPI network?   Because MAPI is the highlander and there can only be one!  You can also see which networks are enabled for replication.  I’ve noticed that my MAPI network for DAG02 is configured for replication, but I’m going to fix that below.

SS15-CreatingDAG

In Exchange 2010, you had to configure your DAG networks manually, such as disabling replication on the MAPI network.  If you run Get-DatabaseAvailabilityGroupNetwork, you can see that Exchange 2013 auto configured it for us.  In fact, if you want to configure the DAG networks manually in Exchange 2013, you have to run Set-DatabaseAvailabilityGroup dag02 -ManualDagNetworkConfiguration $True.  I’m going to run this command to disable replication on my MAPI network because the DAG enabled it for me and I want that disabled on that network to force everything through the replication network.  This doesn’t meant that the DAG will never use the MAPI network to replicate because in an emergency situation when all replication networks are down, DAG02 will use the MAPI network if it has to so that replication continues.  You can run the following command to see which network your DAG is using for replication.  Get-MailboxDatabaseCopyStatus -Server red-15exch01 | fl name,*incoming*,*outgoing*.  Running this from both servers in our DAG will show which network the log copying is coming in on.

SS18-CreatingDAG

 

Adding Database Copies

Well done so far!  You’ve created a DAG and hopefully learned some stuff.  Now that we do have this fancy DAG, we need to use it by creating Database copies.  Let’s jump back over to the EAC and click on servers, then databases.  One quick thing here.  Am I the only one that hates it when menu items aren’t capitalized???  That drives me nuts that the menu options in the EAC are not capitalized, but I’m open to change.  We’ll see how that goes.  Ok, back on track.

Click on the database hosted by one of the member in our DAG and click on the “…” and select Add database copy.  This will “seed” the database, meaning copy over the EDB file over to the server you pick and then copy over the log files.  If you’re database is large, it could take some time depending on your bandwidth.  If you’re doing this in a lab with an empty database, it should go pretty quick.  You’ll want to do this for each database in the DAG that you want protected.

SS20-CreatingDAG

And we’re done!!!

In this post you learned how to create and get started on configuring a DAG.  I tossed in a very poor Talk Soup reference, (Don’t judge me, my wife watches it), related a DAG network to Highlander, talked way too much about the Witness Server, expressed how much I hate menu options not be capitalized, and put in a Tosh quote.  Man there was a lot in this post, but I truly hoped you learned something even if it’s never to read one of my posts again.  I hope to continue this post soon with extending your DAG to another site.  Very exciting!!

As always, I encourage your feedback and any questions you might have.

 

141 Comments

  1. Comment by Rocky:

    Great article.
    But, I’m unable to add a second node to my Exchange 2013 DAG. I setup a VMware ESXi lab for a prospect production Exchange 2013 design. There are two AD sites – 172.16.91.0/24 and 172.16.92.0/24. Currently have 1 Exch 2013 CAS and MBX in site 1 and another 2013 MBX in site 2. MBX on site 1 has two NICs – one for Mapi ( 172.16.91.5/24) and one for Replication (10.10.10.1/24). MBX on site 2 has: Mapi (172.16.92.5/24) and Replication (10.10.10.2/24). So, Mapi is on two subnets while Replication is one subnet. Of course, Replication network might change in production to two subnets. I can create the DAG, add one node but cannot add 2nd node. It doesn’t matter if I chose MBX1 or MBX2. Any ideas?

    • Jerrid Williams
      Comment by Jerrid Williams:

      Hi, Rocky. Thanks for the compliment and asking your question.
      Would you mind emailing me or posting your error message when you try to add the second node and I’d be glad to help you out.

      • Comment by Faisal Malik:

        Hi Jerrid,
        Wondering, how did you resolve Rocky’s issue? because Ive same setup and am experiencing with exact same problem.. Cheers

        • Jerrid Williams
          Comment by Jerrid Williams:

          Hey Faisal,
          Thanks for commenting. I didn’t get a chance to resolve Rocky’s issue because I never received the error message he was getting. Not knowing the error you’re getting, I would check the basic stuff. I would make sure each server has the correct DNS entries and that there are no ports blocked between the two servers. The other thing I would do is pre-stage the CNO. I mentioned in the article that Microsoft recommends this, but it worked for me in the lab. Since then, I have seen similar issues to yours and Rocky’s that were caused by not pre-staging the CNO.
          Thanks and I hope this helps. If you want to send me any error logs, I’ll gladly take a deeper look.
          Jerrid

    • Comment by Faisal Malik:

      Hi Rocky,
      Would you mind letting me know how you managed to resolve the issue with the setup below because I have exact same problem;
      But, I’m unable to add a second node to my Exchange 2013 DAG. I setup a VMware ESXi lab for a prospect production Exchange 2013 design. There are two AD sites – 172.16.91.0/24 and 172.16.92.0/24. Currently have 1 Exch 2013 CAS and MBX in site 1 and another 2013 MBX in site 2. MBX on site 1 has two NICs – one for Mapi ( 172.16.91.5/24) and one for Replication (10.10.10.1/24). MBX on site 2 has: Mapi (172.16.92.5/24) and Replication (10.10.10.2/24). So, Mapi is on two subnets while Replication is one subnet. Of course, Replication network might change in production to two subnets. I can create the DAG, add one node but cannot add 2nd node. It doesn’t matter if I chose MBX1 or MBX2. Any ideas?

  2. Comment by Jack:

    Hi, great post. Any idea when you will post about extending the DAG to another site and do you think it’s possbile to have full site resilience, failing over all roles and witness server?

    Thanks, Jack

    • Jerrid Williams
      Comment by Jerrid Williams:

      Hey Jack, thanks for commenting! It is possible to get site resiliency and I’m trying to find the time to write an article on how to extend a DAG across sites because this is where I see a lot of customers make mistakes. I just have to find the time 😉 I’ll see what I can do if things slow down during the holidays.
      Thanks again for reading and commenting!

  3. Comment by Rojee varghese:

    really great and helpful article , thank you Jerrid Williams

  4. Comment by Ahmed Al-Haffar:

    very nice article.
    (Y)

  5. Comment by Danny:

    Hi,

    I’ve read comments about a 2 node DAG not being recommended. I was wondering if there is a specific reason why? My 2013 Exchange servers are in different sites but I was trying to avoid a 3rd Exchange server. I’ve deployed numerous 2 node GeoClusters in the past and I was just wondering what the main reason is for not creating only a 2 node DAG, thanks!

  6. Comment by Danny:

    Jerrid,

    I really enjoyed reading your article. One more question. Can I install 1 Exchange server and set up the AD group and the DAG on 1 Exchange server and then add the second Exchange server in another location later?

    • Jerrid Williams
      Comment by Jerrid Williams:

      Danny, I think the reserve people have, or at least I have, in creating a stretched site DAG with only two nodes is not because it’s only two nodes, but because it splits your DAG in half. I would have the same concern with a two node stretched site DAG as I would with an eight node DAG with four nodes in one site and four nodes in the other.
      The reason is that if your WAN link is down or the DR site goes offline, you have lost half your votes and you can only sustain one more failure (like rebooting a server) in the primary site before your DAG will go completely down, and if you have DACP enabled (and you should), then it won’t come back up easily if the DR site is still down.
      The resolution to this (If you’re running Server 2008 R2), is to offset your DAG nodes so that you have more nodes in the primary site than you do the DR (4 in Prime and 1 in DR).
      In 2012, they have a feature called Dynamic Quorum that is pretty amazing that protects you against all this and evenly placing your DAG members between sites is now a viable solution. Dynamic Quorum is not an Exchange feature, but a new 2012 clustering feature so you can take advantage of it in Exchange 2010 SP3 and above. Here’s a MS blog that covers it if you’re interested.
      http://blogs.technet.com/b/aevalshah/archive/2012/08/21/windows-server-2012-failover-clustering-dynamic-quorum.aspx

      I hope this helps and thanks for your question!

  7. Comment by Mohamed:

    Hy,

    nice article.

    i have a same problem of Rocky, but with Windows 2008 R2 and Exchange 2010 SP3.
    can you help to resolve this problem, i suspect the wan latency but i have’nt the idea to chech latency on wan, the wan have 2 Mb.

    thank you

    • Jerrid Williams
      Comment by Jerrid Williams:

      Hey Mohamed,
      Thanks for posting a question!
      Unfortunately I’ve slept since then, so I can’t remember what ended up fixing his issue and I couldn’t find any emails that he sent me offline.
      Can you email me a screenshot of your error and I’ll try to help?

  8. Comment by Ed Vogels:

    Jerrid,

    Great article !

    1 note : If you want to use different folder for witness directory on witness server, the fileshare is not created immediately, but will be created when you add member servers :-)

    Ed

  9. Comment by Vishal:

    Dear, I have scenario where I have 3 node dag, when dag fail over occurred outlook disconnect and stuck at truing to connect. if I restart outlook its works fine. Do i need to create anything for session availability?
    Also I have migrated approx 10 users from exch 2010 to 2013, out of those 10, 2 users outlook keep asking for user name and password. if i remove “On fast network, connect using HTTP first, then connect using TCP/IP” option from outlook profile it work fine without prompt for user name and password. when ever autodiscover run in the backhand this option will tick marked automatically.For permanently removing this I have modify registry.

    Any suggestions-

  10. Comment by movi:

    hey,
    can you publish 2 site dag ?
    regards

  11. Comment by Jim:

    My company is currently rolling out a new Exchange 2013 environment utilizing a 3 node DAG and a separate Witness server. In this configuration, is standard Microsoft Clustering configured or is the only “cluster” the DAG itself?

    • Jerrid Williams
      Comment by Jerrid Williams:

      Hey Jim,
      You don’t have to configure the clustering services manually. When you add the Exchange server to the DAG, it will configure the cluster services for you.
      Thanks for your question
      Jerrid

  12. Comment by Ritesh:

    hey jerrid nice article,

    my company is doing a new set up with windows 2012 server std r2, we have 2 servers of same hardware config , we want a fail over cluster for dns, dhcp, adc & exchange 2013 is it possible to create a fail over for exchange 2013????

    • Jerrid Williams
      Comment by Jerrid Williams:

      Hey Ritesh, thanks for commenting and asking a question.
      First off, currently Microsoft does not support Exchange 2013 or 2010 on Windows Server 2012 R2. Check out this support matrix to verify. http://technet.microsoft.com/en-us/library/ff728623%28EXCHG.141%29.aspx
      Specifically talking about Exchange, yes, a DAG gives you a failover cluster. Exchange uses a very small part of Windows Clustering, but once you create a two node DAG, you have the ability to fail between servers at the mailbox database layer. You still need to address service availability at the client connectivity and email routing layer, but that’s a little more than what I can cover in the comments of an article.
      You really don’t need a failover cluster to make DNS, DHCP, and AD highly available. You can install DNS on both servers and have your zones Active Directory integrated. AD is inherently highly available (just have to seize roles). DHCP can be installed on both servers and configured with the same scope and configure it with the 80/20 rule. This means that you disable 80% of the scope on one server and 20% on the other. Or you can do 50/50.
      When I help customers, I always try to keep things as simple as possible. I never implement something just to do it. I see more customers experience down time from user error than anything else, and keeping a solution as simple as possible reduces the chances of human error. That’s why I suggest not introducing failover clustering unless you have to.
      I will say that I’m not a huge fan of putting Exchange on DCs, but I understand that sometimes money dictates our solutions.
      Another option you have if you have shared storage, this will complicate things, is to use a hypervisor on both physical servers. You can let the hypervisor handle the high availability piece and you won’t need a DAG. So the hypervisor will complicate things, but at the same time it will simply your Exchange and DHCP environment.
      Just my two cents.

      • Comment by Ritesh:

        hi jerrid

        thanks a lot, i re-installed server 2012 std(& not server 2012 r2), and created 2 virtual machines on both the physical servers, for better understanding ill name them as primary & secondary. & virtual machines as VM.
        so on Primary VM1 i installed Dc& Dns, secondary VM1 i installed my ADC ( additional domain controller) i skipped installing “DHCP” as per some it is not a good practice to install dhcp server on VM.
        On primary & secondary VM2 i have installed exchange server 2013, as i want to replicate my exchange server so that it is highly available to all.
        in case my primary goes down my secondary should automatically take over my exchange server roles.

  13. Comment by Jose:

    Really great and helpful article ,explained it in a most understandable way…
    Thank you Jerrid Williams….

    One question, if i want to add 5 nodes in DAG, no need to configure witness server, right? Then how the failover will happen if more than 2 or 3 servers goes down.

    • Jerrid Williams
      Comment by Jerrid Williams:

      Hey, Jose. Thanks for the question and comment.
      When you configure a DAG, regardless of the node count, you’ll still need a witness server for the file share witness (FSW) because the DAG will automatically adjust the quorum type when you add/remove nodes. But, you are correct, in a 5 node DAG, you will not use the FSW to maintain quorum. If we do the math 5/2 + 1 = it comes to 3.5. Since we can’t have half a node, we need 3 voting members to maintain quorum. On Windows Server 2008 clustering, that means we can lose 2 nodes and still be ok, but if we lose a third, we’re in trouble. If we’re running Server 2012, they have a new cluster feature called dynamic quorum which allows you to maintain quorum as long as you have enough votes to maintain quorum at the time of a node failure. This means you can take a 5 node DAG and experience a series of failures that bring you down to a single node and still be ok as long as each failure leaves you with enough voting members. I know I just did a terrible job of explaining dynamic quorum…lol So here’s a link to a post that does a much better job. http://blogs.technet.com/b/aevalshah/archive/2012/08/21/windows-server-2012-failover-clustering-dynamic-quorum.aspx
      I hope this helps.

  14. Comment by Mohamed gamal:

    waw amazing article. thank you very much.

  15. Comment by Ritesh:

    With your kind help we were able to deploy exchange 2013, so i would like to thank you for the same as going through your busy schedule you could remove time and help us with the same.

    but we are facing a new problem as after adding multiple clients to the exchange server, clients are unable to connect to the server, it gives us the following error

    ” the connection to the microsoft exchange is unavailable. Outlook must be online or connected to complete the action.”

    Though owa we can connect to all the clients but when we try to connect the clients outlook it give the above error when it tries to logon to the sever.

  16. Comment by mohamed:

    Thank you very much for this nice article.
    I have one doubt. If my DAG member is in a remote site, or in a different VLAN, how can I configure the replication network?
    Regards,

    • Jerrid Williams
      Comment by Jerrid Williams:

      Hello, Mohamed.
      You would have two networks per VLAN, a replication and a client network. Then you would configure the DAG networks to combine all the replication subnets under one DAG network and all the client subnets under another DAG network. With that said, I recently attended the Microsoft Exchange Conference, and Microsoft is now recommending combining replication and client networks on the same NIC under some circumstances. For example, if you’re on a 10GB network, it doesn’t make much sense to use a 10GB NIC for replication and a 10GB NIC for client connectivity because your chances of maxing out a 10GB NIC with replication and client connectivity are slim. Microsoft’s point of view, and mine as well, is to keep your design as simple as possible. In the case of replication and client DAG networks, one NIC is easier than two when you can achieve it.
      I hope this helps and thanks for the question.
      Jerrid

  17. Comment by Bikram:

    The article is Great…..

    But you replying every comment… is really SUPER…. just this small jester… has made me your FAN….

    People write blogs and never answer the comments… (Including me… sorry for that)… but you sir… have set an example to all…

    Hats off to you… and Kudos to your efforts…. no mater what… just keep up the good work…

    In future… I may not promote myself… but defiantly your will be preferred… Didnt find a subscribe or follow link… would love to do that…

    really happy to find this find…..

    Take Care….

    Thanks a zillion…..
    Bikram

    • Jerrid Williams
      Comment by Jerrid Williams:

      Hey Bikram,
      Thanks so much for the compliments. Greatly appreciated and thanks for visiting the site. I keep saying this, but I need to post more and if I do, I’ll definitely look at adding a subscribe or follow link. Thanks for the suggestion.

      Jerrid

  18. Comment by GQure:

    Hi Jerrid Williams,

    Great article indeed. However i have a question. I am also trying to setup a two node DAG for Exchange 2013. Do we need two NICK cards for each node? you mentioned only two nick cards (MAPI & REPL) for one of the nodes, how about the other node? it doesn’t require two nick cards. Also would like to how to configure activation preference on the databases. Please clarify…

    Thanks,
    GQure

    • Jerrid Williams
      Comment by Jerrid Williams:

      OMG!! I just typed a novel which was of course an amazing response to your question and it deleted it…lol This won’t be as good but I’ll still answer your question.
      First off, you’ll need two NICs on each server. With that said, Microsoft is learning more about their own product from their O365 deployment and as they learn, they update their guidance. They are now suggesting to use one network IF it makes sense. For example, if you are on a 10GB network, it is ok to have your replication and MAPI traffic sharing a NIC. The plus to only having one NIC is it simplifies the deployment. There are a few things that I see customers mess up a lot on and DAG networking is definitely one of them. Another example of when it might make sense to use a single NIC is virtualization. If you create two virtual NICs but they are sharing the same physical port, then it doesn’t make sense to add complexity just to satisfy Microsoft’s recommendation, so stick with one NIC and keep your deployment simple.
      So, to answer your question, use two NICs unless it makes sense to use a single NIC (10GB network and virtualization when sharing the same physical NIC).
      Now for activation preference. Microsoft does a 10 point inspection on all possible database copies when it is trying to figure out where to mount a failed databases and this includes the activation preference, but don’t expect the databases to end up exactly where you want them to during a failure. Here’s a really good article that explains Exchange 2013 (and 2010) best copy selection. http://technet.microsoft.com/en-us/library/dd776123(v=exchg.150).aspx
      One benefit of activation preference is redistributing databases after maintenance. After you’re done updating the last node in your DAG, you will need to redistribute the databases back to their preferred host. You can do that with a script in the Scripts folder called RedistributeActiveDatabases.ps1 with the BalanceDbsByActivationPreference option. This will automatically place the databases back to their preferred host for you.
      Now, I feel like I’ve typed a novel and haven’t answered your question yet. In a two node DAG or a DAG with only two copies of a database in the primary site, it’s pretty easy to determine the preference because there is only one other copy to mount. In a two node DAG specifically, I tend to keep my active copies of the odd numbered databases (DB01, DB03, DB05) on node 1 and my active copies of the even numbered databases (DB02, DB04, DB06) on node 2. If you are doing three and four copies, I suggest taking the easy road and using Ross Smith’s Exchange 2013 Server Role Requirements Calculator. It will tell you where to place your databases and you can use that to help you determine your preference order. Here is a link to the blog where Ross talks about it. http://blogs.technet.com/b/exchange/archive/2013/05/14/released-exchange-2013-server-role-requirements-calculator.aspx
      I hope this helps and let me know if you have any more questions, and thanks for commenting and your questions.

  19. Comment by jamshed:

    Hi,
    I am New with Exchange and Exchange DAG.
    >>”Witness Serve must be in the same forest and not be a member of the DAG”

    Describing my environment:

    I have installed 2 Exchange 2013 server in in two VMs. Another one VM as Witness Server. All are windows 2012 running and Forest Functionality 2008 configured when installed the OS.

    both Exchange Server configured as DNS and Active Directory.And Witness Server only deployed by Win 2012 with default configuration.

    My question is should I make the “Witness Server” as DNS member of the two DNS servers (two exchange servers)??

    I am not understanding when to write “Witness Server Name” in the “New Database Availability Group” what will be name??Because here need full FQDN .

    Please me out here.

    • Jerrid Williams
      Comment by Jerrid Williams:

      Hello, Jamshed, and thanks for your question.
      Let me make sure I have your question correct. You want to know if you should make your File Share Witness Server (FSW), that is a standalone DNS server too? If that’s the question, then no, I would not. You already have two domain controllers with DNS (Zones should be active directory integrated) installed, so you have your redundancy there with AD replication. I wouldn’t add DNS to your FSW server.

      As for your FSW question regarding the naming, you put the FQDN of the FSW server on the DAG properties and it will setup the FSW for you as long as Exchange Trusted Subsystems group is in the local administrators group of the intended FSW server.
      I hope this helps.
      Thanks, Jerrid

  20. Comment by James:

    Hi Jerrid. Can you tell me what to do next. I would like a single name space for the exchange 2013
    cluster that my clients can connect to. I did this in a 2 node exchange 2010 cluster by pointing my clients to an alias that pointed to the DAG IP. So if a server went down or a failover happened the clients would always remain connected to the common namespace. I also configured auto discover so clients would connect to the DAG alias and not the individual server names. I have been told this is much easier and supported in 2013 but can not find any articles.
    Cheers

    • Jerrid Williams
      Comment by Jerrid Williams:

      He James, thanks for your question.
      With a two node DAG with both nodes being in the same site, you would configured 2013 the exact same way you did 2010. With pointing everyone to the DAG cluster IP, it doesn’t provide load balancing, but it does provide high availability. If you wanted true HA and load balancing, you’d need to invest in a load balancer because they are service aware and pointing to the DAG IP is not. This would be true for 2010 and 2013.
      So to make sure I’m being clear and answering your question, you would take the following names and point them to an Alias (for example, mail.company.com) that resolves to the DAG IP or the Virtual IP of a load balancer.
      Outlook Web App
      Exchange Control Panel
      ActiveSync
      Exchange Web Services
      Autodiscover URI
      Autodiscover.company.com
      Offline Address Book
      POP/IMAP
      Outlook Anywhere

      I think what you might be hearing about the single namespace being easier with 2013 is the cross site configurations. You can go to one namespace with 2013 and it will just take care of everything for you. For example, in 2010 days, if you had a cross-site DAG that was actively serving mailboxes out of each site, you’d have to configure separate name spaces for each site or you could get caught in some nasty redirect loops. With 2013, that is no longer the case. You can have a single namespace for both datacenters and 2013 will just figure it out. With this new capability, you can start using things like GEO-DNS and automatic site failover (requires a third site for your FSW).

      But, like I said before, when just looking at a DAG in the same site, it’s handled the same way as 2010. Just get a single IP to point to (DAG IP or VIP) and change all your URLs (OWA, ECP, AS, etc..) to point to that name. There is some certificate work that needs to be done in there, obviously, but it sounds like you already understand that part.

      Two things I want to mention here regarding pointing your names all at the DAG IP and not using a load balancer. Fist is that I would not use the method of pointing to the DAG IP if you have a cross-site DAG. That’s because the cluster could switch to the DR site IP and bring everyone offline. Second, Microsoft is introducing the feature of creating a DAG without a Cluster Administrative Access Point (AAP). It means that in this setup, you’d have no DAG IP to point to. They introduced this to simplify the DAG configuration, I guess because people were making so many mistakes with configure the DAG with all the right IPs because you need a DAG IP for every subnet you have a DAG node on and most people were just putting one and forgetting their DR site IP. Anyways, keep that in mind. If you want to read more, check out this blog post. http://blogs.technet.com/b/scottschnoll/archive/2014/02/25/database-availability-groups-and-windows-server-2012-r2.aspx

      I hope this helps and thanks again for your question.

  21. Comment by Jumrat:

    why two node DAG running EMS>Exchange Management Shell (EMS) and running Get-DatabaseAvailabilityGroup DAG02 -Status | FL.

    stopedmailboxservers: {}
    StartedmailboxServers: ()

    how do force Set startmailbox server?.
    Start-DatabaseAvailabilityGroup -Identity DAG1 -MailboxServer MBX2?

    • Jerrid Williams
      Comment by Jerrid Williams:

      Jumrat,
      Thanks for your question. I hope I understand it correctly, but you want to get the servers in the startedmailboxservers, right? To do that, you have to change your DatacenterActivationMode to DagOnly. You do that by running this command “Set-DatabaseAvailabilityGroup -DatacenterActivationMode DagOnly” This enables DACP and helps prevent split brain and should show both of your servers in the StartedMailboxServers.
      Please let me know if this does not answer your question.
      Jerrid

  22. Comment by Ian:

    Question about the MAPI Nic. So I assume if we didnt have DAG before and our mailbox server had a LAN nic for regular client access, that the MAPI nic will be the same thing. The terminology is interchangable. So All I would need to do is add the REPLICATION NIC. The reason I ask is because in this technet template

    http://technet.microsoft.com/en-us/library/ff622321(v=exchg.141).aspx

    It references the MAPI nic and tells you do delete the DNS servers from it and also do not register with DNS. That seems like it would break something if that was already my primary NIC connection to the data network.

    thanks a lot

    • Jerrid Williams
      Comment by Jerrid Williams:

      Hey Ian, thanks for the question. Yes, all you’d need to do is add a replication NIC and configure it just as it says in the article you’re referencing. I looked through the article and didn’t see where it said to configure the MAPI NIC like that, but I could be missing it. I see a MAPI and REPL section and they both seem to be correct.
      Either way, your thinking is correct.
      One thing about the replication NIC. If you’re on a 10GB network, just use one NIC for both replication and MAPI, and if you’re using virtualization and both NICs would be traveling across the same physical connections, use one NIC. This is recommended by Microsoft now to keep designs simple.
      Thanks and I hope this helped.

      • Comment by Ian:

        Thanks for your followup. Yes we are all virtual and using Cisco UCS blades with 10GB uplinks but the second DAG member we want to setup is over a 100mbps VPN connection so I think I should still have two separate nics dont you think?

        • Jerrid Williams
          Comment by Jerrid Williams:

          Hey Ian,
          If you have a 100mbps VPN link, separating the traffic into two NICs won’t help you since both NICs will be sharing the same pipe. This is your DR site, correct?
          It’s hard to give 100% recommendations with out really looking at your environment, but if you have a 10GB network and you’re sharing the same bandwidth to your DR site, I would really think about going single NIC. It’s a lot simpler and you shouldn’t see any impact to your end users.
          Thanks
          Jerrid

  23. Comment by Ryan:

    Hi, Jerrid
    GREAT GREAT article you have, it helps me a lot.

    So I’m planning to setup a 2 nodes DAG in 2 different sites. I have a question that bother me before deploying DAG.
    About the replication itself, how does it work?in term of how much bandwidth will it utilize? and is it gonna be a real time replication or would it be possible to put it on a schedule

    • Jerrid Williams
      Comment by Jerrid Williams:

      Hey Ryan,
      I would lean on the Capacity Planning tool written by Ross Smith. It will help you determine the bandwidth needed. Basically, every transaction log created in the primary site will be replicated to your remote site. In addition, the passive copy builds it’s database indexes from the active copy, so you’ll see traffic from that as well. The tool helps you determine that. As far as replication, it’s not real time and to my knowledge, there is no supported way to put that replication on a schedule. You can deploy a lagged copy in DR, but the logs will still replicate to the remote exchange server, the lagged copy just won’t commit the changes until it reaches the threshold.

      Here’s a link to the capacity planning tool I mentioned http://gallery.technet.microsoft.com/Exchange-2013-Server-Role-f8a61780

  24. Comment by Tom:

    You covered a number of things nicely, but NOT ONCE did you mention THE MOST BASIC ITEM that comes to mind: Do the 2 nodes of the DAG necessarily need to be the exact same hardware? We want a primary node that carries the load most often to be “beefier” but the secondary node, which rarely would do much, except in event of failover, we want to be “not as beefy.” This is a critical item that should be addressed, then your article will be complete. Thanks.

    • Jerrid Williams
      Comment by Jerrid Williams:

      Hi Tom, thanks for your comment and question.
      One suggestion I have is to not do a “beefier” and “not as beefy” design. I would recommend getting two servers that can handle the load and build your DAG with them and making them share the load. This way you don’t have one sitting there collecting dust and you’ll be utilizing your investment. It all comes back to design. If your design calls for x number of processors and x amount of RAM, then your “not as beefy” server will need to meet those requirements if you do not want to affect your end users during a failure. This suggests that your “beefier” server would have more processors and RAM than your design requires, therefore, you wouldn’t be using your budge effectively.
      I would design the solution correctly and purchase two servers that meet the design requirements and deploy a DAG with the databases distributed between them. If you do that, then the servers will have the same resources and probably be identical since you’ve purchased them from the same manufacture. With that said, there is no requirement that the hardware match exactly. Back in the 2003 days when you had Microsoft Clustering heavily involved, that was a requirement or strongly recommended. Not the case now, but when talking about a DAG, it usually works out that they are exactly the same because of the design unless you’re trying to repurpose old/used hardware. That is fine, but if Email is a critical application, enough so that you’re building a DAG to protect it, you could probably justify the costs of new equipment.

      To address your concern, this is a how-to article and not a design article, so that’s why the type of servers used for the design are not discussed.

      I appreciate you helping me better my article and I’d like to return the favor and help you better your comments. Your comment comes off as arrogant and condescending. It’s hard to interpret one’s true intent from just words, but for future reference, when asking for free help on a free website, or offering suggestions on improvements, I would recommend that you attempt to ask your question in a way that doesn’t seem so arrogant and condescending even if that’s not your intentions. That way you’re more likely to get the help you’re looking for.
      Thanks for your question and I hoped it helped.

      Jerrid

  25. Comment by Michal Cardella:

    Hi Jerrid

    My Exchange Admin (who is no longer with our company) just setup an Exchange 2013 DAG with 3 Exchange Nodes in the DAG using separate 10GB NICS for MAPI and Replication. Basically, we have 3 Mailbox servers which are virtual machines running on 2 x hyper-v host servers. The mistake he made was – He setup one mailbox server on Hyper-v1 and 2 mailbox servers on hyper-v2. Since this Exchange DAG has an odd number of members we are not using a file-witness server to maintain quorom. Which leads me to my major problem. Due to hyper-v2 physical server rebooting today, we lost 2 out three votes or 2 out of 3 DAG members which dismounted our Exchange Databases and brought the DAG down. Basically, we have 2 out of three DAG members on the same Hyper-v physical host server. My question is – can we simply add in a File witness server to the 3 node current DAG and then remove the 3rd mailbox member which will leave us with a 2-node Exchange DAG and a File witness server? Keep in mind, I will have one DAG member on each Hyper-v Server and the File witness server on another physical server (non domain controller member server). I am not sure in what order this should be done. Should I first add the file witness server to the 3-node dag? Or should I first remove the 3 mailbox server (DAG node) and then add the file witness server? Unfortunately, I have over 1000 mailboxes that are active in this DAG so I want to make sure that I do this in the correct order and keep the DAG and databases up and running during the process. Any advice would be greatly appreciated. Thanks in advance.

    • Jerrid Williams
      Comment by Jerrid Williams:

      Hey Michal, thanks for the question.
      When you move/remove nodes from a DAG, the DAG will automatically switch the cluster type for you. Right now, as you’ve seen, your cluster is Node Majority. When you remove the third node and you have an even number, the DAG will change the cluster type for you to Node and File Share Majority. So, to directly answer your question, I would do this.
      1. Determine who your DAG thinks should be your FSW. This is the server it will use once you remove the third node. You can get that by typing this command Get-DatabaseAvailabilityGroup | fl *witness*
      2. If the WitnessServer is not the physical server you’ve designated, then you can run the Set-DatabaseAvailabilityGroup
      -WitnessServer (You shouldn’t have to specify the directory path)
      3. Remove all database copies from the node you’re removing and if it’s a CAS server, remove it from your load balancer. Also make sure it’s not the source for any send connectors.
      4. Remove the third node.
      5. Check Failover Cluster Manager and you should see your cluster configured as Node and File Share Majority. If for some reason the cluster is not set correctly, run this command with no parameters. Set-DatabaseAvailabilityGroup That will make exchange do some basic checking and fix anything that might be wrong.
      6. Uninstall Exchange from third node

      This is something that you can do with no downtime, but I would still strongly recommend doing this after hours just to be safe.

      I hope this helps and please let me know if you have any more questions.

      Jerrid

  26. Comment by Mchal Cardella:

    Hi Jerrid

    Thank you very much for the in-depth instructions. We are going to give this a shot after hours and see how it works out and will keep you posted. Thanks again!

  27. Comment by Mchal Cardella:

    Hi Jerrid

    Your advice worked perfectly. I had one minor error that was occurring because the Exchange uninstaller kept failing. ( this was after we successfully removing MBX03 from the DAG as you instructed). So we basically had to use ADSIEDIT to remove the mailbox server from AD. All is good now and the job was a success but I am wondering if Exchange typically fails to uninstall and you always have to use ADSIEDIT. Thank you very much for your guidance on this – I really appreciated your expert help.

    • Jerrid Williams
      Comment by Jerrid Williams:

      That’s awesome! Glad I could help.
      I see a lot of issues with removing exchange servers, but they are usually issues that can be resolved without the use of ADSIEDIT and I eventually get them to gracefully uninstall. If you’ve already removed it with ADSIEDIT and you don’t experience any issues, then you should be good.
      Thanks for getting back with me on how it went and enjoy your weekend!

      Jerrid

  28. Comment by Wayne Whittle:

    We have Exchange 2010 installed at two sites and have set up a 2-Node DAG, with a FSW in the primary site, which has been working fine for a long time now. I haven’t kept up to scratch with Exchange recently but is there any way to prevent the mailbox database dismounting at the secondary site when the WAN link goes down ?

    • Jerrid Williams
      Comment by Jerrid Williams:

      Wayne,
      Thanks for your question. It sounds like you’re running Active/Active configuration with clients being served in both sites with a single DAG. Unfortunately, there is no way to keep databases mounted in both datacenters when the WAN link goes down. A cluster must have quorum at all times to mount databases. When you lose the WAN link, the site that does NOT have the FSW does not have enough votes to maintain quorum, which in your design is 2. You’d either need to get a more reliable WAN link or design around it. To design around it, you’d need two DAGs in an Active/Passive configuration with each DAG hosting active databases for the site where they FSW is located. It would provide DR capabilities and prevent the WAN link from causing outages to the client, however, it does double your server count.
      I hope this helps
      Thanks,
      Jerrid

  29. Comment by Sukhjinder:

    Thanks Jerrid, Nicely written article, well explained. I know it is not good practice to use Domain Controller as FSW. But I am in situation where I only have DC which I can use as FSW. Is there any major risk if I use DC as FSW.

    Thanks,
    Sukhjinder

    • Jerrid Williams
      Comment by Jerrid Williams:

      Hey Sukhjinder,
      Thanks for the question. It’s ok to use a DC. The catch there is that you have to add the Exchange Trusted Subsystem to the Domain\Administrators group in AD. This is seen as a security risk, but it’s very common in smaller deployments.
      Thanks and I hope this helps.
      Jerrid

  30. Comment by Daro:

    Could you describe how to configure alternate file share witness and how to test the configuration?

    • Jerrid Williams
      Comment by Jerrid Williams:

      Hey Daro,
      Thanks for your question. There’s not much to the FSW. There are some basic requirements which I covered in the article. When you create the DAG and add members, exchange configures the FSW for you as long as the Exchange Trusted Subsystem is in the FSW’s administrators group.
      The best way to test this is to run Set-DatabaseAvailabilityGroup (no switches). This checks the FSW and will warn you if something is wrong. The true way to test this is to put your DAG in a situation where the FSW is needed and make sure everything works. The time to test this is before it goes into production, so test and then test some more.
      Thanks and I hope this helps.
      Jerrid

  31. Comment by Phil:

    Hi Jerrid,

    Quick question. I already have a 2-node 2012 R2 failover cluster using shared storage. Does it make sense to deploy a DAG in this case since both Exchange nodes would be sharing the same CSV (with 2 separate databases) and would be on the same cluster (although I’d deploy with anti-affinity so they’d always be on different nodes). Is that overkill? Is it sufficient that one CAS and one MBX virtual server be on the failover cluster and let the underlying cluster logic keep them available? I just don’t want to deploy a lot of stuff (2 of everything, actually) that I might only be getting a couple seconds faster switchover, but with the same single point of storage failure (albeit one that has a very low probability of failure). Thanks.

    • Jerrid Williams
      Comment by Jerrid Williams:

      Hey Phil,
      This is a great question and one I work with customers with all the time. It’s a very long discussion most of the time, but I’ll do my best to not get wordy. I’m assuming that you’ve determined that you want/need to use virtualization for Exchange, because that’s usually encompassed in this discussion as well. The one thing I will say about that is, if the company is mature enough to manage exchange on a virtual platform and the benefits outweigh the added complexity, then virtualization makes sense. We can talk about that more later if you’d like, but to get to your original question, you are correct, a DAG is still providing benefits, but is it enough to add on the complexity of a DAG? I know a single site DAG is not that complex, but it is more complex than standalone servers and more complexity is always more risk.
      Now, what is a DAG providing you in your scenario? A faster failover, but like you figured out, it might not be that much faster. If a host fails, does your company need a sub 30 second failover (DAG), or can it handle a couple minute outage while the other host fires up the exchange server? In most smaller companies, a few minute outage is completely acceptable.
      The other thing that a DAG is providing is the ability to update one node without bringing down production. This feature provides piece of mind in that if the windows/exchange updates fail, your databases stay mounted on the other node and your users don’t notice. In a virtual world without a DAG, if updates go bad, you’re repairing/restoring a server while email is down, and that just sucks. A lot of customers just say, “That’s ok, I’ll snapshot it before the update.” That might work, but unfortunately, Microsoft does not support restoring an Exchange server from a snapshot. With that said, most small customers in a pre-DAG world were at that risk already and probably survived just fine.
      Another argument for a DAG is you have multiple copies of your databases, which is always good, but like you said in your case, it’s all on the same CSV, so how much of a benefit is that? If you lose your storage, you could have a million copies and you’ll lose them all because it’s shared storage.
      Here’s what I usually recommend. For small customers facing this virtualization question, I usually try to persuade them away from a DAG simply due to the complexity and cost, and rely on virtualization for high availability and good old backup solutions for recoverability. Some people may disagree, but I see more customers bring themselves down out of ignorance or lack of operational maturity, and a DAG only makes those situations worse.
      My main goal is to keep it simple and if you have to add complexity, make sure the benefits outweigh the risks.
      I hope this helps, but please keep in mind that every situation is different and these are just my thoughts based of what little I know about your environment and my experiences.

      One side comment, you mentioned having one CAS and MBX server on one host and that suggests you’re separating out the roles. I would highly recommend combining the two roles. Less servers to deal with. It’ll lower your costs and risks while raising your high availability.

      Thanks again and please let me know if you have any more questions.

      Jerrid

  32. Comment by Martin:

    Hi Jerrid,

    Thank you very much for your informative post.

    I have one question. I have a 5 member dag. 2 members are at Production site (this is also where our witness server and share is on a CAS server), the other 3 are at DR site. I want to simulate a fail-over by “switching” all exchange servers off at Production site, I am not able to send emails out of my organisation. However receiving is fine. Does this mean i have to create another witness share residing at DR or should recreate the DAG? If i have to move it? How can i do it?

    • Jerrid Williams
      Comment by Jerrid Williams:

      Hey Martin,
      Thanks for your question.
      One quick note, you have an odd number of DAG members so your FSW is not used, however, you want this in your main site because the DAG will configure the FSW for you as you add/remove DAG members. Second, I would rebalance your DAG members. You want the higher number in your primary site. If you experience a WAN failure in your current layout, your primary site will lose exchange functionality. If you are not receiving email when your primary site is down, there are a few areas that could cause it, but I would start looking at send connectors. You’ll need a send connector that your DR site can send out of. If that’s setup, I would check the queues to see where and why the email is getting hung up.
      I haven’t seen your environment or your technical/business reasons for the messaging system, but I would bet you’d be better off putting three servers in your primary site and two servers in your DR site. That way a WAN link won’t bring down your primary location. I would fix that first, and then work on email routing.
      I hope this helps.

  33. Comment by Brian Parker:

    Hi,

    I am currently trying to set up a 2 node DAG with a non-exchange FSW. I must be missing something, because every time I start the 2nd exchange server, it starts spewing forth all kinds of spam. I have just completed a comprehensive malware scan and clean of my entire network and am confident I have removed all malware. I just can’t seem to get this to stop long enough to configure the 2nd server to complete the DAG.

    Can you give me some insight as to what I may be missing? I would appreciate any help you can give me. I have searched google for weeks and can’t find anything.

    • Jerrid Williams
      Comment by Jerrid Williams:

      Hey Brian,
      Sorry for the late reply and thanks for your question. That’s odd. If the 2nd server is generating it, then I would just rebuild it from scratch if possible. Especially if you’ve tried cleaning it. I would also make sure it’s not opened to the internet on port 25 yet until you’re ready to send/receive email externally and make sure you’re routing inbound email through your spam solution. I have seen new email servers opened directly to the internet and unintentionally bypassing the spam solution and spammers attack them pretty fast.
      I hope this helps, but basically, the email is being generated from somewhere. If it’s the actual server, rebuild that sucker. If it’s coming from external, then block the leak and get it rerouted through your spam solution.

  34. Comment by Aabed:

    Hi Jerrid,

    nice and informative! was really helpful! thanks for sharing.

    Aabed

  35. Comment by Tom Gilmore:

    Great Article. I am trying to figure out an issue where the Main Server goes down and Outlook clients can’t connect. It is 3 node Dag, 2 in one site, 1 in second. If the Database fails over there is no issue, but if the main server is offline OWA and clients can not connect. We do not have a Hardware Load Balancer.

    Any guidance would be greatly appreciated.

    thx

  36. Comment by Ben Goodfellow:

    Hi Jerrid,

    Excellent article, it builds on another I used to create my DAG. I hope you don’t mind answering my question.

    We currently have a 2 node DAG. One in datacentre, which also has another VM for the Witness. And a DR site here in our office. I have tested shutting down datacentre exchange and it fails over nicely. I wasn’t aware of the role the witness plays so I assume if we had WAN failure or the physical server at the datacentre died, then because both the Exchange and Witness are down the DR site would also unmount?

    This is not the desired result, so my question is if our witness was at a third site that both the datacentre and office exchange servers could contact via VPN, I assume that if Datacentre wan failed the DR site would continue as normal as it can still see witness?

    Thank you for your time.

    • Jerrid Williams
      Comment by Jerrid Williams:

      Hey Ben,
      Thanks for the question.
      There are two things here. One, if you lose your DAG member in the primary site and the FSW, you are right, the DR server will dismount. This is where your Alternate FSW comes into action. You’ll need a designated server in the DR site to act as an AFSW for your failover (this is not automatic), so you can mount databases in DR.
      To answer your third site question, yes, with 2013 you can put your FSW in a third site so that if your primary site/server goes down, your DR server will be able to communicate with the FSW and mount databases without the use of an AFSW. This is an automatic failover setup.
      Good question and I hoped this helped.

  37. Comment by Mark Jay:

    Many thanks for your very useful guide.

    We have a two-node DAG stretched across two datacentres in two AD sites. Yesterday we suffered an outage caused by the DAG network becoming unavailable on the active mailbox server. The DAG replication network is shared alongside client connections. Event logs showed that there was also issues connecting to the FSW which is on the same site, and subsequently all databases were unmounted. I was able to fix this problem by going to Failover Cluster Manager and unticking and reticking the ‘allow clients to communicate through this connection’ radio button, the DAG came up again straight away.

    I would be very grateful if you can provide advise on the below three questions –

    This had management jumping up and down a little, how can I add resilience to the DAG network, as I see it as a single point of failure at present?

    I blocked automatic activation of Databases in the DR site as I frequently found that DBs were being automatically mounted in DR causing client connectivity issues – is this a recommended action?

    Also, should I be enabling DAC mode for my DAG, seeing as its only two node?

    • Jerrid Williams
      Comment by Jerrid Williams:

      Hey Mark,
      Thanks for your comment and questions.

      First off, it is common practice to block automatic activation of Database in the DR site, so you’re good there.
      Second, you want DAC mode enabled on a DAG where there is a chance split-brain could be an issue. In your case, you’d want DAC mode enabled because your two nodes are separated by a WAN.
      Third, there are many ways to add HA to your DAG network depending on your setup. If your servers are physical, then I would recommend teaming the NICs and making sure they are connected to separate switches. Some people on the product group would argue that teaming is added software that could cause issues because they’d rather add more NODES to the DAG (which is another option), but I’ve deployed many of DAGs with teamed NICs and haven’t had issues. There are some requirements for teamed NICs and DAGs, mainly they have to be configured as Fault Tolerant Only, meaning that the NICs are configured as Active/Passive. If you’re virtual, it’s obviously the hosts that need to have their NICs configured with HA. This again is assuming your network is redundant.

      One thing I would suggest, and it sounds like you’re doing, is do a root cause analysis to determine exactly what caused the network outage and take steps to fixing the cause. It sounds like you had two issues. The first issue is that your primary site lost connectivity to the DR site. The second issue was that the primary NODE was unable to communicate with the FSW. In normal operation, the DAG does not use the FSW so if it’s trying to, that means it’s losing connectivity to the DR server.

      I hope this helps and please let me know if I can help any further.

      • Comment by Kurt:

        Hi Jerrid,

        Thank you for the excellent article on Exchange 2013 DAGs/clustering.

        I see that you mention that if setting up NIC Teaming the team needs to be set up as fault tolerant only. Do you know what the NIC settings for Windows 2012R2 teaming would be for this? This is for Teaming Mode and Load Balancing Mode. Also, where did you find out about these limitations? This is the only mention of them I could find and would like to do LACP with a switch LAG if I could. (This teaming is just for the MAPI network, and not the DAG replication.)

        Thank you,

        Kurt

        • Jerrid Williams
          Comment by Jerrid Williams:

          Hey Kurt,
          Thanks for the kind words and questions.
          Regarding where I got this guidance from, I tried recalling the article, but I believe I learned of that in my MCM training/notes from the product group. I’m on a distribution list with all the other MCMS/MCSMs around the world and Microsoft, and I reviewed those, and their stance is still the same. They recommend simplicity so they would probably tell you to not use NIC teaming, however, if you’re going to, they’d recommend FTO. As for the 2012 R2 teaming features, I don’t have any real world experience on this, but I did find a good blog article that might help you out with those specifics. http://blogs.technet.com/b/keithmayer/archive/2012/10/16/nic-teaming-in-windows-server-2012-do-i-need-to-configure-my-switch.aspx I’d still recommend, and Microsoft would to, that you keep the teaming configured as fault tolerant. I believe in the 2012 R2 world, that means to configure Teaming Mode as Switch Independent and setting one NIC as standby.
          I hope this helps and thanks again.
          Jerrid

  38. Comment by Alexios Pappas:

    Hello Jerrid,

    First of all Thank You and Congrats for the great article and help on this topic that is a complicated one and with limited-confusing resources even on Technet! I have a fast question, but I haven’t seen anywhere mentioned (on this or other threads). When we are talking about site resilience (I know this article is for High Availability and not Site Resiliance though) we mean two Sites on different datacenters that have except Exchange Server and a DC right? Because if I lose Site1 then Site2 Should work independently.

    Thanks

    Alexios

    • Jerrid Williams
      Comment by Jerrid Williams:

      Hey Alexios, thanks for the comment and the question.
      Site Resiliency means surviving a complete site failure.
      High Availability means surviving a failure within your production site.
      For example, having a two node DAG in a single site should provide you with HA. Extending that to a separate site with a third node would provide you with SR. I wouldn’t say that Site2 should work independently of Site1 because in most SR deployments, Site2 requires manual configuration to start working if Site1 is unavailable.
      I hope this makes sense.
      Thanks again,
      Jerrid

  39. Comment by Munib Akhtar:

    Nice Article with step by step. Thanks for sharing your ideas.

  40. Comment by Senthil Kumar:

    I need some suggestion from you on implementing Exchange 2013 DAG.
    Do we need to have separate CAS server as i am going to 2 Node DAG in HQ and i node in DR which will be part of the DAG nodes itself. What is your suggestion?
    And also SSL certificate for these servers as i wanted to use same SSL for theses 3 nodes. Kindly suggest the way forward.We have got two different domains (email.domain1.com and email.domain2.com) which needs to be protected using single certificate

    • Jerrid Williams
      Comment by Jerrid Williams:

      Hey Snthil, thanks for your question and commenting.
      I would not separate out the CAS and Mailbox role. I would always deploy them on the same box. One technical requirement to separate them out would be because you are planning to use Windows Network Load Balancing, and Microsoft wouldn’t even recommend that. I would suggest KEMP Technologies for load balancing. Inexpensive and great product.
      I would get a single cert for all. Make sure you buy it from a company that allows you to use the same certificate on multiple servers. I always go with digicert.com. They are awesome and hands down the best cert company I’ve ever worked with.
      I hope this helps and thanks again.

  41. Comment by Jason Gordot:

    Thanks for your awesome article. I need your opinion on this topic regarding my Exchange 2013 installation. I have 5 AD sites. Of those sites, only one (the data center) is internet-facing. All sites are connected via MPLS.

    Here’s how I have it installed:

    SiteA – 2 multi-role (mbx+cas) servers. – 2 Active/Passive database Copies for local users

    SiteB – 2 multi-role (mbx+cas) servers. – 2 Active/Passive database Copies for local users

    SiteC – 2 multi-role (mbx+cas) servers. – 2 Active/Passive database Copies for local users

    SiteD – 2 multi-role (mbx+cas) servers. – 2 Active/Passive database Copies for local users

    SiteE – 2 multi-role (mbx+cas) servers. – DataCenter/Internet-facing Site – Includes lagged copy of all DB copies from other sites activation preference 3. SiteE also contains server acting as FSW.

    Questions:

    1. Do you foresee an issue with this design should the link go down at any one site? That is, could a WAN failure at one site cause the “cluster” to lose quorum and prevent DBs from mounting?

    2. Any advantage to separating the roles given the geographical locations? Do we need DAC mode enabled?

    3. For sake of making sure one site doesn’t take down the other (since this is MPLS), do we need to create one DAG per site?

    • Jerrid Williams
      Comment by Jerrid Williams:

      Hi, Jason, thanks for commenting and the questions.
      Let me get the easy ones out of the way.
      1. In your design, if I understand it correctly, you have a 10 node DAG so you need 6 voting members (10/2 + 1) to survive a failure. Server 2012 clustering adds in dynamic quorum, so this helps a lot in failure, but I won’t cover that due to time, but take a look at that new feature and how it affects Exchange. Anyways, there is an even number of nodes so your FSW will be used to maintain quorum if need be. With all that said, a single site failure will NOT take down your entire DAG. You can actually lose two sites and still be ok. With dynamic quorum, you can actually lose a lot more just as long as you have enough surviving nodes to maintain quorum at the time of failure. Again, read up on this cool feature.
      2(a). There are no advantages to separating out the roles, in fact, I’d see it as a disadvantage because it increases costs and administration.
      2.(b). You always want to enable DAC mode in any design where you can end up in a split-brain scenario, which is any DAG stretched to another site. Your design definitely calls for that.

      Now to the harder question regarding your overall design. I’m not a big fan of a DAG that spans more than two sites and that’s just because of the risks a WAN outage. The more WANs included in your design, the more risks you accept due to the network. If something happens with your MPLS network, your entire DAG could go offline and with DAC mode enabled, could be even more difficult to get back up.
      In a design such as this, it’s really heard for me to comfortably give advice, but I always try to keep things simple because simple is easy. I would suggest you look at consolidating all mailboxes back to a central location. I know there are a lot of restrictions when doing this (like the WAN), but with 2013, if you’re not using separate internal name spaces for each location, then you’re coming across the WAN anyways. So my main advice would be to seriously look at consolidating all mailboxes back to a central datacenter and using one of your other sites as a DR site. This way you have a single DAG across two sites and you could probably reduce your server count from 10 to 3 (depending on server count and mailbox profiles). I had a customer that had almost the exact same site structure as you and they initially wanted each location to have it’s own DAG with site resiliency. That meant they needed 15 servers and they were a very small company. We reduced their design to 3 servers by centralizing it all. They initially told me that it wasn’t possible due to business politics, but after presenting the business with the costs associated with separating out the sites, we were able to consolidate. If politics are a factor in your design, represent your design in dollar amounts and that will change their minds most of the time.
      I hope this helps, and please feel free to ask more questions. I feel like I jumped around a lot so hopefully I didn’t confuse you.

  42. Comment by Shafeek:

    I hope now windows 2012 R2 is supporting exchange 2013( from CU4). please find the below article http://technet.microsoft.com/library/ff728623(v=exchg.150).aspx

  43. Comment by Zizou:

    Hi Jerrid!

    Awesome article. You have a great sense of humor too 😀

    Cheers

  44. Comment by Ace:

    Well most of the posts are mentioning about Exchange 2013.

    at this stage I am moving to Exchange 2010, but very less articles are there on Two Node DAG and less talked about MAPI and Replication Network.

    Above Article really helped me in getting my concepts clear on networking front.
    Thanks

  45. Comment by Jonathan Horne:

    All all the funny references in this article… im surprised we didn’t see:

    “you like dags?”

  46. Comment by Alex Driver:

    Hi Jerrid,

    I have two mailbox databases that replicate between two servers.
    Would you recommend having all mailboxes on a single database or should I split the total number of mailboxes evenly on the two databases?
    i.e.

    Name Active on server Server with copies Number of mailboxes
    Database 1 Server 1 Server 1, Server 2 50
    Database 2 Server 2 Server 2, Server 1 50

    or

    Name Active on server Server with copies Number of mailboxes
    Database 1 Server 1 Server 1, Server 2 100
    Database 2 Server 2 Server 2, Server 1 0

    Thanks Alex

    • Jerrid Williams
      Comment by Jerrid Williams:

      Hey Alex, thanks for commenting and sorry for the late reply. The reason I usually create multiple databases to keep the databases sizes at manageable levels. I’d say that if you are under 2TB for your database size, and you are currently able to restore your data (single item, single mailbox, single database, or the entire environment) in the time frame expected by your business, then one database is fine. With that said, splitting it up into two databases spreads your mailboxes out a bit and uses your hardware investment a little more. I guess my answer is, as long as your RTO (recover time objective) is ok with one database, it doesn’t matter if you do one database or two in your situation. If you were to use the capacity planner from Microsoft and all your mailboxes could fit in a 2TB database, they’d say one database. If I kept to keeping it simple, I’d probably put everyone in one database too. When my single database got too large to backup and restore in a timely manner, I’d create a new database.
      Sorry for not giving you a definite answer, but like I said, in your case I don’t think one or two databases are going to help or hurt you much.
      Thanks again and I hoped I helped some.

  47. Comment by Alexey:

    Hi Jerrid,

    Thanks a lot for your useful article!

    But I would like to clarify two matters. As far as I understand, there is no any HA feature for Witness Server itself. For Witness catalog, to be exact. In case of failure of this witness server a lot of problems will occur.

    1)Are there any alternative solutions available to prevent such situations?
    2) In case of using DС as a Witness Server how can I move later a witness catalog from DC to another domain member server?

    Thank you!

    • Jerrid Williams
      Comment by Jerrid Williams:

      Hi Alexey, and thanks for commenting.
      If your witness server is unavailable, then it will only cause problems if you need it to maintain quorum, and in that case, you’re experiencing a multiple failure scenario, and if you didn’t design for multiple failures, then the solution is working as designed. If you need to sustain multiple failures, then your design will need to be changed to support that.
      With all that said, I have to sit back and think about what am I getting by protecting my FSW using a Scale-Out File server. If you don’t already have that infrastructure in place, you start adding a lot of complexity to support a file share that’s not used very often (hopefully). If you server hosting the FSW goes down and the FSW is not protected, then the understanding is that you’ll notice the server failure relatively quickly and then you can move the FSW to another server. That’s why I suggest putting the FSW on a server that you’ll know if it goes down, like a file server hosting user drives or a server that’s in the Exchange team’s control and is monitored.
      I definitely see your point and your concern, but I personally don’t think you’re getting that much in return for the complexity you’re adding.
      To answer your second question, the FSW and AFSW is a property of the DAG which you can update in the EAC or PowerShell.
      I hope this helps and thanks again.

  48. Comment by Vino:

    I am having exchange server 2013(2MB, 2CAS) in my primary site. Now iam planning for DR in other site..
    DAG replication NIC working fine in my primary sites. But i dont know how to make it communicate with DR site DAG replication NIC card, since i dont configured gateway in replication NIC card. If i add Gateway its communicating, but iam getting mutiple gateway warning message.

    Please suggest me microsoft recommended practice for this..

    • Jerrid Williams
      Comment by Jerrid Williams:

      Hey Vino,
      You’re correct, you shouldn’t have two gateways on the same server. The way to handle this is to use the ROUTE or NETSH command to add a static route to handle replication traffic. Basically, in non tech talk, you’ll add a route that says, “Servers in datacenter A should route traffic that is destined for datacenter B’s replication network to the gateway of datacenter A’s replication network.” Then you’ll add the same type of route to the datacenter B servers.
      Another thing to consider is that if you are using a 10GB network or your servers are virtual and your virtual NICs are using the same physical backend to send traffic, you can use one NIC to handle client and replication traffic. It keeps things simple and based off of what Microsoft has experienced in the service, you should be fine.
      Thanks and I hope this helps.

  49. Comment by Buddhika:

    Hi Jerrid,

    Thanks for the great flight! It it’s a smooth fly. Anyway, I have a situation; one of my clients has already running exchange 2013 single server , no DAG. He wants to add another server for DAG. I’m bit stuck and confused here, would you be able to give me expertise on how to install the second exc2013 server and make the DAG (remember! The first exc2013 server is live in the production floor)

    • Jerrid Williams
      Comment by Jerrid Williams:

      Hey Buddhika,
      Thanks for commenting and your question.

      The most important part about introducing an exchange server in a production environment is getting the namespace configured correctly and quickly. After that’s done, you can relax and do the other pieces at your own pace. One note, before I forget, make sure the existing 2013 server is running an OS that supports clustering (2008 R2 Enterprise or 2012).
      Ok, back the namespace. First, you’ll need to export the certificate (with the private key) from the existing 2013 server and import it into the new 2013 server. This can be done before 2013 is installed. Then, what you’ll do is find the current name used for the following services:

      EWS (Get-WebserviceVirtualDirectory -Server | FL *URL*)
      OWA (Get-OwaVirtualDirectory -Server
      | FL *URL*)
      OAB (Get-OabVirtualDirectory -Server
      | FL *URL*)
      EAS (Get-ActiveSyncVirtualDirectory -Server
      | FL *URL*)
      SCP (Get-ClientAccessServer -Identity
      | FL *URI*)
      OA (Get-OutlookAnywhere -Server
      | FL *Name*

      Those should let you know the external and internal URLs (namespace) used for each CAS service. Make note of those. Then prepare the commands in a text file before you install the new server. The commands should set the internal and external URLs to match the existing 2013 server that you got in the other commands.

      Then you’ll want to install Exchange, assign the certificate to the IIS service, and then run your preconfigured commands. I’m not going to try and convince you that’s important you do this after hours and quickly by explaining why, just trust me 😉 If you don’t do this, people will get security pop-ups.

      Next, after you’re up and running, you’ll want to do some sort of load balancing because I’m assuming you’re adding a DAG for high availability, but that only covers the databases and you’ll need to protect all layers (CAS, HUB, Mailbox). Review your options on this, but KEMP Technologies is a great solution for load balancing (I don’t work for them). They are inexpensive, solid, and very easy to configure. If you get stuck, their support is awesome.

      That takes care of the CAS portion.

      For the HUB, you’ll need to add the new server to any send connectors for redundancy. There’s a bit of work to do here that I won’t go into major detail, but if you’re using a smart host, make sure the new server is allowed to relay through it. If you’re sending directly to the internet, you’ll need to make sure that’s setup correctly. (Create firewall rules and NATs and PRT records to ensure email is sent correctly). For inbound, make sure you create a public MX record and supporting firewall rules. Create identical receive connectors if you need to allow printers/scanners/applications to relay through the new 2013 server.

      For the mailbox portion, you simply create the DAG and add database copies and you’re good to go.

      Anyways, this is before I’ve had all my coffee so if I missed a step, I apologize, but I think I hit the important parts. I would definitely do this after hours to avoid business interruption or irritating your customers with pop-ups and such. Also, I have to put a small disclaimer here. All this assumes the existing server was put in place correctly. If the FQDN of the server was used, consider reconfiguring the namespace to something like mail.company.com or owa.company.com. This requires more effort and after hours work, but it’ll be done correctly. Just make sure you get your certificates and services configured with the correct names.

      Thanks again for your question and I hope this helps.

  50. Comment by Christoph O.:

    Little comment i didn’t read in the article nor in the comments:
    When you change the path where the Mailbox-Database is stored (eg. Drive D), and then seed it over to another Server, the same path is used. So be aware that you might need another volume on the new exchange-Server to provide access to the same path…

  51. Comment by Ahmad Mazhar:

    Nice write up.

    Question: cAn i have DAG with one node on Windows server 2012 and other on Windows server 2012 R2?

    • Jerrid Williams
      Comment by Jerrid Williams:

      Ahmad,
      I don’t believe so, but I’ve never tried. I have tried 2012 with 2008 R2 and it failed. I would pretty confident is saying that even if it didn’t work, it wouldn’t be supported simply because that’s probably something Microsoft does not test.
      Thanks for commenting and if I get a chance to test this, I’ll update this comment.

  52. Comment by David Bernard:

    Really good article. Very straight forward but how do I get my additional servers to show up in the available member servers pool. I ran the Exchange Management Shell and they say connected but they are not in the pool or under servers. What have I done wrong?

  53. Comment by Potpal:

    Hi Jerrid – How about site resilience for 2 node DAG with two sites? Where would you put the witness server and what happens if the same site with 1 dag member and witness server goes down?

    • Jerrid Williams
      Comment by Jerrid Williams:

      Hey Potpal,
      With 2013, you can put the witness server in the primary site (manual failover), or put it in a 3rd site that both locations have reliable access to (automatic failover). Assuming you’re like most customers, you don’t have a third site, I would put it in the primary site. If the primary site goes down, you’ll need to provide an alternate fileshare witness in the surviving site to get your databases mounted again. If you do a Get-DatabaseAvailabilityGroup, you’ll see attributes for the AFSW. You can either wait for the primary site to fail to elect an AFSW or you can do it before any of that happens. Microsoft recommends doing this before a failover. Set-DatabaseAvailabilityGroup will do that for you.
      https://technet.microsoft.com/en-us/library/dd297934(v=exchg.150).aspx
      Thanks,
      Jerrid

  54. Comment by Declan:

    Hello Jerrid,

    Thank you for your wonderful article and replies to all comments. Am really impressed and hope you’ll help me out FINALLY as I’ve been through hell and back on this :-).

    A few users complained about a similar issue with mine but when you asked them for the error, they never got back to you. I have been trying to add the second server to my DAG which was created successfully and the first server added but the second throws up the following error:

    “A server-side database availability group administrative operation failed. Error The operation failed. CreateCluster errors may result from incorrectly configured static addresses. Error: An error occurred while attempting a cluster operation. Error: Cluster API failed: “AddClusterNode() (MaxPercentage=100) failed with 0x5b4. Error: This operation returned because the timeout period expired”. [Server: AAAAA.local]”

    Before seeing your post I was missing the ordering of NICs, but I’ve corrected that and the issue still persists!

    All servers run Windows Server 2008 R2 Enterprise SP1 and Exchange Server 2013 CU6 – all physical servers! The witness server has no exchange on it and only has one NIC, which is on the MAPI network.

    I ran these commands from EMS and after which I tried again with the same result:
    [PS] C:\Windows\system32>Get-DatabaseAvailabilityGroupNetwork

    Identity ReplicationEnabled Subnets
    ——– —————— ——-
    dag1\MapiDagNetwork True {{192.168.2.0/24,Up}}
    dag1\ReplicationDagNetwork01 True {{172.16.0.0/24,Up}}

    [PS] C:\Windows\system32>Set-DatabaseAvailabilityGroup dag1 -ManualDagNetworkConfiguration $True
    [PS] C:\Windows\system32>Set-DatabaseAvailabilityGroupNetwork -identity “dag1\MapiDagNetwork” -ReplicationEnabled $false

    [PS] C:\Windows\system32>Get-DatabaseAvailabilityGroupNetwork

    Identity ReplicationEnabled Subnets
    ——– —————— ——-
    dag1\MapiDagNetwork False {{192.168.2.0/24,Up}}
    dag1\ReplicationDagNetwork01 True {{172.16.0.0/24,Up}}

    Please help me with this if you can.

    Thanking you in anticipation.

    Declan

    • Jerrid Williams
      Comment by Jerrid Williams:

      Hey Declan, Thanks for the kind words and commenting. Sorry it took me so long to respond.
      I would first check the basics. Make sure you can resolve the Node names to check name resolution. I have seen where granting all Exchange nodes Full Control to the CNO in AD fix an issue similar to this. The other thing to check is to make sure you do NOT have the firewall service disabled. It’s ok to disable the firewall, just not the service itself.
      Try these things and let me know what you get. Also, to make sure I respond quicker, just email me directly at jerridwills@hotmail.com. If we find a solution, we can post it later for anyone else having issues.
      Thanks,
      Jerrid

  55. Comment by Keith Knarr:

    Question: I have 2 Locations. I have a separate replication network. When I create any dag and attempt to utilize the replication network it creates 2 networks for replication: ReplicationDagNetwork01 and ReplicationDagNetwork02. Communication is working great between DAG members in the same site that are configured inside of ReplicationDagNetwork01. The remote site does not work. How do I set this up correctly?

    What I am looking to do is have 2 local members and 1 remote member for replication purposes and DR. Just having a problem setting it up.

    Appreciate any advice or information you can send my way!

    • Jerrid Williams
      Comment by Jerrid Williams:

      Hey Keith, thanks for commenting.
      The reason for the two networks is because they are on separate subnets. 2013 is supposed to be much better at auto configuring networks, but I found that it still requires manual setup from time to time. You can combine the two replication networks into one network so that you should have a MAPI network with all MAPI subnets, and a replication network with all replication subnets. If you can’t communicate to the other network over the replication network, I’d try adding a static route on each node to help it route correctly. Here’s an article I found that walks through adding a static route.
      http://fixmyitsystem.com/2010/10/adding-static-route-using-netsh-and.html. Please let me know if you have any trouble or if this doesn’t work.

      Thanks,
      Jerrid

  56. Comment by Santy:

    Hi Jerrid, I’m the great fan of your articals. I’m going to start Exchange 2013 implementation in our organization with the help of your articals. I have two active sites DC(consist 2 exchange server) and DR(1 Exchange server), So for DAG creation which I follow:
    1. site resilience or
    2. 3 nodes in a site

    Please suggest.

    • Jerrid Williams
      Comment by Jerrid Williams:

      Hi Santy! Thanks for the kind words and reading.
      I’d follow your business needs on that one. If the business needs are High Availability only, then I would keep Exchange to one site. No need to overcomplicate things if there is not a requirement. KISS is what you’re after. If the business requires High Availability and Site Resiliency, I would put one in the DR site to satisfy the business need.

  57. Comment by Marek:

    How would I go about migrating stand alone Exchange 2013 server with existing mailbox databases to 2 nodes DAG setup? Can I still use this existing server and its mailbox data, or would I have to start creating two new Exchange servers and migrate mailboxes to DAG?
    By the way, would you know whether Exchange 2016 server license can be applied to Exchange 2013 server? I know this was possible with SharePoint 2010/2013, but I am unsure about Exchange.

    • Jerrid Williams
      Comment by Jerrid Williams:

      Hi Marek,
      Thanks for reading and the question.
      If your existing Exchange server is 2008 (r2) Enterprise or 2012 (r2) Standard, you can add a second Exchange server and create a DAG. No need to move mailboxes. If not, then you need to install two new servers and migrate mailboxes. This is because 2008 Standard does not support clustering and that is a requirement for the DAG.
      I’m not sure if 2016 license can be downgraded to 2013 license. My instinct would be to say, yes, but I would contact a MS rep to make sure. Things change all the time with MS licenses because there’s margin in mystery!

  58. Comment by Dylan Kasonde:

    Hi Jerid,

    I want to implement an Exchange 2013 Enterprise two site DAG as follows:

    Primary
    1. AD1
    2. Exch_Server_1

    DR
    1. AD2
    2. Exch_Server_2
    I want to configure them in such a way that if link between primary and DR is down. I can go to DR and use outlook on a laptop to connect to Exch_Server_2. In short I want the exchange databases on Exch_Server_2 to mount when link between primary is down.

    Secondly want Exch_Server_2 to server all users at primary site if Exch_Server_1 is down and link to DR is up.

    Could you provide me with a step-by-step guide to achieve this on Windows 2012 Std or Datacentre?

    What is your recommendation regarding running exchange on a physical box or Virtual Server?

    Regards,

    Dylan

    • Jerrid Williams
      Comment by Jerrid Williams:

      HI Dylan and thanks for reading and your question.
      While I don’t have a step-by-step (no time), I can say that what you’re requesting sounds like automatic site failover. You’ll need a third site to host your FSW.
      As for my recommendations on running virtual or physical, I usually leave that up to the customer. I ask them if they are mature enough in their virtual environment to not bring down the Exchange servers. If they feel like they are, I give them the Microsoft guidelines for running Exchange in a virtual environment and move on. If not, then we go physical. As far as sizing the servers in a virtual environment, treat them as physical and use the Microsoft Capacity Calculator. It accounts for a 10% CPU need when going virtual, but if that calculator says 8 procs with 64GB or RAM, that’s what you need, whether it’s physical or virtual. I have some VMware admins freak out and say that there’s blah blah blah features that make it so we don’t need X number of procs. Don’t follow that. Do what the calc says or go physical if you can’t.

  59. Comment by Flo:

    Hi Jerry,
    Thanks for this article, i just set up a 2 nodes DAG like describe here.
    My setup is :

    -1 Hyper-V with 1 exchange 2013 (CAS&MBX)
    -1 Hyper-V with a second exchange 2013 (CAS&MBX) and a FSW

    Failover A => When the first hypervisor goes offline, the failover works well
    Failover B => If i put the second hypervisor offline (and so loss of second exchange and FSW) => lost of quorum and no exchange access (owa,ecp,etc…)

    Is there a way to make the second failover works ?

    Regards

    Flo

    • Jerrid Williams
      Comment by Jerrid Williams:

      Hi Flo,
      Thanks for reading and the question.
      In the Failover B situation, you’re losing a voting member and your FSW, so the DAG will go down as designed. The only way to fix this is to move the FSW off of the same Virtual Host as the two Exchange Servers.

  60. Comment by Chuck Nguyen:

    Thanks for such a great and very helpful article. May I have a question for you?

    I intend to install an AD/Exchange 2016 system for 140 users at a single site. In order to save the cost but still maintain the high availability and hopefully good enough performance my plan is to have two Dell PE 2950 III servers each of which has dual quad-core(total 8 cores)2.5GHz Xeon 5420 CPU, 32 GB RAM, RAID-1 of two 1TB SATA drives, two Gbit NICs to host 2 VMs: one for AD DC/DNS/GC/DHCP and another for Exchange 2016 server on top of Windows 2012 R2. The first Dell PE 2950 named HOST1 will host ADDC-1 and EX16-1 and the second HOST2 will host ADDC-2 and EX16-2. EX16-1 and EX16-2 will be parts of DAG group with FSW running on a third small physical server running Hyper-V 2012 R2.

    Could you please kindly advise me whether my plan is OK, especially the possibility to use Hyper-V 2012 R2 for FSW server? Thank you a lot in advance.

    • Jerrid Williams
      Comment by Jerrid Williams:

      Hi Chuck, thanks for reading and the question.
      I think your plan is fine as long as one server failure does not bring down an Exchange server and the FSW at the same time, or two Exchange servers at the same time. Meaning, in a virtual environment, don’t put Exchange on the same Host as another DAG member or the FSW.
      Exchange doesn’t care or the FSW doesn’t care if it’s physical or virtual.

  61. Comment by Chuck K:

    Really good article. Easy to read, informative and a bit of humor. Well done and thanks.

  62. Comment by Mike:

    Hi Jerrid, BEST article I have read in years! Cudos!

  63. Comment by Lucky Hamu:

    I have a quick question hope you will answer that I created a DAG with two nodes and feel that if one node goes down the response from other node very slow to up and running the failover and serve to outlook client.

    Kindly suggest any thing I missed during configuration and tell how to verify the DAG is properly configured.

    Thanks

  64. Comment by Lucky Hamu:

    I have quick question that what is default time of database failover if shutdown active node and passive come up. In my case I manually shutdown active database server the passive server comes up approx. 5 minutes to get stable.

    Kindly guide

    • Jerrid Williams
      Comment by Jerrid Williams:

      Hi Lucky, and thanks for commenting.
      Would you mind telling me more about your setup? Do you have Multi-Role servers or have you separated out the roles? Are your CAS servers load balanced?
      Thanks!
      Jerrid

  65. Comment by TJ Hooker:

    Jerrid,
    Hey. This article is amazing! I know I can get our Exchange servers straightened out, your article gives me the confidence to set up a DAG for our organization. I was hoping you were still monitoring this thread. Fortunately for me I checked back and you replied to another post in April. With that said, I do have a question and I think it’s is actually not a repeat. The overall question:

    Are DAGs affected by Exchange servers at different Cumulative Update levels? Must all DAG members be at the same CU level?

    Here is what’s driving my question. I’ve been on the job over year now and have waited till now to ‘rock the boat’ a little. I inherited an Exchange environment consisting of a 2013 CAS server running on 2008 Enterprise and a 2013 Mailbox server running on a second 2008 Enterprise server. Both are virtual, no unified messaging is in use. Both were installed about 3 years ago and both are running CU4. Nobody has really touched them since the deployment. Even I have to admit I’ve not run updates (CUs and other OS updates) like I should because taking down the Exchange servers at any time is a big deal for us. I’ll reveal one detail, my employer is a municipal government, and you would not believe how ill our employees get at taking e-mail away from them, even a 2am. (You don’t want a bunch of ill cops to meet you at your cube when you get in for the day because they spent most of the night shift without e-mail. 😉

    So here’s my neat idea. I need to get to CU12 (the reviews seem favorable for it) and I want us to have a DAG. The bosses approve of allocating the extra disk space on our SAN. My plan:
    -Take the outage to update our CAS to CU12. No choice there, but that would seem to be a shorter outage than updating our mailbox server.
    -Build a new Server 2008 Enterprise VM, doing so with a disk layout identical to our present mailbox server.
    -Install Exchange 2013 on the new VM with the Mailbox role, but use the CU12 bits so that I get straight to CU12.
    -Configure the DAG (with the awesome guide above) and wait till it’s in full operation and all syncing is successful.
    -Take the original mailbox server down at my leisure and update it from CU4 to CU12. My new DAG member would have things covered while the original is down.
    Could this work? Or is my ‘neat idea’ like Oliver North’s ‘neat idea’ which could get me in a world of hot water. Thanks in advance for your input.

    TJ Hooker

    P.S.
    -Yes, I’ve gone by TJ Hooker for years.
    -No, I haven’t ridden on any car hoods lately.
    -Yes, I must admit I like Shatner’s acting work, but his directing work – not so much.
    -No, I do not know where Heather Lockliear is. If I did, I would be there instead of worrying about a DAG 😉

    • Jerrid Williams
      Comment by Jerrid Williams:

      HA! Thanks for the great question, TJ, and for commenting! How could I not respond since you took the time to be so thorough?!
      Let’s get to it. The question regarding having DAG members on different CUs, the answer (as always) is, maybe. The one thing I know you have to worry about is jumping to a CU that modifies the schema of the mailbox database. This is not the AD schema I’m talking about, it’s the mailbox database schema. Here’s the caution. If you have a DAG and want to go to the latest CU, you’d follow some steps similar to this:
      1. Move all databases over to node 2.
      2. Update node 1.
      3. Move all database over to node 1.
      4. Update node 2.
      5. Balance out the databases.

      Let’s assume that you’re installing a CU that does modify the databases’ schema. After you’ve updated node 1 (step 2) and mount the databases on it (step 3), those databases’ schema will be updated. Once that happens, you will not be able to mount those databases on a node 2 until after it has been updated as well. In the scenario above, you wouldn’t notice because you update Node 2 right after node 1, but it’s just to illustrate the point I’m trying to make. I haven’t checked, but I think since RTM, the only CU that updated the schema was one of the CU1-CU4 updates. Can’t remember which one.

      So, with that said, your DAG members can be at different CU levels, but if the higher CU modifies the database schema, you won’t be able to move those databases back to the lower CU server until it’s updated.

      As far as your plan, I like it! Here are a few things I’d like to mention that might help.

      First, it’s been a while since I wrote that article and Microsoft has learned a lot from their O365 deployment, one of which is the need for a replication network and a client network. I’ve mentioned it in other comments, but there are cases where separating out those networks doesn’t make sense, and one of those times is when you’re virtualizing. If two virtual NICs are sharing the same hardware NIC, you’re not buying yourself much, so I would just do a single NIC to keep the number one rule of designing, and that’s keeping it simple. DAG networking is the place where I expect misconfigurations when reviewing a client’s environment. So just do a single NIC and keep it simple.

      The other thing I’d like to toss out there is redundancy. You’re building a DAG and it will protect your mailbox layer. Your HUB layer is inherently protected because HUBs are awesome, but your CAS role is not protected. I’m sure you already get this, but I just wanted to mention it. If your goal is to get your messaging environment highly available (and it sounds like your users want that..lol), then maybe as Phase 2 you can configure your CAS layer to be HA. Since we never use Microsoft NLB, you might want to check out KEMP Technologies for inexpensive load balancers (I don’t work for them).
      Finally, if you’re going to have two CAS servers load balanced and a DAG, I’d suggest combining the roles so that you have two servers total. Ross Smith wrote a great article on why your HA increases by combining roles due to reducing failure domains. I understood about 10% of it because Ross is so dang smart, but here’s the link if you get bored: https://blogs.technet.microsoft.com/exchange/2011/09/16/dag-beyond-the-a/

      Ok, I’m done. Sorry for the long answer, but hopefully it helped! Good luck with the upgrade! If you remember, stop by and let me know how it went.

      Thanks,
      Jerrid

  66. Comment by Lucky Hamu:

    Hi,

    I have 2 CAS servers in Hyper-V and 2 physical Mailbox servers. I am using DNS round robin for CAS servers and it is working fine.

    Please let me know if you need more information.

  67. Comment by Sachin (Sam):

    Hello Jerrid.

    Thanks for your TIME, EFFORTS and PATIENCE to put together this article and all the responses.
    I think I am late in race for DAG but I think that happens when you work for small firm and deals with lots of things at same time.

    Coming to point. Here is our current environment

    Single Site with single AD, 2 DC, 1 Exchange 2013, CU12 with all roles on it on Windows 2012 R2.
    Approx 200 users. Exch is on ESX (if that matters). We have a backup solution Appassure which backsup Exch every hour B2D and replicate it to our DR site (cold state). We have 100 mbps site to site link with very low latency.

    For a DR and or maintenance/min downtime prospective, I started to piece together DAG information to install a second server at DR site. We have License for two Exch servers.

    All emails route through gateway server (I call here GWS), which is third party spam filter as well and installed on our physical location. So outside world has seen only this GWS, MX record points to that. Mobile devices comes inside to network (Airwatch/SEG) and redirects to namespace email.domain.com for message transaction. All users are online (No cache mode) connected to Exch via outlook 2013 client.

    What we want to achieve:-

    1. Data keep replicating to DR site as passive. (I think this is easy to perform with DAG and I know how to as well).
    2. When we do Exch maintenance/upgrade (or in case of disaster), we can switch the server to DR site manually, and outlook and mobile users connect to it. I know how to make standby Active, but what I don’t know how the users (outlook, mobile) will redirect to DR site?
    3. What settings in / for DNS (internal/external), MX record and Certificate etc. needs to be changed.
    4. And last (I think), how to switch back. I think following reverse order of 3 would all be required?

    Not sure..

    1. Does it really makes sense to deploy DAG to DR site with all these efforts, given the backup software Appassure does (all most) same thing. It export VM standby of Exch and continuous update and replicate to DR. with much ease.
    2. Or May be I can have the backup export machine to Prod site and have DAG for DR site.

    Please:

    Suggestion / advise / solution?

    Sorry for lengthy draft, but I tried to pass much information as I can. Thanks

    • Jerrid Williams
      Comment by Jerrid Williams:

      Hi Sam! Thanks for all the detail and thanks for commenting.
      To answer your first question I saw, when switching over to the other datacenter and getting clients redirected to the DR site, you’ll need to update DNS records (internally/externally) to direct clients to the DR site. This will require that all firewall rules are in place to support client connectivity to the DR site and probably an update to your GWS if it’s pointing to an IP to deliver email. There shouldn’t be any cert changes if you use the same cert on both servers. One suggestion, if your plan is to utilize that DR server during maintenance windows, is to lower the TTL on the DNS records related to Exchange (MX, Host) so that it clears out of their DNS cache faster.

      As far as suggestions, I’d break it down to needs of the business, which it looks like you’ve started doing. I’d sit down with the business owners/stake holders and find out what the requirements are for email. This is where RTO and RPO comes into discussions. How fast does email need to come up and how much of the data needs to be available when it does come back up? If they put it on you or don’t give you definitive answers, then come up with a solution and communicate the RTO/RPO and get signoff on it so that everyone agrees to the solution you’ve presented.

      One quick note here, I find that a lot of IT people don’t have these types of conversations with the business. Maybe because it includes talking with the higher ups in the company, but this should be a regular conversation with all applications. At the end of the day, we are here to serve the business. When they have a need, we should be asking all the questions to determine a solution to meet that need. This helps in many ways. It manages expectations which tends to make people more understanding and willing to invest money in a proper solution. If the business says that we need X application to be highly available and recoverable during a disaster, then you can provide costs to meet those needs. If the cost is too high, then the business can scale back their requirements and you’re off the hook and didn’t have to deploy a “I Hope this works with the budget I have” solution. I’m ranting and rambling here, but don’t be a “yes man” and don’t take responsibility for a solution by assuming. Let the business tell you the requirements and the present them with a solution that meets those needs as simple as possible. Let them decide if the solution to meet their needs is worth the cost. The ownership becomes theirs and yours. You just need to make sure you present the right solution and it does what you say it’s going to do. No pressure 😉

      Ok, so back to what we were talking about. Once I’ve collected that information, then I’d look at how to meet those needs as simple as possible while leveraging current investments when possible. For most Exchange admins, DAGs are pretty dang simple and usually can meet a lot of business requirements around RTO/RPO. But if you are comfortable with using VM and Appassure and confident it’s meeting the business needs, then you could look at sticking with that. Just make sure you’re testing the recovery procedures. I’ve had customers tell me their backup/restore solution can restore terabytes of data in minutes, only to find out that it really takes 4 days. That’s not the kind of thing you want to find out during a true disaster scenario.
      You do mention being able to handle maintenance windows, and a DAG is great for that. Some customers rely on VMware snapshots, and that’s pretty dangerous and I think unsupported with Exchange.
      So… With all that said, I’d probably do a DAG because of the first two initiatives you want to achieve. You have a process in place that meets the first initiative, but a DAG will meet the second initiative nicely. I’d keep your backup software in the picture to handle scenarios that a two node DAG wouldn’t protect you from.

      I hope this helps and good luck with your deployment.

  68. Comment by Sachin (Sam):

    Hello Jerrid.

    Thanks for your TIME, EFFORTS and PATIENCE to put together this article and all the responses.
    I think I am late in race for DAG but I think that happens when you work for small firm and
    deals with lots of things at same time.

    Coming to point. Here is our current environment

    Single Site with single AD, 2 DC, 1 Exchange 2013, CU12 with all roles on it on Windows 2012 R2.
    Approx 200 users. Exch is on ESX (if that matters). We have a backup solution Appassure which backsup
    Exch every hour B2D and replicate it to our DR site (cold state). We have 100 mbps site to site link
    with very low latency.

    For a DR and or maintenance/min downtime prospective, I started to piece together DAG information to
    install a second server at DR site. We have License for two Exch servers.

    All emails route through gateway server (I call here GWS), which is third party spam filter as well
    and installed on our physical location. So outside world has seen only this GWS, MX record points to that.
    Mobile devices comes inside to network (Airwatch/SEG) and redirects to namespace email.domain.com
    for message transaction. All users are online (No cache mode) connected to Exch via outlook 2013 client.

    What we want to achieve:-

    1. Data keep replicating to DR site as passive. (I think this is easy to perform with DAG and I know how to as well).
    2. When we do Exch maintenance/upgrade (or in case of disaster), we can switch the server to DR site manually, and
    outlook and mobile users connect to it. I know how to make standby Active, but what I don’t know how the users
    (outlook, mobile) will redirect to DR site?
    3. What settings in / for DNS (internal/external), MX record and Certificate etc. needs to be changed.
    4. And last (I think), how to switch back. I think following reverse order of 3 would all be required?

    Not sure..

    1. Does it really makes sense to deploy DAG to DR site with all these efforts, given the backup software Appassure
    does (all most) same thing. It export VM standby of Exch and continuous update and replicate to DR. with much ease.
    2. Or May be I can have the backup export machine to Prod site and have DAG for DR site.

    Suggestion/advise/solution?

    Sorry for lengthy draft, but I tried to pass much information as I can. Thanks

  69. Comment by Sachin (Sam):

    UPDATE: your response to James on Monday, May 12th 2014 at 11:08 am | is I like to have more clarification. How DNS, certificate, etc and other changes are required?
    We are inclining towards DAG – 2 nodes on same site. Still exploring what makes more sense Active/Active or A/P.
    In either situation, is there any downtime for users for implementing the DAG?
    Please advise. Thanks

    • Jerrid Williams
      Comment by Jerrid Williams:

      Hi Sam,
      If you are doing a DAG in the same site, you’ll need to install the same cert on both servers and you can do round robin DNS or get a load balancer to handle client connectivity. KEMP is a good solution and inexpensive. I’d go A/A if they are in the same site. Might as well utilize your hardware investment by dividing your databases between the two servers.
      There shouldn’t be any downtime when creating a DAG itself but I still like to do it after hours just in case the databases dismount for some crazy reason.

      Thanks,
      Jerrid

  70. Comment by Ron:

    thank you for the great post – very valuable information. There is one part I am unclear on though if you can so kindly help clear the air. When you state “Select the servers you want to add to the DAG. You can select multiple servers here. I’m adding two servers at the same time. I’m skipping RED-15EXCH02 because it’s running 2008 R2 and the other two servers I’m adding are running 2012.

    When you add the first Exchange server to the cluster, Microsoft has reported that if you add Exchange servers to the DAG too quickly and Active Directory does not have time to replicate, the second Exchange server might not see that server creates the CNO in Active Directory if you didn’t pre-stage it. the CNO and then create it’s own. This might be another reason to pre-stage the CNO before adding a node to the DAG or at least make sure you force replication after you add the first node to the DAG to replicate around the CNO”

    So I thought you already prestaged the DAG CNO or when you manually created it you named it DAG02. Isn’t this done already so you when state “when you add the first exchange server to the cluster, that server that server creates the CNO in Active Directory if you didn’t pre-stage it” But I thought you already created the DAG as you are now just adding members. I guess I am confused on why it would create another DAG CNO if one already exists? Thank you in advance if you can help clear up!

    • Jerrid Williams
      Comment by Jerrid Williams:

      Hi Ron,
      Thanks for reading and the question. Sorry for the confusion, too.
      If you’ve pre-staged the CNO, then it won’t create another one. My comment was more around adding multiple nodes to the DAG when the CNO was not pre-staged or AD was not fully replicated. If the CNO is pre-staged and AD is fully replicated, you should be fine.

      Thanks,
      Jerrid