Recovery Storage Groups (RSG) are one of the most administrator friendly features of Exchange Server 2003 SP1. Prior to Exchange 2003 SP1, if you needed to restore a
[2] mailbox, you were in for a whole pile of work. You would need to configure a completely separate forest with an Exchange recovery server and then restore to that server. Once that was complete you could export to PST and then import that PST into the production mailbox. Not fun and I know of more than one place that had a policy not to restore mail. You can imagine what that led to.
One of the features of Exchange Server 2003 SP1 is called Recovery Storage Groups. Fellow MSExchange author Markus Klein wrote on using RSGs in his article titled Recovering Mailboxes with Exchange Server 2003 Service Pack 1 [3].
Recovery Storage Groups allow an administrator to mount a restored copy of an Exchange database on any server in the same Administrative Group. Once the database is restored to the RSG, the administrator has a number of options to restore the mailbox(es) to the production server. You can restore a mailbox, a group of mailboxes, or the entire database.
The first and foremost difference is that RSGs do not support any protocols except MAPI and therefore cannot send or receive mail. They also cannot be bound to a user’s Active Directory account. In fact the only user accessible way of accessing a mailbox in a RSG is with ExMerge. Other than ExMerge, the only other way to access the mailbox is to restore it to the production store.
Because RSGs are not meant for long term, and cannot be put into production use, there are a number of things that they do not support such as online maintenance, defragmentation, mailbox management, and system policies. Unlike a regular storage group, you cannot change the location of the files. When you create the RSG you can use the default locations or specify a different location for the files (see Figure 1). The only way to change this is to delete the RSG and start over.
Figure 1: RSG File Location
A few other things that make RSGs different are:
Once you have the RSG created and are going through the restore process, you will probably notice that you are not prompted where to restore the database to. This has caused a few administrators to cancel the restore thinking they have done something wrong. For example, when restoring with NTBackup, the only information you need to supply is where to restore to, and the location of the temp files (see Figure 2).
Figure 2: Restore Options
One thing to be aware of is that you can only restore backups taken with an Exchange aware backup application. So why isn’t the production database overwritten? Simple, the Information Store is smart enough to automatically redirect the restored database to the RSG. When you create an RSG you are prompted to choose a database to recover (see Figure 3).
Figure 3: Database Selection
When you start the restore, the Information Store checks to see if the chosen database is in an RSG. If it is, the database is restored to the RSG, if it is not the restore stops. You may also see event ID 9635 in the application event logs. The source of this error is MSExchangeIS and the description will tell you that the database could not be found.
Once the RSG is deleted, the recovery process returns to its normal behavior. If you do not want to delete the RSG, but don’t want to restore to the RSG, you can modify the behavior in the registry.
Open up the registry and drill down to
HKLM\System\CurrentControlSet\Services\MSExchangeIS\Parameters\System
Create a new DWORD called “Recovery SG Override†and set the value to 1. This will allow you to keep the RSG, but the restored database will not be redirected. I don’t recommend creating this key, and if you do require it, delete it when you are finished. Last thing you want is to forget about it and then wonder why the 3 month old database you just restored to an RSG actually overwrote the production database!!!
With the RSG created and the database restored, you might now wonder how the mailbox in the RSG connects to the mailbox on the production database. The RSG mailbox and the production mailbox are linked with the following two Active Directory attributes
The msExchMailboxGUID is unique for each mailbox and is created during mailbox creation and never changes. The GUID of the mailbox in the RSG must match the GUID of the production mailbox. This leads to a common issue with RSGs; you cannot restore a deleted mailbox. When the mailbox is deleted so is the GUID and when the new mailbox is created a new GUID is also created. Because the GUIDs do not match, a RSG cannot be used to restore the data. Figure 4 demonstrates this link.
Figure 4: GUID Linking
The msExchOrigMDB attribute determines the originating database from which the mailbox was a part of. This attribute directs the data to the proper database. The combination of the msExchMailboxGUID, which determines which mailbox to restore to, and the msExchOrigMDB attribute, which determines which database the mailbox is in, allows the administrator to merge or copy the data into the production mailbox (see Figure 5).
Figure 5: Merge or Copy Data
This leads to another common issue, what happens if the mailbox has been moved to a different database since the backup was made? In such a case, the msExchOrigMDB attribute can be edited with ADSIEdit.
If the mailbox has been moved to a different database, you must edit the msExchOrigMDB attribute on the RSG so that it points to the database that now contains the mailbox. To do this open ADSIEdit and drill down to
CN=Configuration,DC=domainname,DC=tld
CN=Services
CN=Microsoft Exchange
CN=ExchangeOrganizationName
CN=Administrative Groups
CN=AdministrativeGroupName
CN=Servers
CN=Servername
CN=InformationStore
CN=StorageGroupName
From this location, right-click on the database object and select Properties; record the value for the distinguishedName. Next, locate the RSG database under the CN=Configuration,DC=domainname,DC=tld container. Edit the msExchOrigMDB attribute and enter the value you recorded earlier. Close ADSIEdit and you can now restore the mailbox that was moved.
Recovery Storage Groups are a powerful tool available to Exchange administrators that allow you to easily restore mailbox data. This article scratches the surface on how they work, but I hope it answers some of the questions you had on the subject. If you want to know more check out these great articles from other MSExchange authors:
Exchange 2003 Backup and Restore with NTBACKUP [4]
Recovering Mailboxes with Exchange Server 2003 Service Pack 1 [3]
Using ExMerge to recover a Single Mailbox or Mailbox Item [5]
Exchange Server 2003 Mailbox Recovery [6]
This article was reprinted with permission from MSExchange.org [1]Links:
[1] http://msexchange.org/tutorials/How-Recovery-Storage-Groups-Work.html
[2] http://www.msexchange.org/
[3] http://www.msexchange.org/tutorials/Recovering-Mailboxes-Exchange2003-SP1.html
[4] http://www.msexchange.org/tutorials/Exchange-2003-Backup-Restore-NTBACKUP.html
[5] http://www.msexchange.org/tutorials/ExMerge-Recover-Mailbox.html
[6] http://www.msexchange.org/tutorials/Exchange_Server_2003_Mailbox_Recovery.html