Playing with RSG | Database Restore

This came across few days back when one of our production Exchange 2003 backend server went down due to hardware failure and was totaly dead.The Backup team was shortly in action to carry out the restore. The restore was done on the different server in a Recovery Storage Group (RSG).

Now the question is how to merge these mailboxes in RSG with the production ones... certainly direct merge was not possible as we didnt opt for Dialtone method as the production server was totaly dead and we didnt set up a new server to replace that one.

The one option was to to extract the mailboxes from RSG using Exmerge, delete the existing mailboxes of users and create new ones on another server, and then import that extracted mailboxes. But this is very time consuming.
However here's an another option to tweak the RSG to make it behave as the production store and move that mailboxes over.

The Recovery Storage Group is identified by the msExchRestore Attribute. The msExchRestore = TRUE property tells us if a database is a recovery database.
As such we cannot directly connect the mailbox from the RSG to user direcly. We have to modify this msExchRestore Attribute and make its value to Not Set so that it cannot be identified as RSG and we can connect the mailbox to the user.

The detailed steps are as follows:

1. Reset the MsExchRestore attribute on both the Recovery Storage Group, and the recovered mailbox store using Adsiedit:

Expand the Configuration Container node, and then browse the hierarchy to:
DC=Domain
DC=com
CN=Configuration
CN=Services
CN=Microsoft Exchange
CN=Administrative Groups
CN=Administrative Group Name
CN=Servers
CN=ExchangeServerName
CN=InformationStore
CN=Recovery Storage Group

Right click for Properties on the Recovery Storage Group, ensure that the checkbox for "Show Optional Attributes" is checked. Scroll down to the "MsExchRestore" attribute. Double-click the MsExchRestore attribute and check the Not Set parameter. Click OK, Apply, and OK to exit the properties pane.
Right click the "CN=MailBox Store(ServerName)" under the Recovery Storage Group, and select Properties. Ensure that the checkbox for "Show Optional Attributes" is checked. Scroll down to the "MsExchRestore" attribute. Double-click the MsExchRestore attribute and check the parameter. Click OK, Apply, and OK to exit the properties pane.
Close the AdsiEdit mmc

2. Now from the ADUC>Exchange Tasks, delete the mailboxes of the users that are in question.

3. In Exchange System Manager select the Recovery Storage Group, right click and select Refresh. Expand the Recovery Storage Group, then the mailbox store.

4. Select "Mailboxes" under the Mailbox Store, then right click the mailbox to be recovered, and select "Reconnect". The applet "Select a New User for this Mailbox" applet will appear. Enter the alias of the user you wish to associate with the recovered mailbox into the "Enter the Object Name to select" data entry field, the click "Check Name". The alias of the user should be resolved to the full display name. Click OK. You will see a pop-up stating "The operation has completed successfully".

5. Once its done for all the users, you can successfully move the mailboxes over to any of the servers.

Disaster Recovery (Soft Recovery) - Exchange 2003

After an unexpected shutdown of the Exchange Server, the Information Stores in One Storage Group goes dismounted. Gave an error message while mounting.
Checked the state of the databases by eseutil /mh and there it shows dirty shutdown.

Here it can be that one of the database is not up-to-date and the server got rebooted when it was processing one of the transactions and got corrupted.

Our next step in this case is to identify the store that has been corrupted.

We will try to replay the logfiles on the each of the stores individually:

• Renamed priv2.edb and priv2.stb.
• Replayed the logfiles: eseutil /r /i E00
• Error Encountered. So log files cannot be replayed for Information Store 1 (priv1.edb, priv1.stm)
• Now Renamed priv1.edb and priv1.stm.
• Replayed the logfiles: eseutil/ r /i E00
• Completed Successfully. So the Information Store 2 is up to date now and we are able to mount it.

Now as the Information Store 1 is corrupted, the best practice is to restore from the last backup and then make the database up to date by recovering from the present log files.Eseutil /p should be the last resort as it performs the hard recovery and punches off the corrupted tables or entries from the database. So there is always a good chance of loss of some data.

As we have renamed priv1.edb and priv1.stm, the database restore from the backup will create new set of these files. We should not overwrite these files from the restore.

The Restore of backup (Veritas in this Case) should be set with the following options:

• Do not replay logs automatically
• Do not mount databases
• No Loss restore (don't overwrite or delete anything)
  

After the restore, we have the new set of edb and stm (a day old) and the current log files that will make them up to date.
Now we will use "ESEUTIL /CC" command to replay to restore.env file and continue on to production log files. There are temporary log files and restore.env file created when we run the restore. In case of Veritas restore, they are created in C:\temp\

Restore.env file is just a temporary environmental file holding path information about the data. Its purpose is to help the Exchange 2003 restore process find its files and match them with the corresponding email stores.

Now run the command eseutil /cc "path of restore.env"

Mount the store back after it completes successfully.