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\15M31Status : MountedMinimumSupportedDatabaseSchemaVersion : 0.121MaximumSupportedDatabaseSchemaVersion : 0.126RequestedDatabaseSchemaVersion :
Identity : D12 MBX Store 18\D15M41Status : HealthyMinimumSupportedDatabaseSchemaVersion : 0.121MaximumSupportedDatabaseSchemaVersion : 0.126RequestedDatabaseSchemaVersion :
Identity : D12 MBX Store 18\15M30Status : HealthyMinimumSupportedDatabaseSchemaVersion : 0.121MaximumSupportedDatabaseSchemaVersion : 0.126RequestedDatabaseSchemaVersion :
Identity : D12 MBX Store 18\D15M40Status : ServiceDownMinimumSupportedDatabaseSchemaVersion :MaximumSupportedDatabaseSchemaVersion :RequestedDatabaseSchemaVersion :
[PS] D:\data\scripts>Get-MailboxDatabase $m.database -status | FL *schema* CurrentSchemaVersion : 0.126RequestedSchemaVersion : 0.126
[PS] D:\data\scripts>Get-MailboxStatistics $m | FL *schema* CurrentSchemaVersion : 0.126
Hopefully this helps understanding what this is for!