Using Exchange Standard or Enterprise Edition to Build a DAG

A recent discussion amongst some Exchange Server MVPs asked whether it was a good idea to implement a Database Availability Group (DAG) using the standard edition of Microsoft Exchange Server 2010. Although this is obviously possible because Exchange 2010 does not require the enterprise edition to form a DAG, I’m not sure that this is a good route to take. In passing, you do need the enterprise edition of Windows 2008 R2 to be able to use Windows Failover Clustering, the fundamental underpinning of the DAG.

Companies do need to keep an eye on cash spent on IT and a natural tendency exists to restrict spending whenever it’s not absolutely necessary. A DAG built on the standard edition of Exchange 2010 can support five mounted databases on each server (mailbox and public folder databases count against the limit) whereas Exchange 2010 enterprise edition can support up to one hundred mounted databases. Assuming that you deploy sufficient DAG members to support three copies of each database (two copies deliver reasonable redundancy; three provide a warm feeling), it’s reasonable to argue that you can avoid the higher software license fees required for Exchange 2010 enterprise edition and go ahead with the standard edition. I agree with this position, but only up to a certain point.

A small DAG (say, three mailbox servers) can certainly deliver good redundancy at an excellent price point, especially if you deploy JBOD-style storage. But then I start to think about why the DAG exists. A DAG is there to deliver highly available mailboxes, pure and simple. If you accept that this statement is true, then it follows that you should support the software with a high-quality environment. In other words, you pay attention to points such as multiple NICs on the servers, intelligent storage controllers, disks with an extended MTBF, and server hardware that doesn’t look as if it were hand-crafted from sheet metal using a can opener. In short, you spend money to reduce the potential of hardware failure.

Taking this approach further, shouldn’t you then opt to deploy the enterprise edition of Exchange to be able to support more than five mounted databases on a server? Rules of thumb for successful DAG designs suggest that flexibility is a really good thing to have. That’s why, in general, it is preferable to operate a large DAG (up to the sixteen members supported by Exchange 2010) rather than several small DAGs on the basis that the large DAG will be much more tolerant of failure than a smaller DAG.

Having the ability to mount more databases on a DAG member means that the databases can be smaller. Many good things flow from not having to cope with giant databases: transitions following failures and administrator-initiated switchovers should be faster, as will reseeding operations (should the need occur). Backups will also take less time. And if a database should disintegrate in flames in such a way that it cannot be recovered from a copy, a restore from disk will be quicker too. Expansion is easier too as you don’t have to worry about hitting the five database limit. All in all, a number of operational issues are made easier when more databases can be mounted. Apart from the larger check that has to be written to Microsoft, I’m not sure I can think of any downside in saying that the enterprise edition of Exchange is usually the best choice to provide the underpinning of a DAG.

This isn't to say that there aren't some interesting edge cases to be explored. For example, you might want to have a single server in a DAG that runs the standard edition of Exchange 2010 but is expressly intended to never host active databases. Instead, this server will only host passive copies of the databases that store the mailboxes of "very important people," usually company executives or the like. In this scenario, other copies of these databases exist within the DAG and can be activated if required, the copies on the standard server have low activation preferences, and the entire mailbox server could have its activation policy set to "Blocked" with the Set-MailboxServer cmdlet so that Active Manager won't even consider attempting to bring the copies online. The idea here is that the server will provide an extra copy of up to five databases containing critical mailboxes that could be brought online through administrator intervention if something really horrible happened. I can see how the idea might have value in some circumstances but I'd still prefer to have the server run Exchange 2010 enterprise so that it can play a fully functioning role within the DAG.

A possibly more interesting scenario is where you want to have a server in a DAG that runs Exchange 2010 standard and only hosts archive mailboxes. As you know, Exchange 2010 allows you to separate a primary mailbox from its archive. In most instances, I think administrators are happy enough to keep the two mailboxes in the one database on the basis that it's a simpler setup and simplicity is always better. This is valid, but there's also value to be gained in separating an archive away from the primary, if only following the "don't put all your eggs in the one basket" principle. I have heard some system designers contemplate creating such an archive server, the idea here is that the server hardware can be purpose-designed to accommodate the lower resource demands of archives while taking advantage of the lower cost of Exchange 2010 standard. Once again, it's an interesting notion but I still think that I'd like all the servers in my DAG to have the same hardware and run the same software so that I can spread the load equally across all servers. It seems to me that this is how DAGs are designed to operate.

Every company is different and the arguments advanced here will be more or less attractive depending on the circumstances in which a company finds itself. It’s an interesting debate to have, perhaps after discussing whether mailbox servers should be virtual or physical (my take: always physical).

One last point, those who feel constrained by the current 16-member limitation for a DAG are unlikely to find much joy in Exchange 2013. Despite its support for Windows Server 2012 and the 64-member cluster limit in that operating system, the signs currently are that Microsoft isn’t yet ready to lift the limit for a DAG. Exchange 2013 also supports Windows 2008 R2 SP1 and it would not make sense to have limits dependent on the operating system. What, for instance, would happen in a mixed DAG of Exchange 2010 and Exchange 2013 servers when some servers ran Windows 2008 R2 SP1 and others Windows 2012. Of course, this is not possible because Exchange doesn't support mixed DAGs composed of servers running different versions of Exchange or different versions of the operating system, but think of the complications if it did...

Follow Tony @12Knocksinna