Skip to main content

How to work with Recovery Storage Groups at Exchange server 2007


The Recover Storage Group (RSG) feature, which was originally introduced back in Exchange 2003, gives you as the Exchange administrator, the option of mounting a second copy of a mailbox database (typically a mailbox database restored from backup) so that you can extract data from one or more mailboxes in the respective database without affecting the production databases if you need to do so during working hours.
Depending on how much you have used the new Exchange 2007 Management Console (EMC), there’s a chance you may have noticed you can no longer create an RSG from within the EMC. With Exchange 2007 this is instead done using the Exchange Troubleshooting Assistant (ExTRA) which is launched via the Database Recovery Management tool, which is found under the Exchange Toolbox work center, or by using the Exchange Management Shell (EMS).
When mounting a copy of a Mailbox database to an RSG you can extract the data from a mailbox and then merge the data with another mailbox located in a mailbox database in a production Storage Group, but you can also extract the data and then copy it to a specific folder in another mailbox.
With Exchange 2003 RTM, the data was extracted, copied and merged with another mailbox or mailbox folder using the Microsoft Exchange Server Mailbox Merge Wizard (ExMerge) tool, but with Exchange 2003 SP1 the process was integrated in the Exchange 2003 System Manager GUI.
Recovery Storage Group Limitations

There are a few things you should be aware of when dealing with RSGs. First they cannot be accessed by any protocols other than MAPI, and although they can be accessed using MAPI this doesn’t mean you can connect to a Mailbox stored in a recovery database using an Outlook MAPI client. MAPI is strictly used to access mailboxes using the Exchange Troubleshooting Assistant (ExTRA) and/or the respective cmdlets in the Exchange Management Shell. In addition you should be aware that you still cannot use RSGs to restore Public Folder data but only mailbox data. It’s also worth mentioning that even though you can create up to 50 Storage Groups on an Exchange 2007 Enterprise edition server, you’re limited to one RSG per server, but it’s supported to add multiple mailbox databases to an RSG as long as all databases belong to the same Storage Group. Finally you should note that although it’s possible to add a restored mailbox database to an RSG on another Exchange 2007 server, it’s important to understand that the Exchange 2007 server must belong to the same Active Directory forest.
Managing Recovery Storage Groups using the Exchange Troubleshooting Assistant

You can create a Recovery Storage Group (RSG) either by using the Microsoft Exchange Troubleshooting Assistant (ExTRA) tool, or by running the New-StorageGroup cmdlet with the –Recovery parameter in the Exchange Management Shell.
To create the RSG using ExTRA you should first launch the tool by opening the Database Recovery Management tool found under the Toolbox work center in the navigation tree of the Exchange Management Console (EMC). Now let the tool check for any tool or configuration file updates that may be available then click the Go to Welcome screen link. Now enter an indentifying label for this activity (such as Create RSG) then click Next. On the appearing Tasks list click Create a Recovery Storage Group then select the Storage Group you want to link with the Recovery Storage Group as shown in Figure 1, then click Next once again.

Figure 1: Selecting the Storage Group to link with the RSG
Now it’s time to create the RSG, but before you do so you need to give it a name (the default name is Recovery Storage Group which should be ok in most situations). When you have entered an appropriate name, click Create the recovery storage group (Figure 2).

Figure 2: Creating the RSG
After a little while you will be presented with a screen similar to the one in Figure 3 and the RSG for the respective Mailbox Database has now been created.

Figure 3:
 RSG Result
With the RSG created we can move, copy or restore database and transaction log files to the recovery storage group paths. To see the path for the recovery storage group log and database files, click Show Create Recovery Storage Group Information. By default the path is C:\Program Files\Microsoft\Exchange Server\Mailbox\\RSGxxxxxxxxx as you can see in Figure 4. The RSGxxxxxxxxx folder will appear empty in Windows Explorer until you have either moved, copied or restored the database and transaction log files to it.

