One option for moving Exchange Server 2003 databases is to install Windows onto a new server and then assign that server the same name as the failed server. Because a computer account already exists in the domain, you should not join the server to a domain initially. If you do join the server to a domain, you will have to get rid of the old computer account, which will eventually cause problems related to a global unique identifiers (GUID) mismatch.
This technique assumes that you have a full backup of the server. If you only have a backup of the Exchange Server databases, you can still use a variation of this method.
Rather than trying to preserve the previously existing computer account, get rid of the account and join the new server to the domain. You must then install Microsoft Exchange Server and apply any Exchange Server service pack that was running on the failed server. It is critical that the new server uses the same service pack level as the failed server. Furthermore, both servers must be running Exchange Server SP2 or higher.
To restore the Exchange Server database, you must follow these steps:
- Once Exchange is up and running with the correct service packs applied, create a new database on the empty Exchange server. You must assign this database the same name as the database from the failed server.
- Right-click on the new Exchange database and select Properties.
- Next, choose the This Database Can be Overwritten by a Restore checkbox and click OK. Now you can perform the disaster recovery operation.
There is one problem with this method: It can be a pain to get the Exchange databases back to an operational state. There's another database portability option that works better, however. It requires that you install Windows onto a new server and assign it a name that's different from any of the server names that you are currently using on your network. From there, install the same Windows service pack that was running on the field server and then install Exchange Server along with the appropriate service pack on the new server. Finally, create an empty database that uses the appropriate database name and then restore your backup.
Basically, you temporarily move a database from a failed server to another server in your organization. Rather than dealing with identical server names, security identifiers (SIDs) and GUIDs, it is easier to restore the database to a different server altogether. If you use this technique, though, the new server must be in the same administrative group as the failed server.
Regardless of whether you try to duplicate the name of the failed server or set up a new server with a new name, there is some cleanup work that is required after the database recovery process is complete. Specifically, each recovered mailbox must be relinked to an Active Directory user account. You may also have to configure Microsoft Outlook on the users' workstations to point to the new mailbox location.
About the author: Brien M. Posey, MCSE, is a five-time recipient of Microsoft's Most Valuable Professional award for his work with Exchange Server, Windows Server, Internet Information Services (IIS) and File Systems and Storage. He has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. As a freelance technical writer, Brien has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal website at www.brienposey.com.
Do you have comments on this tip? Let us know.
Please let others know how useful this tip was via the rating scale below. Do you know a helpful Exchange Server, Microsoft Outlook or SharePoint tip, timesaver or workaround? Email the editors to talk about writing for SearchExchange.com.
This was first published in November 2008