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.
Review the complete blog at http://blogs.technet.com/b/exchange/archive/2014/01/13/exchange-2013-database-schema-updates.aspx
Read my favorites blogs:
Assigning File Share permissions using Power Shell
Designing a backup less Exchange 2010 Architecture
Step by step guide for upgrading Active Directory from Microsoft Windows 2003 to Microsoft Windows Server 2008
Microsoft Exchange 2010 CAS Array – Steps and Recommendations
Appear Offline in Microsoft Office Communicator Server 2007
Microsoft Exchange 2010 Test cases
Microsoft Exchange Server 2010 Disaster Recovery
Microsoft Exchange Server 2010 Upgrade Guide