Moving an Exchange Mailbox Database to Another Server or Storage Group

 

Microsoft® Exchange Server mailbox databases are portable between servers that are running the same version of Exchange and that are in the same administrative group. A mailbox database created on one server in an administrative group can be renamed or copied to a different storage group on the same server or to a different server in the same administrative group. After this renaming or copying has been done, the links between user accounts and mailboxes must be reconfigured.

Moving entire mailbox databases to accomplish normal administrative tasks is not recommended. The Move Mailbox task is the recommended method for transferring mailboxes to different databases.

Move Mailbox can be done without database downtime and with minimal interruption to end user service. During a Move Mailbox operation, all end users are allowed full mail access except for the mailbox that is currently being moved. For more information about the Move Mailbox process, see Microsoft Knowledge Base article 821829, "Moving mailboxes in Exchange Server 2003".

In addition to the traditional move mailbox process, you also can move entire mailbox databases between servers or storage groups. After you move a mailbox database, you must re-link each mailbox in the database to an Active Directory® directory service user account before the mailbox will be accessible to an end user. For more information about re-linking mailboxes back to user accounts, see Using Active Directory Attributes to Enable, Disable, and Re-Home Mailboxes and How to Re-Home Exchange Mailbox Accounts.

Special limitations also apply for mailbox databases that host the System Attendant mailbox. For more information about the System Attendant mailbox, see Issues with the System Attendant Mailbox When Moving an Exchange Mailbox Database.

Creating and Replicating Public Folder Databases

This topic only covers moving mailbox databases. You should not move public folder databases between servers that are running Exchange. Microsoft does not support moving public folder databases between Exchange servers in the same Active Directory forest. Public folder databases replicate with each other, and moving databases to different servers can disrupt replication. Instead of moving a public folder database between servers, it is recommended that you create a new public folder database on a different server and then replicate folders to it.

Warning

If you want to move a public folder database to a laboratory server for test or data salvage purposes, you must never bring that database up again in the Exchange production forest, even on its original server. Running a public folder database in a different Exchange organization will cause it to gain knowledge of the system folders of that organization. When returned to the original organization, the folders in this database may conflict with the original organization’s system folders. This conflict may destroy the original system folders and force you to reset them. If this happens, you will have to reset and rebuild the calendar free/busy information and the offline address books for your entire organization.

For more information about replicating public folder content between servers, see the following Knowledge Base articles:

• 822444, "How to reset system folders in Exchange Server 2003"

• 275171, "XADM: How to Reset System Folders on an Exchange 2000 Server"

• 326637, "Resolve problems that are caused by duplicate free/busy folders and Offline Address Book folders on an Exchange Server 5.5 site"

• 152960, "Reassigning site roles after removing the first server in an Exchange site"

Disaster Recovery and Mailbox Database Portability

The mailbox database portability capabilities of Exchange may also be useful when designing a site resilience disaster recovery plan. In a site recovery scenario, the fundamental assumption is that an entire server that is running Exchange or even an entire geographical site has gone offline and will be offline for a prolonged period. Therefore, you must bring up Exchange resources on new hardware and in a new location.

As a best practice, your plan should be designed to avoid re-homing mailboxes during a disaster. If possible, you should restore or copy databases to new physical systems that retain the original Exchange installation configuration.

For more information about designing a disaster recovery or site resilience plan that does not require re-homing mailboxes, see How to Move All Exchange Virtual Servers from a Production Exchange 2003 Cluster to a Standby Exchange 2003 Cluster.

For Exchange servers that are not clustered, see Knowledge Base article 822945,"How to move Exchange 2003 to new hardware and keep the same server name." This article discusses use of the /DisasterRecovery setup mode to move an Exchange installation to new hardware while retaining the current Exchange installation configuration.

Moving Exchange Mailbox Databases Between Servers

When an Exchange mailbox database is created, naming information is written into it that identifies the database as a member of a particular Exchange organization and administrative group. The database can only be mounted on servers running Exchange that have been installed with the same organization and administrative group names.

However, an Exchange mailbox database is not tied to the server or storage group in which it was created. It can be transferred to any Exchange server that shares the same organization and administrative group names and is of the same major version and service pack revision or is of a higher version that is compatible with the original server.

Note

If you move a database to a different location by using an online backup, it will be necessary to configure the destination server with the same storage group and logical database names as on the original server. This requirement is a demand of the backup API, not inherent in the database itself. This requirement is explained in detail in Method 1 below.