Figure 4: Storage Group and Recovery Storage Group Paths
For the purpose of the example in this article, we will restore a Mailbox Database from a backup using the Windows 2003 Backup tool. So let’s launch the Windows 2003 Backup tool by clicking Start | Run and typing cmd.exe followed by hitting Enter. Since we will restore the Mailbox Database by using this tool in Advanced Mode, click Advanced Mode. Now select the Restore and Manage Media tab. Here we need to select the Mailbox Database and Log Files we want to restore, when you have done so click the Start Restore button.
The Restore files to: drop-down box is set to Original location. Also notice we cannot change this selection. But does this mean the Mailbox Database currently in production will be replaced with the one we restore from backup? No this is not the case, first we haven’t dismounted the production Mailbox Database and second we haven’t enabled the This database can be overwritten by a restore option on the Mailbox Database property page. Because of this the Mailbox Database will be restored to the Recovery Storage Group which we just created.
Now specify the Exchange Server to which you want to restore the respective Mailbox Database, then enter a temporary location for the log and patch files. Lastly check Last Restore Set (Log file replay will start after this restore completes.) as this is the last restore set. When you have done so, click OK and wait for the restore job to complete then click the Close button.
The respective files have now been restored to the RSGxxxxxxxxx folder as you can see in Figure 5.

Figure 5: Restored Mailbox Database in Windows Explorer
Since we didn’t check the Mount Database After Restore option, the Mailbox Database will now be in a dismounted state, with this in mind let’s switch back to the ExTRA Task Center. As shown in Figure 6 we now have several new Recovery Storage Group related tasks available, since the Mailbox Database needs to be mounted before we can extract data from it, we have to click Mount or dismount databases in the recovery storage group.

Figure 6: Selecting Mount or dismount databases in the recovery storage group
On the Mount or Dismount Database page, check the Respective Mailbox Database and click Mount selected database (Figure 7).

Figure 7: Mounting the Mailbox Database using the ExTRA Tool
When the Mailbox Database has been mounted click Go Back to task center and then select Merge or copy mailbox content. This will bring us to a screen similar to the one shown in Figure 8, here you should just make sure the Mailbox Database you wish to extract data from is selected, and then click Gather merge information.

Figure 8: Selecting a Mounted Database in the Recovery Storage Group
We now have the option of swapping the Mailbox Database mounted to the RSG and the linked production Mailbox Database (a recommended step if you’re performing a dial-tone database restore) by checking Swap database configurations as can be seen in Figure 9. Since this option will swap the two databases, both of them needs to be dismounted, which will affect mail service to the end-users whose mailboxes are stored in the respective database.
Since we aren’t dealing with a dial-tone database restore in this example just click Next.

Figure 9: Database Swap Option
On the Select Merge Options page we should click Perform pre-merge tasks (Figure 10).
Note that you have the option of clicking Show Advanced Options. Under the Advanced options we can specify different match and filtering options as well as the bad item limit. This is also the place where you specified whether all merge mailbox data should be merged to the respective mailboxes in the production Mailbox Database or should be copied to a single target mailbox.

Figure 10: Specifying Merge Options
Final step is to select the mailboxes you want to merge. You do this by checking the box to the left of each user name in the list as shown in Figure 11.

Figure 11: Selecting the Mailboxes to Merge
Now wait for the tool to merge the mailbox data from Mailbox Database in the Recovery Storage Group for the selected mailbox. When the mailbox data merge has completed, you should be able to see the content that was deleted from the production Mailbox Database. You don’t even need to restart the Outlook or OWA client for the restored data to appear!
When you have merged or copied the required Mailbox data, you can use ExTRA to dismount and then remove the Recovery Storage Group. Be sure you remove the files in the RSGxxxxxxxxx folder again after you have removed it, so that the files don’t take up valuable disk space.

Working with Recovery Storage Groups using the Exchange Management Shell

