Upgrading the database schema within an Exchange 2013 DAG

In my conversation about life, the universe, and Exchange development (well, mostly the latter) with Microsoft’s VP for Exchange development, Perry Clarke, he said “There isn’t a part of the core Exchange Server that is not shipped to our on-premises customers. We don’t have a special Exchange that runs in the cloud.” The meaning here is twofold: that Office 365 and the on-premises Exchange share a common code base and that (by inference), innovation in software engineering for “the service” flows through to on-premises customers through the servicing model now used by Exchange 2013.

In effect, this means that the cumulative updates for Exchange released by Microsoft to on-premises customers every quarter contain fixes and new features that have been tested by running at scale in Office 365.  Perry said that this should “comfort our on-premises customers that the code that they run is validated by running against millions of mailboxes before they have to deploy it.”

The theory sounds good but the question is how do on-premises customers recognize when innovation has occurred? It’s easier to know about new features when Microsoft ships a brand new release or a service pack because Microsoft markets the new software on the basis of the whizz-bang new features. For example, Exchange 2013 contains features such as Data Loss Prevention (DLP), Managed Availability, and database auto-reseed. The last two of these flow from Microsoft’s need to run their datacenter operations more efficiently (i.e. with as little human intervention as possible) and can be considered innovation, even if that innovation sometimes hiccups before on-premises customers can master it fully.

It’s harder to detect where innovation occurs in “regular” cumulative updates. I say “regular” because Exchange 2013 SP1 will be cumulative update number 4 as the same ship and update mechanism will be used as for updates 1, 2, and 3. SP1 will contain more features than the other updates, but it is really just a larger update than the norm.

But lurking in Exchange 2013 CU3 is a cmdlet called Update-DatabaseSchema that is used to update the schema used by mailbox databases. In the past (Exchange 2010 SP1 is a great example), updating internal database structures such as the global tables has created some challenges. For instance, an Exchange 2010 SP1 DAG member server could activate a database copy created on an Exchange 2010 RTM server, but the reverse was impossible because the RTM server had no notion of the changes made in the SP1 schema.

Engineers often need to tweak internal structures to increase efficiency. But given the number of mailbox servers that are deployed in DAGs to achieve high availability, including tens of thousands of Exchange Online servers running inside Office 365, it is inconceivable that the situation that arose in Exchange 2010 SP1 would be allowed to compromise high availability every time a schema update is necessary.

The Exchange developers therefore came up with a mechanism that allows the setup process to request database schema upgrades during server updates. For instance, when mailbox servers are updated from Exchange 2013 CU2 to CU3, you don’t realize it but setup runs Update-DatabaseSchema to request that databases on the server should be upgraded from the RTM version (0.121) to the CU3 version (0.126).

When the update is done on a standalone server, the schema is upgraded immediately. Servers that are installed from scratch using the CU3 code use the upgraded schema. However, an immediate upgrade cannot be allowed to happen within a DAG, so the update is treated as a request that should be actioned in the future when all of the DAG member servers are ready. In other words, when all the DAG member servers have been upgraded to a version of Exchange that supports the new database schema. When the last DAG member is upgraded with the new version of Exchange, the request made by Update-DatabaseSchema can be executed and all of the database copies within the DAG will be upgraded the next time that each database is mounted.

Updating the schema of a database affects the global tables or the data shared across all mailboxes in the database. The schema for the tables that make up individual mailboxes are also adjusted following a database upgrade. This happens the next time that a logon occurs to a mailbox.

You can use the Get-MailboxDatabaseCopyStatus cmdlet to discover what version of the schema is currently in use. For example, to find out the database schema versions for all copies of the DB2 database, we run the command:

PS> Get-MailboxDatabaseCopyStatus –Identity DB2 | Format-List Identity, Status, *Schema*

Name                                  : DB2\EXSERVER2
Status                                : Mounted
MinimumSupportedDatabaseSchemaVersion : 0.121
MaximumSupportedDatabaseSchemaVersion : 0.126
RequestedDatabaseSchemaVersion        :
Name                                  : DB2\EXSERVER1
Status                                : Healthy
MinimumSupportedDatabaseSchemaVersion : 0.121
MaximumSupportedDatabaseSchemaVersion : 0.126
RequestedDatabaseSchemaVersion        :

The maximum supported version of the database schema is 0.126. Both database copies report the same value, so we can conclude that these DAG members have been upgraded (in this case, to CU3).