However, after mounting a database on an up-level server, it is not possible to move the database back to a down-level server. Therefore, you should match server versions and patch levels exactly when moving databases, or treat the move as a one-way operation. Exchange 2000 Service Pack 3 databases are mountable on any server running Exchange 2000 Server or Exchange Server 2003 with a version level equal to or higher than the original server.

As viewed in Exchange System Manager, each Exchange 2000 Server or Exchange Server 2003 mailbox database is hosted in a storage group on a particular server. The database has a logical name that corresponds to an Active Directory database object. The database is composed of two physical files, which are a database file (.edb file) and an accompanying streaming database file (.stm file). You can view the path to these files and the filenames on the Database properties page of each database object.

There are three methods for moving Exchange databases to different storage groups or servers:

• **Restore an Exchange-aware online streaming backup of the database, redirecting the restore location to a different server   **For this method to work, the new server must be configured with a storage group and logical database whose names are identical to those on the original server.

  For example, you make an online backup of a database with the logical name “Mailbox Store (Server A)” in storage group “Server-A-SG1” on Server A. You may then create a storage group called “Server-A-SG1” on Server B, and then create a database in that storage group called “Mailbox Store (Server A).”

  You restore the online backup, changing the restore location to Server B, and the backup will be restored to the matching storage group and logical database names on Server B.

• **Restore an Exchange-aware online Volume Shadow Copy Service (VSS) backup of the database   **Exact methods for doing this will vary depending on vendor capabilities and limitations in restoring database files to other than their original locations. Consult with your backup vendor for specific instructions.

• **Copy Exchange database files from the current path location to the path location for a different logical database, storage group, or server   **If you use this method, the logical storage group and database names do not have to match, but the database filenames must match those defined in the destination. You may rename database files as necessary to make them match.

  For example, database files named “Priv1.edb” and “Priv1.stm” are associated with the logical database “Mailbox Store (Server A)” in storage group “Server-A-SG1” on Server A. You create a Storage Group called “Server-B-SG1 on Server B, and create a database called “SG1-MB1” in that storage group. The file paths listed for the SG1-MB1 database are “F:\Databases\SG1-MB1.edb” and “F:\Databases\SG1-MB1.stm.”

  You copy Priv1.edb and Priv1.stm from D:\Databases on Server A to F:\Databases on Server B. You then rename Priv1.edb to SG1-MB1.edb and rename Priv1.stm to SG1-MB1.edb.

When performing the procedures described in this topic, it is recommended that you consider the following:

• When restoring or copying a database to a different location, it may be necessary to select the check box for This database can be overwritten by a restore before you can restore the database from online backup or before the database can be mounted. This checkbox is located on the Database properties page for the logical database object. If you are unable to restore or mount a moved database because of this reason, the problem will be logged in the server’s application log.

• Before copying database files to another location, you should ensure that they are in a consistent or clean shutdown state. For more information about these states, see the “Database States” section of Knowledge Base article 240145, "How to remove Exchange Server transaction log files."

  It may also be possible to replay additional transaction logs into a database before or after it is copied or restored to an alternate location. For more information, see Issues with Transaction Log Files When Moving an Exchange Mailbox Database.

• Before starting the move process, stop the destination database, remove the existing database files and mark the database to not start automatically. This will prevent the database from inadvertently coming online during the move process.

• When moving databases to an alternate location, in-transit mail may become undeliverable or become lost. To minimize the effects of this problem, you should link user accounts to the new database location as early as possible in the move process. You can do this before shutting down or moving the original database. Doing so will prevent client access to all mailboxes in the database until the move process has completed. For more information about this, see Using Active Directory Attributes to Enable, Disable, and Re-Home Mailboxes.

• Exchange generates several different mailboxes for performing various system functions, including SMTP, System, and System Attendant mailboxes. After moving a database to a new location, there may be “leftover” mailboxes for these functions in the database. The Mailbox Cleanup Agent will eventually disconnect these mailboxes, and they will be purged 30 days later by default. It is not necessary to manually disconnect or purge these mailboxes.

• As a best practice, you should reboot an Exchange server as soon as is feasible after completing a database move. Core client connectivity and mail delivery functions will work without requiring a reboot, but other system functions and third-party applications may require it.

For More Information

For information about the interaction of Move Mailbox and the mailbox tombstone table, see Move Mailbox Operations and the Mailbox Tombstone Table.

For more information about methods you can use to enable, disable, and re-home mailboxes, see Using Active Directory Attributes to Enable, Disable, and Re-Home Mailboxes.