As mentioned in the introductory, you can also manage an RSG using the Exchange Management Shell (EMS). If you have a fair amount of experience working with cmdlets, restoring mailbox data from a Mailbox Database in a Recovery Storage Group can be done a lot faster than when using ExTRA.
The first step is to create the RSG. In order to create an RSG via the EMS you need to run the New-StorageGroup cmdlet with the –Recovery parameter. So to create a RSG for the First Storage Group on a server named E2K7S04, type:
New-StorageGroup –Server E2K7S04 –LogFolderPath “E:\Program Files\Microsoft\Exchange Server\Mailbox\First Storage Group\RSG –Name “Recovery Storage Group” –SystemFolderPath “E:\Program Files\Microsoft\Exchange Server\Mailbox\First Storage Group\RSG” –Recovery
The LogFolderPath and SystemFolderPath parameters are used to specify where the RSG related files should be located. As you can see, we specified they should be restored to a subfolder called RSG under E:\Program Files\Microsoft\Exchange Server\Mailbox\First Storage Group\RSG. If you intend to do the same please make sure there’s sufficient disk space available for the Mailbox Database you’re restoring from backup.
To see if a respective Storage Group is a Recovery Storage Group (as well as many other types of information) you can use the Get-StorageGroup | FL command. If the Storage Group is a Recovery Storage Group it will say True under Recovery as shown in Figure 12.

Figure 12: Full List of Recovery Storage Group information
The next step is to add a recovery database (either moved, copied or restored from backup) to the RSG, this is done by running the New-MailboxDatabase cmdlet with the MailboxDatabaseToRecover parameter. So to add a recovery database to the Recovery Storage Group on a server named E2KS04 with the edb file path pointing to E:\Program Files\Microsoft\Exchange Server\Mailbox\First Storage Group\RSG, type:
New-MailboxDatabase –MailboxDatabaseToRecover “Mailbox Database” –StorageGroup “E2K7S04\Recovery Storage Group” –EDBFilePath “E:\Program Files\Microsoft\Exchange Server\Mailbox\First Storage Group\RSG\Mailbox Database.edb”
With the Mailbox Database created in the Recovery Storage Group we now need to configure it to allow overwrites by running the Set-MailboxDatabase cmdlet with the –AllowRestore parameter. To allow file restores for the recovery database just created, type:
Set-MailboxDatabase -Identity "E2K7S04\Recovery Storage Group\Mailbox Database" -AllowFileR
estore $true
Now that we have created a recovery database in the Recovery Storage Group and allowed it to be overwritten by a file restore, it’s time to restore the mailbox database version from which you want to extract and copy or merge data to the mailbox database in production. To do so launch the Windows 2003 Backup tool and restore the respective Mailbox Database version using the same steps as we did when we used the ExTRA to recover Mailbox data.
We now need to mount the restore Mailbox Database using the Mount-Database cmdlet. In order to do so type:
Mount-Database –Identity “E2K7S04\Recovery Storage Group\Mailbox Database”
With the Mailbox Database mounted we can now extract Mailbox data from it. If you for example want to merge the mailbox data of an existing user in the recovery database to the production mailbox database, you need to type:
Restore-Mailbox –Identity -RSGDatabase “servername\RSG name\database name”
In Figure 13 we recovered mailbox data for a user called Test User 1on a server name E2K7S04.

Figure 13: Restoring Mailbox Data from a Mailbox in a Recovery Storage Group
Depending on the size of the mailbox that is to be recovered, this merging process can take a long time.
If you need to recover mailbox data for all users in the RSG, you would need to use the following command:
Get-MailboxStatistics -Database “Recovery Storage Group\Mailbox Database” | Restore-Mailbox
Let’s suppose the mailbox in the recovery database from which you want to recover data in the meanwhile has been deleted from the production mailbox database. In this case you have the option of recovering the mailbox data to a target folder in another mailbox by using the following command:
Restore-Mailbox –RSGMailbox “Test User 1” -RSGDatabase “servername\RSG name\database name” –Identity “Test User 2” –TargetFolder “Test User 1 Recovered data”
Like is the case when recovering data using the ExTRA tool, you should, when using the Exchange Management Shell, remember to remove the RSG after the required data has been recovered. To do so, first run the command to remove the recovery database:
Remove-MailboxDatabase –Identity “E2K7S04\Recovery Storage Group\Mailbox Database”
Click Yes to the confirmation warning, then type the following command in order to remove the RSG:
Remove-StorageGroup –Identity “E2K7S04\Recovery Storage Group”
Finally delete the RSG folder manually using Windows Explorer.


