Moving an Exchange Server 2007 Database between Mailbox Servers


The database portability in Exchange Server 2007 together with Outlook 2007 allows administrators to move a database between servers quickly and easily. Exchange Server 2007 allows the mounting of any database from the same Exchange organization.

This feature may be useful in some disaster recovery scenarios where you want to decrease downtime and get your clients working as soon as possible. However, this article will not focus on a high availability solution, but, as mentioned, this feature may be an option in some disaster recovery scenarios.

If you want to create a high availability strategy, you have to consider technologies such as LCR (Local Continuous Replication), SCC (Single Copy Cluster), CCR (Cluster Continuous Replication) or SCR (Standby Continuous Replication). Note: SCR is a new feature that will be available in Exchange Server 2007 SP1.

Exchange Server 2003 database portability

In Exchange Server 2003, portability was not easy. We needed to fulfill some prerequisites before starting the process of moving a database to another server.

The prerequisites for Exchange Server 2003 are:

  • The servers must belong to the same Administrative Group and Exchange Organization

  • We have to modify some Active Directory attributes for the affected users (msExchHomeServerName, homeMTA and homeMDB). These are user attributes related to the database (or server) location of the new Exchange Server

  • We have to manually change all of the client settings to use the new server

There is a Knowledge Base article explaining the procedure mentioned above for an Exchange Server 2003 environment. It can be found at the Microsoft Support Website:

Exchange Server 2007 mailbox portability

The whole process of moving a database in Exchange Server 2007 is simplified, if we compare it with the same process for previous Exchange Server versions. For Exchange Server 2007, the only prerequisite for moving a mailbox database between servers, is that both servers must be in the same Exchange organization.

The problems related to the user attributes affected by the database change are addressed through a parameter called –configurationonly on the move-mailbox cmdlet.

On client side (for Outlook 2007 users) the problem is automatically solved by the AutoDiscover Service in Exchange Server 2007; for previous Outlook versions, the users had to manually configure all the changes.

For OWA clients there is no change, because the Client Access Server (CAS) will change the settings to the correct mailbox server.

Remember that even with all these new features, this process must be completed to minimize downtime and it is not a simple procedure.

Note: You can only move mailbox databases, Public Folders are not portable.

Moving a database between Mailbox Server in Exchange 2007

Now that we have seen how it works for Exchange Server 2003 and 2007, we will review a step-by-step procedure on how to move databases between two mailbox servers and how Exchange 2007 helps us decrease the downtime involved in this process.

We are going to discuss a scenario (Figure 01), where we have two mailbox servers (srv-mbx01 / srv-mbx02), and another server which has the CAS role (srv-cas) that provides the autodiscover services and protocol access to our clients. The users (for the purposes of this article) will be Anderson.Patricio and Jose.Rodas. They belong to a mailbox database called Sales which is located in the srv-mbx01 mailbox server.

Let’s suppose that this server experiences a hardware failure. So, we will have to move the database on this server to another Mailbox server. Our objective is to do it with the least effort and impact on our users.

Figure 01: Scenario where we are going to move a database between mailbox servers

On Exchange Server Srv-MBX01 we are going to check the number of messages and mailbox size of user Anderson.Patricio who has a mailbox on srv-mbx01 in the sales database. (Figure 02).

Figure 02: The total number of items and size of Anderson.Patricio’s Mailbox

So now, we are going to start the database move process between the Exchange Server 2007 computers. Note: During this period the messages sent to users who are in the mailbox sales database in the srv-mbx01 will not be delivered.

First of all, we have to be sure that that our mailbox database is in a “clean shutdown” state. We can get a database in that state through various ways, for example with an online or offline backup.

In this article, we will dismount the sales database, and copy the sales.edb file. But we must verify the status of the mailbox database using our old friend eseutil with the /mh switch (eseutil /mh <database name>) (Figure 03).

Figure 03: Verifying that the mailbox database “sales” is in Clean Shutdown

Now, we are going to copy the sales.edb file containing all of the users’ messages to a new server, called srv-mbx02. Then, we will create a new mailbox database with the same name as the original one.

