Exchange recovery servers

By Jerry Cochran 01 Nov 2004 | SearchExchange.com

Digg This!     StumbleUpon     Del.icio.us

The following is tip #19 from "20 tips on protecting and recovering Exchange data in 20 minutes," excerpted from the book, "Mission Critical Microsoft Exchange 2003" (Digital Press, a division of Elsevier, Copyright 2004). For more information about this book and other computing titles, please click here. Return to the main page for more tips on this topic.

Providing individual brick-level mailbox and message recovery can be the most challenging of these scenarios. Many third-party solutions exist for mailbox or message-level recovery, but most are far from perfect. In addition, Microsoft does not really provide a solution either -- instead leaving this gap open to the third-party developers.

However, there is a solution for this problem scenario that should be your best practice regardless of which version of Exchange Server you are running. This solution is called the Exchange recovery server and it can be a very useful tool for every Exchange administrator.

The idea behind the Exchange recovery server is that you maintain a spare server in your environment that is available as a target location to perform recovery operations. Regardless of which version of Exchange you run, you can recover an information store from one server to another server. Once this information store is recovered to the recovery server, you can then perform recovery for complete mailboxes or just individual messages by extracting these items from the store using Outlook or programs like ExMerge.

Of course, Exchange 5.5 provides recovery and retention for deleted items, and Exchange 2000 adds mailbox retention to this. However, since even these two mechanisms might not meet all of your disaster recovery requirements, it is nice to know that the recovery server option is available.

Exchange 5.5 recovery servers
The recovery server capability is available for any version of Exchange. However, the configuration and setup of your recovery server will vary depending on whether you are using Exchange 5.5 (and earlier versions) or Exchange 2000.

Let us start our discussion with Exchange 5.5 and earlier versions since this is the version that the majority of you are using. With Exchange 5.5 and earlier versions of Exchange, the recovery server can be any server (member server of domain controller) in the same domain as the original server you are recovering.

