Microsoft won’t release Exchange 2010 SP3, the version necessary to interoperate with Exchange 2013, until sometime in early 2013, no one has yet run into the issue of what to do to upgrade an Exchange 2010 Database Availability Group (DAG) to Exchange 2013. This will be a pretty fundamental operation for anyone interested in Exchange high availability, so it’s a good time to start planning – or at least thinking about the topic.
The big issue that you run into is that you cannot run mixed operating systems within a DAG, nor can you run mixed versions of Exchange. Therefore you can’t simply introduce an Exchange 2013 mailbox server into a DAG that is currently based on Exchange 2010. Or you can’t upgrade the underlying OS from Windows 2008 R2 to Windows 2012. Nothing in life is as simple as it might seen.
Given that Exchange likes to have its DAGs composed of member servers all running the same software, the approach that must be taken is to build a new DAG based on Exchange 2013 and then migrate mailboxes to the new Exchange 2013 DAG once it is fully operational. A general outline of what needs to be done is as follows:
As you remove Exchange 2010 mailbox servers, they can be reused as the basis of a new Exchange 2013 server. Don’t bother attempting to upgrade anything as it’s better to use the “strip to bare metal and rebuild” approach to create a brand new server running Windows 2012 (preferably) and Exchange 2013. When the new server is ready, it can become a member of the Exchange 2013 DAG.
All of this sounds like a lot of bother, but when you think about the situation, it’s really not dissimilar from the approach taken for “regular” Exchange servers where you cannot upgrade them to run a new version of Exchange. Given that this approach is now three versions old and we have become used to installing new versions of Exchange on new (or reused) servers, it does make sense to extend the rule to a DAG. Build a new DAG, migrate mailboxes, and move forward.
In closing, if you think that technical writing is a boring job because it's simply a matter of documenting what programmers have produced, have a look at the "How do you know this worked" section of http://technet.microsoft.com/en-us/library/dd979786(v=exchg.150).aspx, which I think demonstrates that some technical writers make their work a delight to read.
Follow Tony @12Knocksinna