Exchange 2013 database schema updates

Recently, we have seen some questions about what the Update-DatabaseSchema cmdlet in Exchange 2013 is about. So I thought I would share some additional information on the subject.

The Update-DatabaseSchema cmdlet is a part of the infrastructure that we’ve built into Exchange 2013 to safely upgrade database schema in a DAG deployment. Unlike previous releases, a database schema upgrade in Exchange 2013 can only occur after all DAG members are upgraded to a version of software that supports the schema version and there is control over when the schema upgrade occurs (setting RequestedDatabaseSchemaVersion to a value higher than CurrentSchemaVersion up to the MaximumSupportableDatabaseSchemaVersion supported by all members of DAG). The RequestedDatabaseSchemaVersion of a database cannot be incremented to a value higher than the minimum of MaximumSupportableDatabaseSchemaVersion supported by any DAG member. This design prevents issues like those encountered during upgrade Exchange 2010 DAG members to post-RTM service packs and automatically upgrading database schema version when mounting database on an upgraded server (no longer able to mount on a server that has not yet been upgraded).

The initial database schema version will be based on the server version(s) deployed in the DAG. The Exchange 2013 RTM database schema version is 0.121 and can be displayed using get-MailboxDatabase or get-MailboxDatabaseCopyStatus in CU2 and later. MaximumSupportableDatabaseSchemaVersion has incremented in each CU release, so databases created with server versions after RTM may be created with a schema version higher than 0.121. Prior to CU3, the Update-DatabaseSchema cmdlet could be used to manually set RequestedDatabaseSchemaVersion value higher than CurrentSchemaVersion (version at database creation). In CU3, setup (during build-to-build upgrade) was modified to automatically request upgrade of database schema version on existing databases to MaximumSupportableDatabaseSchemaVersion (0.126) for databases created with a lower schema version. By design, the attempt to set RequestedDatabaseSchemaVersion to 0.126 only succeeds when the last member of DAG is upgraded to CU3. All database schema upgrades are serial and are performed at mount time after a RequestedDatabaseSchemaVersion value is set, so an upgrade from 0.121 (RTM) to 0.126 (CU3) will involve 5 distinct schema upgrades (transactions).

It should be noted that database schema upgrades only involve global tables in a database. There is also a schema associated with tables associated with each mailbox and a mailbox schema upgrade can modify any table associated with a mailbox. After a database schema upgrade is performed during database mount, corresponding mailbox schema upgrades can be performed on subsequent logon to a mailbox. The schema version of a mailbox can be displayed using get-MailboxStatistics and will match the database schema version after first logon occurs after database schema upgrade completes.

We internally have the ability to control the MaximumSupportedDatabaseSchemaVersion for each target environment (test, dogfood, production service, on-premises) where an Exchange Server can be deployed explicitly and only increment the value supported in an environment in a given build after we have built high confidence with that change. We progressively built high confidence in the safety of performing a schema upgrade in our test, dogfood and Exchange Online environments and completed in-place database schema upgrades in Exchange Online prior to shipping CU3. It was this validation in our production service that led to the decision to enable this automated upgrade for our on-premises customers so that they could begin to reap the benefits enabled by these schema changes. This same validation will be performed for any schema upgrades included with future CU/SP releases.

You might ask yourself at this point: what are those benefits? Since the release of Exchange 2013, we have used database schema upgrades to help tweak performance on the database level, and envision that we will continue to do so in the future. Another thing to note is that we will not be automatically incrementing the version at every release (a cumulative update or a service pack) but will change the schema only when there is a specific benefit to be had.

The following shows the cmdlets that can be used to display the schema versions supported by servers hosting each database copy, the schema version of each database, and schema version of each mailbox.

[PS] D:\data\scripts>$identity = "forest noll"
[PS] D:\data\scripts>$m = get-mailbox $identity
[PS] D:\data\scripts>Get-MailboxDatabaseCopyStatus $m.database | FL Identity,status,*schema*