To do so, we will follow these steps:

  1. Log on to the Srv-mbx02 server

  2. Open the Exchange Management Console

  3. Expand Server Configuration

  4. Click on Mailbox

  5. Click on Srv-MBX02 and, into Result Panel, click on First Storage Group

  6. In the Toolbox Actions, click on New Mailbox Database

  7. We must complete the name of the original mailbox database located in the srv-mbx01. For the purposes of this example, the name will be “Sales”. Take a note of the path where this database will create the file. Clear the checkbox called Mount this database. After that, click New (Figure 04)

Figure 04: Creating a database in the new server

  1. Completion. This will be the final page of our process of creating a mailbox database in the srv-mbx02 server. Click Finish. (Figure 05).

Figure 05: Final screen showing that the new mailbox database “Sales” was created on srv-mbx02 server

Now, we can check the Properties of our newly created database from Toolbox Actions. We can click on the checkbox This database can be overwritten by restore (Figure 06).

Figure 06: Preparing the mailbox database switch

So now our database has been successfully created on the new server, and we must now copy the sales.edb file of the original server into the srv-mbx02 server. The path where we will copy the original *.edb file must be the same as that which we defined in the database creation process (Figure 04). Finally, we have to mount the database, click on sales database and in the Toolbox Actions click on Mount Database. The result expected will be as follows in Figure 07.

Figure 07: The mailbox database sales mounted on the new server

During the process of moving the database to another server, our users experienced some issues in their clients. The following are some examples of that. First is the error message for Outlook Web Access (Figure 08) and also the error message for Outlook 2007 (Figure 09).

Figure 08: Message error that appeared in the OWA connection

Figure 09: Message error that appeared in the Outlook 2007 client

Although the mailbox database is mounted on the new server (srv-mbx02), all of the users’ attributes are set to the other server. So, we will have to change these settings to set those attributes on the new server.

We can do this using the follow cmdlet:

get-mailbox –database <old database> | move-mailbox –targetdatabase <new database> -configurationonly:$true

Figure 10: Moving the configuration for all the mailboxes from srv-mbx01\sales to srv-mbx02\sales

Now, we can validate if user Anderson.Patricio has been updated to the new server (Figure 11). The user has changed the Exchange Server name and mailbox database but the data is still the same, because the only change was the database move between servers.

Figure 11: The user Anderson.Patricio with his new attributes

After moving the database to the new server and correctly configuring the user settings, the Outlook 2007 clients are going to get a message asking for an application restart (Figure 12).

Figure 12: Message dialog box warning user to restart his/her Outlook 2007

After restarting Outlook 2007, we can check if we are being connected to the new server through connection status. To get this applet, we should CTRL + Right Click on the Outlook icon in the system tray. (Figure 13).

Figure 13: Checking Outlook clients with the new settings

In the OWA environment, we just need to log on again and we will be able to access the mailbox normally on the new server.

After our tests, we can evaluate the results of moving databases between servers on the following environments:

  • Microsoft Outlook 2007 clients will be redirected by the AutoDiscover Service, without requiring user intervention

  • OWA clients will be automatically redirected to the new server, because of the Client Access Server

  • Outlook legacy clients must be manually configured because they do not have the ability to use the AutoDiscover service

Fixing Search issues after a database move

After the database move between srv-mbx01 and srv-mbx02 servers, our users may be getting this kind of error in the Outlook Web Access Search feature (Figure 14).

Figure 14: Some users may experience this problem in the OWA search feature

To reset the Exchange Search Service, we can use a script called ResetSearchIndex.ps1 which is located in the scripts folders under the Exchange Server 2007 installation directory.

The full syntax of the script is:

.\ResetSearchIndex.ps1 –force sales,

Where sales is the mailbox database name

Figure 15: Resetting the Microsoft Exchange Search Indexer using the EMS for the new database


In this article we’ve reviewed the step-by-step procedure for moving a mailbox database between Mailbox Servers in an Exchange Server 2007 environment. We have discovered that this process is easier than the same process in previous versions, and the objective of this process is to decrease the downtime in an Exchange Server 2007 environment by using less administrative effort.

More Information:

CCR Deployment:

SCC Deployment:

Using the /RecoverServer Switch

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top