Moving Exchange Mailbox Databases Between Storage Groups in Exchange Server 2003
Microsoft® Exchange Server 2003 organizes databases (mailbox stores and public folder stores) into storage groups. Each Exchange server can have up to four separate storage groups, and each storage group can have up to five databases. The following figure shows how Exchange System Manager lists storage groups and databases.
Storage groups and databases (mailbox stores and public folder stores) in Exchange System Manager
.gif "9e982d24-e74e-4101-8973-0192097bfd23")
If you decide to reorganize your storage group topology, the preferred method is to move individual mailboxes to different storage groups rather than to move entire databases directly. After databases are empty, they can be deleted. However, it is possible to move a database to a different storage group.
Important
Moving a database between storage groups is not the same as moving database files, which is described in "Moving Store Files to a New Directory" in the Exchange Server 2003 Administration Guide. The procedure described in the Administration Guide affects only the physical file locations, not the organization of the databases and storage groups.
If you move an entire database, you must first delete all its mailboxes from Microsoft Active Directory® directory service. This does not destroy the mailbox contents, but breaks the link between each mailbox and its associated Active Directory user account. By default, Exchange preserves deleted mailbox content in the database for 30 days after deletion from Active Directory.
After you move a database to a new storage group, you can mount it and then reconnect the mailboxes to the previous Active Directory accounts using the Mailbox Recovery Center in Exchange System Manager. You can also reconnect mailboxes one by one using the Mailboxes listing for that database.
The biggest drawback to moving an entire database is that in-transit messages may be delayed, rejected, or never delivered. This situation occurs because you must delete mailboxes and then reconnect them at the end of the move operation. With careful planning, you can reduce the amount of time that mailboxes remain in the deleted state to a few minutes, but some messages can still be lost. To avoid this problem, you would have to shut down all mail transports throughout your entire organization during the time that the mailboxes are disconnected. It would not be enough to just stop mail flow on the involved servers. Because routing and delivery information is distributed throughout Active Directory, remote servers can detect that these mailboxes are no longer valid delivery destinations, and thus, incoming mail will be affected.
Even if there are drawbacks to moving databases for topology rebalancing, doing so can be useful in recovery scenarios. The remainder of this appendix explains what you can and cannot do safely when moving databases to another ordinary storage group or to a recovery storage group.