Identity : D12 MBX Store 18\15M31
Status : Mounted
MinimumSupportedDatabaseSchemaVersion : 0.121
MaximumSupportedDatabaseSchemaVersion : 0.126
RequestedDatabaseSchemaVersion :

Identity : D12 MBX Store 18\D15M41
Status : Healthy
MinimumSupportedDatabaseSchemaVersion : 0.121
MaximumSupportedDatabaseSchemaVersion : 0.126
RequestedDatabaseSchemaVersion :

Identity : D12 MBX Store 18\15M30
Status : Healthy
MinimumSupportedDatabaseSchemaVersion : 0.121
MaximumSupportedDatabaseSchemaVersion : 0.126
RequestedDatabaseSchemaVersion :

Identity : D12 MBX Store 18\D15M40
Status : ServiceDown
MinimumSupportedDatabaseSchemaVersion :
MaximumSupportedDatabaseSchemaVersion :
RequestedDatabaseSchemaVersion :

[PS] D:\data\scripts>Get-MailboxDatabase $m.database -status | FL *schema*
CurrentSchemaVersion : 0.126
RequestedSchemaVersion : 0.126

[PS] D:\data\scripts>Get-MailboxStatistics $m | FL *schema*
CurrentSchemaVersion : 0.126

Hopefully this helps understanding what this is for!

Todd Luttinen

Comments (17)
  1. Anonymous says:

    Good article for Exchange On-Premises customers, Thanks.

  2. Anonymous says:

    I’ve informed some folks, but performing a CU3 upgrade on 2 ten server DAGs from CU2, the database schemas were not updated even after remounting the databases. Some DBs showed the MaximumSupportedDatabaseSchemaVersion as 0.125. I had to perform the update via poweshell post install.

  3. Anonymous says:

    thanks for sharing! :) good article.

  4. Anonymous says:

    Good article. So in a multi-member DAG environment is the patching recommendation still the same? Use the StartDagServerMaintenance.ps1 , apply the updates, then use StopDagServerMaintenance.ps1 .

    Then run Update-DatabaseSchema and if necessary RedistributeActiveDatabases.PS1.

    Is that correct or am I missing something?

  5. Anonymous says:

    Nice article!! Good Info

  6. Anonymous says:

    Very well written & good information.

  7. Anonymous says:

    So what is the recommendation for patching now. Maybe this can be updated to give an example of the patching. Seems like after all Nodes have been patch, should you do a dismount/mount of all the DB’s in the DAG?

  8. Anonymous says:

    any update about Exchange 2013 SP1 release date??

  9. Anonymous says:

    Good to know information right here!

  10. Anonymous says:

    it would be awesome if a set-moverequest could utilize the “AllowIncrementalSyncs” switch.

    I know that you can use it with a batch, but not sure why you cannot do it with a single.

  11. Anonymous says:

    Good Article….. Thanks buddy…

  12. Anonymous says:

    it would be awesome if a set-moverequest could utilize the “AllowIncrementalSyncs” switch.

    I know that you can use it with a batch, but not sure why you cannot do it with a single.

  13. heynow says:

    Good info
    oops forgot to say
    “Exchange On-Premises customers” :)

  14. John says:

    Yep good info for Exchange On-Premises customers :-)

  15. pesospesos says:

    Hello team, it appears that CU3 altered the GUI in auto attendant menu navigation options so that we can no longer enter a 10 or 11 digit number to transfer to (we are limited to 4 digits as our dial plan is a 4 digit plan). This is an artificial limit only in the GUI as the engine continues to transfer to 11 digit numbers carried over from our 2010 migration, and PSS (after four weeks of trying to finally get the case escalated) has worked with us to discover that using adsiedit and XML editing we can make changes to the numbers that work around this pointless and frustrating change. Can the team speak to why this change was implemented and if it can be reversed in a future update?

  16. SP1 Fan says:

    Nice article, now where’s SP1?

  17. pesospesos says:

    Can someone please check PSS case 113122011043395 and advise if this will be fixed in SP!?

Comments are closed.