Exchange Server 2013 Backup and Restore 101 (Part 9)

If you would like to read the other parts in this article series please go to:

In the last couple of articles of this series, we covered the process to backup and restore data using the most basic tool available to an Exchange administrator that is the Windows Server Backup. We also covered how an administrator is able to create a backup of a running mailbox database using the eseutil utility.

There is nothing wrong with that process, and it will work just fine. However, let’s picture a scenario where the customer has a single Exchange Server and a large mailbox database and all the protected data is on tapes which are moved to an offsite facility on a daily basis.

Then, we have a catastrophic failure on Exchange Server, and we performed the disaster recover procedures on the server (using the same step by step guide that we described in the sixth article of this series). To make matters worse, the business/customer says that time is of the essence and they must have access to some sort of e-mail to keep the business going as soon as possible. At this point, we have two options:

Option A: You can say to the customer: Sorry pal, but your design does not allow such RPO (Recovery Point Objective). If you can get his agreement that it is not doable, then we can restore the data as we have done in the previous articles, however we will have to wait for the Backup team to find the data and make them available.

Option B: Perform a dial tone recovery, where we will create a new temporary mailbox database and move all existent users to that new place, and after that they will be able to send and receive new e-mails just fine.

After having the original database ready from the backup team, we can use a feature called RDB (Recovery Database) to mount the original mailbox database and make sure that the database or at least its data can be restored/merged in production.

Restoring the service using dial tone recovery….

In order to demonstrate the dial tone recovery, we are going to use the following scenario: we have a couple of users hosted on TOREX01server, and they work in a special department that is responsible for sending and receiving information from the customers.

The data to be restored is going to take at least a day to be available to the messaging team, and for that reason we decided to perform the dial tone recovery to get the users working on the new messages and then afterwards we are going to merge that information.

Our test user is called Number6, and we can see its mailbox content before the crash, as shown in Figure 01.

Figure 01

After the restore of the server (we can check the entire process on the sixth article of this series), we will have all databases dismounted and the next logical step would be the restore of the databases, but in this scenario we are aware that they are not coming anytime soon.

At this point, new messages coming from Internet are being queued up (Figure 02, Queue Viewer), all Outlook clients are showing as disconnected (Figure 02, Outlook) and Outlook Web App is giving an error message (Figure 02, OWA). Long story short, nothing works!

Figure 02

The first step is to create a temporary mailbox database (TDB01) using either Exchange Admin Center (EAC) or Exchange Management Shell on the recovered server. Using EAC (Exchange Admin Center), click on Servers, and then Databases, click on Add (represented by the + icon) and on the new page define a name for the new Mailbox Database, for this article we will be naming it as TDB01, finally define the location for logs and edb file, and click on save, as shown in Figure 03.

We left uncheck the Mount this database, because as soon as we finish creating it, we will be restarting the Microsoft Exchange Information Store, and then mounting the mailbox database using these cmdlets:

Restart-Service MSExchangeIS

Mount-Database TDB01

Figure 03

The mailbox databases are shown in Figure 04, where we have the DB01 dismounted, which is waiting for the original log files from the last backup, and a brand new temporary database called TDB01.

Figure 04

Our next logical step is to start pointing the mailboxes to the new temporary mailbox database. In the cmdlet below (Figure 05), we list the mailbox first and then we move it by adding set-mailbox cmdlet at the end of the pipe. After running either of the cmdlets below, a confirmation will be required to complete the process.

Get-Mailbox number6 | Set-Mailbox –Database TDB01

We can use also in a single cmdlet, as follows:

Set-Mailbox <name> -Database <New-Database>

Figure 05

The important lesson from the cmdlet above is that we have not moved any data (It makes sense, since the original mailbox database with all data is dismounted and the backup is coming). We just need to change the mailbox configuration to the new location, what is going to change mainly is the homeMDB attribute of the user, as shown in Figure 06.

Note:
We are just showing the attribute, we don’t need to change it manually, just perform the cmdlet above and we are good to go.

Figure 06

Now the user that we have just moved can go to the Outlook Web App (OWA), the result will be a brand new mailbox, and only new messages that were in the queue will be delivered to the mailbox, as shown in Figure 07.

Figure 07

If the same user opens an existent Outlook profile that was configured in the past, then the following message (Figure 08) will be displayed. In order to access the information on the temporary database, the user needs to click on Use Temporary Mailbox and only the new information will be accessible. On the other hand, if the user wants to access the information before the outage of the system, then the option Use Old Data can be selected, and the information that was previously synchronized with the user local OST file will be available.

Figure 08

In Figure 09, we can see Outlook with the new received messages after the user clicked on Use Temporary Mailbox option.

Figure 09

Conclusion

In this article, we went over the process of using the dial tone recovery process to bring the end-users back online with an empty mailbox where they will be able to send and receive new messages. In the next article of this series, we will be restoring the original database content and merging the new information with the old data to restore the service completely.

If you would like to read the other parts in this article series please go to: