If you would like to read the other parts in this article series please go to:
- Exchange Server 2013 offsite protection using DPM and Microsoft Azure (Part 1)
- Exchange Server 2013 offsite protection using DPM and Microsoft Azure (Part 2)
- Exchange Server 2013 offsite protection using DPM and Microsoft Azure (Part 3)
- Exchange Server 2013 offsite protection using DPM and Microsoft Azure (Part 5)
In the previous article of this series, we went over the process to restore an entire database using DPM and Exchange Server 2013. In this continuation of the series we are going to restore the database protected in Microsoft Azure to a Recovery Database and from there restore the items to a specific folder, or to the original mailbox.
The first step is to make sure that we delete content from the user that we will be testing. In this case, we are going to log on to Outlook Web App (OWA) using number2 mailbox (the same that we used in the previous article) and we will remove all items from the Inbox, Deleted Items and Recovery Deleted Items, and the mailbox will be empty.
As Exchange administrators, we know that there are several ways to restore the mailbox information, but for the current article we want to force the restore using the DPM and use the long-term protection stored in Microsoft Azure. If you are interested in other possible ways of how to restore that data, I’ve been working on a series of articles here at MSExchange.org using just native tools to restore the information, check this link for the first article of the series.
Now that we created a situation where the user lost its messages from its Inbox, our second step is to create a Recovery Database (RDB), and to make things easier in this article, we are going to create a folder C:\RDB to host the recovery database.
In order to create the Recovery Database, we should open Exchange Management Shell as administrator and run these following cmdlets (all steps described below are shown in Figure 01).
New-Item –Type Directory –Name RDB
New-MailboxDatabase –Recovery –Name RDB –LogFolderPath C:\RDB –EDBFilePath C:\RDB\TORDB01.EDB –Server TOREX01
Restart-Service MSExchangeIS
Note:
We use the database name TORDB01.EDB because we know this is the file name on Microsoft Azure, however you can use any name and rename the file afterwards.
Figure 01
Now that the building blocks on the Exchange Server are created, we need to log on to DPM Administrator Console, click on Recovery, select the database that the information will come from, a date and the recovery point. After that right-click on the database name listed on the frame below and click on Recovery (Figure 02)
Figure 02
In the Review Recovery Selection page. All information collected so far (recovery point date, location, and details about the item to be restored) will be displayed as shown in Figure 03, click on Next.
Figure 03
In the Select Recovery Type page. Select Recover to a Recovery Database and then click Next, as shown in Figure 04.
Figure 04
In the Specify Destination page. Click on browse and select the Exchange Server from the list (in our example is TOREX01.patricio.local) and on the Database Name we are going to type in the name that we defined at the beginning of this section which in our case is RDB (Figure 05), click Next.
Note:
Only Exchange Servers with DPM Agent will be listed on the Browse button.
Figure 05
In the Specify Recovery Options page. We can mount the database as part of the process, and for that we will select Mount the database after they are recovered (Figure 06), and on this scenario we can enable e-mail notification to inform the administrator that the process was competed (at this time we have access to the e-mails). Click Next.
Note:
If the Notification section is disabled, the reason is that in the DPM options, the SMTP Server and credentials were not configured.
Figure 06
In the Summary page. No surprises here, a final status of all options will be displayed (Figure 07) click on Recover to start the process, and as we mentioned in the previous article, the size of the database being restored and your Internet bandwidth will play a major role in this process.
Figure 07
After a while, a similar message informing that the process was completed successfully will be displayed as shown in Figure 08.
Figure 08
Going back to the Exchange Management Shell, we can run the following cmdlet to check the status of the Mailbox Databases and in our scenario, we can see that the mailbox database RDB is already mounted (Figure 09).
Figure 09
The next logical step is to find out what we have in that Recovery Database, and the best way to do that is using the Get-MailboxStatistics cmdlet, which will list all the mailbox databases. The cmdlet example is listed below and it was used in the Figure 10.
Get-MailboxStatistics –Database RDB | ft DisplayName,MailboxGuid,ItemCount,Disc* -AutoSize
Figure 10
There are several ways to restore the content. My favorite is to restore the entire mailbox located in the Recovery Database (which means the information that is coming from the Recovery Point in Azure) to a specific folder in a production mailbox.
Using the information provided in the output from the previous cmdlet, we will start a restore using the New-MailboxRestoreRequest cmdlet (Figure 11), where we are going to restore the entire mailbox into the target mailbox number2 under the folder RestoreAzure. We do have options to narrow down the restore (by folder for example), but for now the cmdlet below will be sufficient:
New-MailboxRestoreRequest –SourceStoreMailbox <MailboxGUID> -SourceDatabase RDB –TargetMailbox Number2 –TargetFolder RestoreAzure
After starting the request, it is recommended to purge it when it is complete. These following cmdlets can be used to retrieve the existent mailbox restore requests and then remove the completed ones (Figure 11):
Get-MailboxRestoreRequest | Select TargetMailbox,RequestGuid,Status
Remove-MailboxRestoreRequest <RequestGuid> -Confirm:$False
Figure 11
The results of this operation can be seen on Figure 12, where the entire content located under RestoreAzure folder is coming from the backup that was stored in the Backup Vault in Microsoft Azure through the Recovery Database.
Figure 12
Conclusion
In this fourth article of our series, we went over the process to restore messages to a specific user using the data stored in Microsoft Azure through DPM.
If you would like to read the other parts in this article series please go to:
- Exchange Server 2013 offsite protection using DPM and Microsoft Azure (Part 1)
- Exchange Server 2013 offsite protection using DPM and Microsoft Azure (Part 2)
- Exchange Server 2013 offsite protection using DPM and Microsoft Azure (Part 3)
- Exchange Server 2013 offsite protection using DPM and Microsoft Azure (Part 5)
