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