However, the request to update the database schema is not actioned until the database is mounted, so to check whether this has happened, we run the Get-MailboxDatabase cmdlet as follows:

PS> Get-MailboxDatabase –Identity DB2 –Status | Format-List Name, *Schema*

Name                            : DB2
CurrentSchemaVersion            : 0.126
RequestedSchemaVersion          : 0.126

We can see that the request to upgrade the schema has succeeded and that the database is using the latest schema.

Finally, to discover whether the mailbox schema for an individual mailbox has been upgraded (following a logon), run the Get-MailboxStatistics cmdlet against the mailbox:

PS> Get-MailboxStatistics –Identity ‘TRedmond’ | Format-List DisplayName, CurrentSchemaVersion

DisplayName                          : Redmond, Tony
CurrentSchemaVersion                 : 0.126

All of the schema versions match so we know that the upgrade has been effective across the DAG.

This might all seem a tad prosaic, but it’s a mechanism that has been slipstreamed into CU3 and made available to on-premises customers after a lot of testing and careful observation in Office 365. Of course, Microsoft couldn’t afford to have the DAGs running in Office 365 be compromised by the need to upgrade database internals, so you can argue that this work had to be done to improve the reliability and robustness of the service. That’s true, but isn’t it also true that this is a good example of how innovation flows through the common code base from cloud to on-premises?

Truly, Office 365 is a remarkable test-bed for on-premises Exchange.

Follow Tony @12Knocksinna


About Tony Redmond

Lead author for the Office 365 for IT Pros eBook and writer about all aspects of the Office 365 ecosystem.
This entry was posted in Exchange, Exchange 2010 and tagged , , , , , . Bookmark the permalink.

9 Responses to Upgrading the database schema within an Exchange 2013 DAG

  1. Interesting Tony, even with all these of my DAGs fully upgraded to CU3, I see many DBs with the RequestedSchemaVersion of 0.125. It takes me running the updated-databaseschema command manually to get it to a CU3 version.

  2. Pingback: Upgrading the database schema within an Exchange 2013 DAG | Thoughtsofanidlemind’s Blog | JC's Blog-O-Gibberish

  3. Pingback: NeWay Technologies – Weekly Newsletter #77 – January 10, 2014 | NeWay

  4. Scott Schering says:

    A quick check shows 17 or my 33 databses are at 0.126 the rest are sitting at 0.125

    I guess I have some work to do.

  5. Mike DiVergilio says:

    Tony, I wonder what affect this update cmdlet has on the schema version for the search catalog. I’ve been getting informational messages regarding a new schema available for that. All my DBs are at the CU3 version, 0.126.

    A schema of newer version is available for the catalog of database d632cde5-4878-4fd0-8740-d68a70d2e7e2 (database-name). Current version is 4294967297(1,1); latest version is 42949672970(10,10).

    • No idea (because I haven’t seen this before). A superb trivia question to ask an Exchange developer at MEC?

      Seriously, the schema might be upgraded the next time the database is mounted. Then again, it might not.


      • Mike DiVergilio says:

        Sadly, can’t attend MEC this year. Middle of our deployment and just bad timing. I’ve had the DBs mounted and dismounted, which was required to upgrade the mailbox to the correct schema. There is so much still to understand about 2013 and still a bunch of issues to work through as well. Just opened my 41st case against 2013! Hopefully, I will get a chance to travel to TechEd or DevConnections. Enjoy Austin!

      • You know, maybe if you attended MEC you’d have to file fewer cases against Exchange 2013.

        The software is like any other release of Exchange – it takes time to settle down and for people to become accustomed to its quirks – and for Microsoft to sort out bugs. Exchange 5.5 was the last release that I can remember where the software could be deployed without a lot of concern about new stuff, new bugs, or new knowledge requirements. Once Exchange 2000 came along, all bets were off. Exchange 2003 was the worst release by far (didn’t settle down until SP2), Exchange 2007 was acceptable, Exchange 2010 was better but still badly needed SP1. Exchange 2013 is like Exchange 2010 with some of the “newness” that we experienced when Exchange 2000 delivered the Active Directory integration and all that… Life is full of circles.

        Connections will be much better for you than TechEd. I think TechEd is sadly overhyped. It is a marketing event above all. We hope to have the best independent commentators and experts at Connections, where at least you’ll hear the truth. It should be very much a marketing-free zone.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.