However, the recovery server must have a different name from that of the server being recovered (you don't want this server to start participating in the Exchange organization and doing directory replication, and so forth). You configure this recovery server by installing it with the same organization and site naming conventions and hierarchy as the original server (but a different server name) and organization but you do not join this server to the production organization. The result will be a server with the different name, but the same site and organization name as the original. This might seem confusing, but the server will not interfere with your existing Exchange organization because it was not specifically joined to it during installation. This allows the server to function in the environment without causing problems for the production Exchange 5.5 deployment (you can even use the same Exchange Service account).

Once the recovery server is installed and properly configured, you can restore an information store to the server. However, the directory database on this server will not have any objects (remember, you did not join this server to the existing organization). You can easily remedy this by either manually creating mailbox objects in the directory that match the ones you want to recover (the Distinguished Name or DN is the only attribute that must match).

Alternately, you can run the Exchange 5.5 DS/IS Consistency Adjuster (in the Exchange Administrator program) to automatically generate mailbox objects in the directory for each one found in the information store. These procedures will link information store mailboxes to directory objects on the recovery server. From this point, you can simply install the Outlook client on the server or use tools such as ExMerge to extract mailbox data to personal store files (PSTs) and import the data back to the production Exchange server into the appropriate mailboxes.

Exchange 2000 recovery servers
Deploying a recovery server for Exchange 2000 operates on the same principles as earlier versions. However, several things are different in Exchange 2000.

The first issue has to do with Exchange 2000's dependence on the Windows AD. Since you can have only one Exchange organization per AD forest (as things are today -- hopefully, someday this will not be the case), we are forced to deploy a completely separate AD forest for our Exchange recovery server(s). This should not be that big a deal since the recovery forest can exist right along side our production forest, and it is a good idea to have a test environment available anyway.

However, you will need to determine the administrative impact this has on your organization. The other key differences in Exchange 2000 involve the change from sites (in previous versions of Exchange Server) to administrative groups (in Exchange 2000) and the ability to have more than one information store per server. This adds additional steps to the configuration of an Exchange 2000 recovery server, which I will discuss next.

The first step in deploying and Exchange 2000 recovery server is to deploy your recovery forest. You must have a separate forest when installing your Exchange recovery server or you will be forced to join the existing production Exchange organization.

The recovery forest can have any naming convention and need not match naming conventions in the production forest (it can even exist on the same network). Once you have your Exchange 2000 recovery forest deployed, you can install your Exchange 2000 recovery server into the forest with the same organization name as the production server you will be restoring (remember, this is the Exchange organization naming -- not the AD naming). The server name can be the same or different as there will be no conflicts with the production server (other than potential DNS issues if it is on the same network).

If you are going to keep the recovery forest up and running permanently, I recommend that you install a permanent recovery server into the recovery forest that maintains a permanent name and is the fi;rst server in the organization. I also recommend that the naming conventions and administrative group hierarchy match your production Exchange 2000 organization. This will be of huge benefit in the steps I discuss next. When you have a permanent server installed that maintains organization naming and hierarchy, a second recovery server can be installed for each incident to match the naming of the server being recovered. This will alleviate issues with LegacyExchangeDN discussed next.

After the recovery forest and server(s) have been configured, you can perform a restore of the information store database into an administrative group with the same name as the one where the database was taken from. However, from a database and AD point of view, the LegacyExchangeDN values for the administrative group and the database must match.

In addition, the storage group and database names must also match those on the original server. If you have taken steps as outlined earlier to maintain a permanent recovery server in the recovery forest (that matches the naming and hierarchy of the production organization) and have installed a second recovery server to the same administrative group, storage group, and database as the production server, these values will match.

However, in the event that you do not wish to maintain this extra recovery configuration, the LegacyExchangeDN value can be updated manually using an LDAP editing utility such as LDP, ADSI Edit (Windows 2000 Support Tools), or LDIFDE (installed by default in Windows 2000) to view and edit this value for the database and administrative group. In addition, Microsoft provides an unsupported tool called LegacyDN.EXE (available with Exchange 2000 SP1 or later) that provides an easy-to-use interface for changing this attribute (note really made for this purpose -- which is why it is not supported).

Regardless of which tool you choose, the Exchange 2000 organization name, administrative group name, storage group name, database name and LegacyExchangeDN values for the production environment and the recovery server must all match for the database being restored. For more information on the procedure to modify LegacyExchangeDN values, see Appendix A: Changing the LegacyExchangeDN Attribute Values in the white paper Exchange Database Recovery. Once you have restored the information store database to the recovery server, you can proceed to link mailbox objects to mailboxes similar to the Exchange 5.5 recovery scenario. However, for Exchange 2000 and AD, the procedure is different. In earlier versions of Exchange, the mailbox object is linked to a DN and only directory objects with the same DN are required to link mailboxes to directory objects.

In Exchange 2000, this is not the case, and you must explicitly connect a mailbox in the database to a directory object. You can do this manually if you are recovering a small number of mailboxes by creating a user object that is not mailbox-enabled (using the AD Users and Computers MMC Snap-in). After creating a user object, it is a good idea to run the mailbox cleanup agent from the Exchange System Manager.

Afterward, you should be able to see mailboxes in the restored database that have a red "X" indicating they are orphaned, or not connected to any user object. From this point, you merely right-click on the mailbox object, choose reconnect, and select the user object that you wish to connect to the mailbox. Of course, if you are recovering many mailboxes, you might want to use something like the Mailbox Reconnect Tool (MBConn -- available on the Exchange 2000 CD) to save you some keystrokes and mouse clicks. Once mailboxes are connected to user objects, you can extract data from them in the same manner as we discussed in the Exchange 5.5 recovery server scenario (using Outlook, ExMerge, and so forth).

We have taken a closer look at the concept of a recovery server for your Exchange environment. As an Exchange administrator, you should take this concept to heart and implement Exchange recovery servers as a best practice in your environment -- regardless of which version of Exchange you have. In addition to being an important recovery facility for your Exchange environment, the recovery server scenario also provides a great nonproduction testbed that is useful in other situations. If you are not using Exchange recovery servers as part of your everyday life as an Exchange administrator or encouraging your customers to use this best practice, you might consider the benefits this solution can bring to you and your customers. The recovery server concept may seem like extra trouble. However, if you desire to provide this level of disaster recovery for your Exchange users, the recovery server concept can be a lifesaver.

Get more "20 tips on protecting and recovering Exchange data in 20 minutes." Return to the main page.

About the author: Jerry Cochran is a contributing editor for Windows IT Pro and Exchange & Outlook Administrator and a group program manager for Microsoft. He is the author of Mission-Critical Microsoft Exchange 2000 (Digital Press).

Digg This!     StumbleUpon     Del.icio.us

RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary