Database portability, as it applies to Exchange server, is the capability of taking a copy of a mailbox database from one Exchange server and using it as another mailbox database - whether on the same Exchange server or on another Exchange server.

I could write many thousands of words about database portability, but most of them would probably not apply to you! Let’s talk about what database portability probably means to you.

For Exchange 2000 and Exchange 2003, database portability only applied when all involved servers were in the same Administrative Group and the same Exchange Organization. While those restrictions still apply with Exchange 2007, the new Exchange 2007 requirement for all servers to be in the same Administrative Group (one that is hidden from normal view), causes that issue to be one that you are less likely to experience. Therefore, for most folks, Exchange 2007 only requires that a mailbox database be from the same Exchange organization. Effectively, this means that any Exchange 2007 mailbox database which was created within your Active Directory forest can be moved to any other Exchange 2007 server within your forest.

There are some interesting challenges within the process, if you choose to move a mailbox database from one server to another.

With Exchange 2000, were you to make this move, you would have to write a program or script which updated all relevant users in your Active Directory to point to the new database on the new server (there are a number of user attributes that define the specific mailbox database which a user is pointed to - they should all agree).

With Exchange 2003, you should either overwrite an existing Exchange database from a backup, or your database portability would only apply to a mailbox database from another server which is loaded into a Recovery Storage Group (RSG). If you were to make any other choice; you would have no automated way in which to access the content of the mailboxes in that mailbox database.

In Exchange 2003, the exmerge program has the capability to merge the contents of a mailbox existing in a RSG to a live mailbox as well as to export the contents of a mailbox in a RSG to a PST. This is the only supported mechanism for obtaining the content of those mailboxes.

In Exchange 2007, you also have the requirement of mounting a database into a RSG and using a tool (in that case, the recover-mailbox PowerShell cmdlet) to either merge the contents of a mailbox or export the contents of a mailbox to a PST. That is the only supported mechanism for acquiring the content of the mailboxes which are in a RSG.

Of course, there are tools from Quest, NetPro, OnTrack, AppAssure, and others; each of these programs would allow you to extract content directly from a mailbox database. However, those tools are not free.

Another option is a recovery server. You can create a server and create an Active Directory forest which has no connection to your production Active Directory forest. Install an Exchange server with the same organization and administrative group name as that of your production forest. At that point, you can mount the databases onto an Exchange server in that forest from any other Exchange server having a matching organization and administrative group name. If you create the necessary users, you can map the mailboxes in those mailbox databases to those users, and access them directly, using whatever tools you desire.

As with any disaster recovery, resiliency, or high availability solution, you should practice your usage of this technique well before you require it.