Popular posts from this blog

Recreating a missing VMFS datastore partition in VMware vSphere 5.x and 6.x

    Symptoms A datastore has become inaccessible. A VMFS partition table is missing.   Purpose The partition table is required only during a rescan. This means that the datastore may become inaccessible on a host during a rescan if the VMFS partition was deleted after the last rescan. The partition table is physically located on the LUN, so all vSphere hosts that have access to this LUN can see the change has taken place. However, only the hosts that do a rescan will be affected.   This article provides information on: Determining whether this is the same problem Resolving the problem   Cause This issue occurs because the VMFS partition can be deleted by deleting the datastore from the vSphere Client. This is prevented by the software, if the datastore is in use. It can also happen if a physical server has access to the LUN on the SAN and does an install, for example.   Resolution To resolve this issue: Run the  partedUtil  command on the host with the issues and verify if your output

ما هى ال FSMO Roles

  بأختصار ال FSMO Roles هى اختصار ل Flexible Single Operation Master و هى عباره عن 5 Roles فى ال Active Directory و هما بينقسموا لقسمين A - Forest Roles 1- Schema Master Role و هى ال Role اللى بتتحكم فى ال schema و بيكون فى Schema Master Role واحد فى ال Forest بيكون موجود على Domain Controller و بيتم التحكم فيها من خلال ال Active Directory Schema Snap in in MMC بس بعد ما يتعمل Schema Register بواسطه الامر التالى من ال Cmd regsvr32 schmmgmt.dll 2-Domin Naming Master و هى ال Role المسئوله عن تسميه ال Domains و بتتأكد ان مفيش 2 Domain ليهم نفس الاسم فى ال Forest و بيتم التحكم فيها من خلال ال Active Directory Domains & Trusts B- Domain Roles 1-PDC Emulator و هى ال Role اللى بتتحكم فى ال Password change فى ال domain و بتتحكم فى ال time synchronization و هى تعتبر المكان الافتراضى لل GPO's و هى تعتبر Domain Role مش زى الاتنين الاولانيين و بيتم التحكم فيها من خلال ال Active directory Users & Computers عن طريق عمل كليك يمين على اسم الدومين و نختار operations master فى تاب ال PDC Emu

Unlock the VMware VM vmdk file

  Unlock the VMware VM vmdk file Kill -9 PID Sometimes a file or set of files in a VMFS become locked and any attempts to edit them or delete will give a device or resource busy error, even though the vm associated with the files is not running. If the vm is running then you would need to stop the vm to manipulate the files. If you know that the vm is stopped then you need to find the ESX server that has the files locked and then stop the process that is locking the file(s). 1. Logon to the ESX host where the VM was last known to be running. 2.  vmkfstools -D /vmfs/volumes/path/to/file  to dump information on the file into /var/log/vmkernel 3.  less /var/log/vmkernel  and scroll to the bottom, you will see output like below: a. Nov 29 15:49:17 vm22 vmkernel: 2:00:15:18.435 cpu6:1038)FS3: 130: <START vmware-16.log> b. Nov 29 15:49:17 vm22 vmkernel: 2:00:15:18.435 cpu6:1038)Lock [type 10c00001 offset 30439424 v 21, hb offset 4154368 c. Nov 29 15:49:17 vm22 vmkernel: gen 664