Migrating an Exchange 2010 DAG to Exchange 2013

Migrating an Exchange 2010 DAG to Exchange 2013

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:

  • Create the new Exchange 2013 DAG and add Exchange 2013 mailbox servers to the DAG.
  • Create mailbox database copies within the Exchange 2013 DAG as required.
  • Move mailboxes from databases in the Exchange 2010 DAG to the Exchange 2013 DAG.
  • As mailboxes are drained from Exchange 2010 databases and the databases empty, remove these databases and their copies from the Exchange 2010 DAG.
  • As the workload reduces in the Exchange 2010 DAG, you can consolidate it on a smaller number of members and remove the Exchange 2010 DAG members that are no longer required.
  • After removing a mailbox server from the Exchange 2010 DAG, you can run Setup to deinstall Exchange 2010 and remove the server from the organization.
  • After all mailboxes have been migrated to the Exchange 2013 DAG, you remove the last remaining mailbox server from the DAG and then run the Remove-DatabaseAvailabilityGroup cmdlet to remove the now-obsolete Exchange 2010 DAG from the organization.

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

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.