• Status: Solved
  • Priority: Low
  • Security: Public
  • Views: 54
  • Last Modified:

Are two Exchange Servers in a DAG enough?

We have two Exchange 2016 on-prem servers in the same physical location and on the same network running on VMware.    Both mailbox servers are part of a single DAG.   The two servers are currently only balanced via round robin DNS serving a total of 85 users with over 800 mailboxes (yes, that's right - we have a LOT of shared mailboxes that duplicate many of the same emails).

We're a little backwards in that we went to production first with only one server because we didn't have the hardware to support more, yet we needed to move from Groupwise to Exchange pronto.    Now I have two working servers in the DAG, one active one passive.   My question is, should I feel comfortable now that I have two servers in the DAG, or should I have a third?    We only have hardware in this one location, so the third server would also be on the same local network.   I thought of setting a third one with a lagged database copy in case, I dunno, someone deletes an account or something silly like that (although in 12 years of administering a single Groupwise server, we've never had to restore an account).  

I realize this is more of a soliciation for educated opinions rather than a question with a straight right or wrong answer, but the folks here seem to be the best ones to ask.   Am I really getting a significant benefit from having a third server in the DAG in my situation, or is that just overkill?   I'm really trying to protect against Exchange database corruption as opposed to hardware failure as we are fully redundant there (at least as one can be inside a single location).   What events might warrant having a third server with a lagged database copy?
3 Solutions
Lagged. Copy is there to delay log replication so that if any corruption occurs in dB, you can recover it from lag copy, however it's difficult to find corruption in dB and in that case you r not sure where corruption of dB is replicated to lagged copy or not
Two servers are enough for 800 users unless you wanted to build DAG
Todd NelsonSystems EngineerCommented:
Only 85 active user mailboxes?  Three servers should be overkill, IMO.

Hopefully, you have a backup solution for these servers.

Personally, I believe servers with lagged copies are overkill in a small environment.  You also have the potential of losing quite a bit of data depending on how many days the DBs are configured to lag behind should you need to restore.

Review this article on Exchange preferred architecture ... https://blogs.technet.microsoft.com/exchange/2015/10/12/the-exchange-2016-preferred-architecture/

Also, if you are worried about accounts getting deleted, make sure you enable AD Recycle Bin as a precautionary measure...
Do you have any RTO (Recovery Time Objectives) and RPO (Recovery Point Objectives) ?
this would help give you confidence in what you have setup.  If your company could lose money if they lose service or data then its worth weighing up the financial risk vs cost of additional licences/hardware etc.

If you only have one site/datacentre then a 2 node DAG should be more than sufficient and as suggested above a robust backup solution it much better than a lagged copy, which only gives you a specific time window to know there is corruption and stop the lagged copy corrupting too.
izgoblinAuthor Commented:
Thanks all.   Yes, we certainly have redundant backups (onsite and off) so I'm going with the thought that a third server would be overkill.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: Certified Penetration Testing

This CPTE Certified Penetration Testing Engineer course covers everything you need to know about becoming a Certified Penetration Testing Engineer. Career Path: Professional roles include Ethical Hackers, Security Consultants, System Administrators, and Chief Security Officers.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now