Recently, a user informed me that hundreds of items were missing from the Calendar of an Exchange Server 5.5 mailbox. The mailbox's Information Store (IS) was configured to retain deleted items, but I couldn't find any deleted items to recover. The items didn't appear to be in any offline folders store (.ost) or personal folder store (.pst) files, and the users who had access to the mailbox were sure they hadn't moved the items. Eventually, I discovered that someone had performed a hard delete of the missing Calendar items, which weren't recoverable because Deleted Items Recovery had been enabled only for the Deleted Items folder. (See the Microsoft article "XADM: How to Recover Items That Are Not First Transferred to the Deleted Items Folder" at http:// support.microsoft.com/?kbid=178630 for a discussion of this type of situation.) Consequently, I needed to restore the deleted items from backup.
Our Exchange application runs on a Windows 2000 Server machine with a tape backup drive, and I use VERITAS Software's Backup Exec 8.6 with the Agent for Microsoft Exchange to perform online backups of Exchange to tape. I recently had set up a Windows NT Server test server that I could use as a recovery server but didn't want to rebuild it as a Win2K Server machine (I planned to use it as a hot spare while I rebuilt another NT server); furthermore, it didn't have a tape drive. So I decided to determine whether I could restore the IS over the network to the recovery server—even though that server was running a different OS version and service pack from the Exchange production server—without bringing down the production server. I discovered that such a restoration, although it contradicts the Exchange 5.5 disaster-recovery information I've read, is indeed possible.
I tested the technique only on Exchange 5.5 by using Backup Exec; you should be able to use NTBackup to perform a similar recovery, but I didn't test that scenario. Be aware that Microsoft doesn't support the methodology I used to restore the missing Calendar items. In some cases, my methodology actually contradicts Microsoft's documented recommendations and works around some restrictions inherent to restoring Exchange databases to a different server. Also, restoring to a recovery server with a different OS version and service pack configuration increases the time required to restore the IS. Despite these caveats, I believe that this process can benefit Exchange administrators who don't have a spare recovery server that's running the same OS version and service pack as the Exchange server and a matching tape drive. Of course, restoring from backup should always be a last resort, and both systems must run the same Exchange 5.5 service pack.
Preparation
Before I could use Backup Exec to perform an online Exchange database restore, I needed to license the Agent for Microsoft Exchange by installing its serial number on the Backup Exec server. I also needed to install a remote agent serial number on the Backup Exec server to redirect the restore to a different server and make sure that the remote agent was installed and running on the recovery server. Backup Exec requires both a remote agent and the Microsoft Exchange Agent to restore Exchange data over the network to a different server; both options require separate licenses from VERITAS. To install the remote agent, I ran the setupaa.cmd script (in the \winnt\install\eng\i386\ntaa folder on the Backup Exec CD-ROM). To start the service without rebooting, at the command prompt I entered
net start
BackupExecAgentAccelerator
Before I began, I needed to have at least one complete and successful online IS backup to restore to the recovery server. Depending on the backup method you use and the size of the backup, a backup could require more than one tape.
Next, I installed Exchange on the recovery server by running setup.exe from the \server\setup\i386 folder on the Exchange 5.5 installation CD-ROM. I didn't run Setup /R, which is intended for a full restore on the same server or a new server with the same name. I selected the Complete/Custom option and used the Exchange service account for the existing site to install only the Exchange Server and Administrator options. In addition, I used the production server's organization and site names to create a new site. I didn't select Join an existing site when I installed Exchange because I didn't want the recovery server to replicate data with the production server.
I installed Exchange 5.5 Service Pack 4 (SP4) on the recovery server because the restored database version must match the Exchange version running on the recovery server. I stopped all Exchange services except the System Attendant and Directory (the Directory service, which has a dependency on the System Attendant, must be running for Backup Exec to recognize the recovery server as an available network server for the redirected restore). At this stage, the recovery server was ready to receive the restored data.