Wouter’s Blog

Yesterday I was called out to recover a server from a disaster crash by one of our customers. I figured I would write something here because maybe someone some day will have a use for this information.

The server itself was a Small Business Server and handled everything, Exchange 2003, Domain Controller, Fileserver. That happens in small environments but is far from ideal, because when this server went down, all users were crippled. Imagine no email for a day!

The backups were made on LTO2 tapes using NTBackup. These backups, however, were spread out over multiple days making it hard to recover everything easily. We ended up using tapes from three points in time to recover all features of the server.

Finally the main issue was Exchange. To recover the exchange database into the original location in the information store, you use NTBackup and then restore the information store to the same server. Because this was a disaster it had to go to the orginal location. First, we had to remove the Recovery Information Store, because if it exists, NTBackup will default to trying to restore the database in that information store instead of in the First Storage Group that was defined and where it needed to go. This fixed the following error that we saw in the event logs:

Event Type: Error
Event Source: MSExchangeIS
Event Category: Exchange Backup Restore
Event ID: 9635
Computer: EXCHANGE
Description: Failed to find a database to restore to from the Microsoft Active Directory. Storage Group specified on the backup media is [GUID]. Database specified on backup media is [Database Name] (EXCHANGE), error is 0xc7fe1f42.

Another work around is the registry change described here, if you must keep the recovery information store, but be careful to switch the change back after the restore is done in case you are going to perform one at a later stage when you really do want it to be written to the recovery storage group!

http://support.microsoft.com/kb/824126

Then we had to create an empty database by moving the already restored (file level restore) files to a subfolder in the MDBDATA folder and then mounting the database through the Exchange System Manager, this prompts the creation of a new and empty database, after which the information store could be restored via NTBackup.

After the recovery, the database could not be mounted due to corruption. This happens sometimes when the database is not taken offline during backup. The solution is to use ESEUTIL.exe from the bin subfolder in the exchange installation folder. However, it is best to add this folder to the environment path variable and then start eseutil from the directory where the data files are. For instance, when your database is in D:\mail\ you will want to open a dos box and run the following commands:

• D:
• cd mail
• eseutil /p priv1.edb

Where priv1.edb should be changed to the filename of the exchange 2003 database. Always make sure to have a copy of the restored database folder, because if this process gets interrupted or fails you will end up with an unusable database file again and have to start back from the beginning with a new empty database and run the restore job again.

Once we had run this process through (which took 2 hours for a 16GB database) the store was mountable and we could reconnect the recovered server to the network again so the cached mail could start to be delivered.

8 hours of work to recover a domain, fileserver, and exchange server with hardly any dataloss. That is good result if you ask me!