Exchange Server 2013 Backup and Restore 101 (Part 8)

In the previous article of this series, we went over the process to backup Exchange Mailbox Databases using Windows Server Backup and after protecting the databases we have several ways to restore the data. It is all about planning how we want to restore that data to the end-users.

In a scenario where the Exchange Server is beyond repair and a recovery process has to be started, then we can use Windows Server Backup to restore the entire volume to the original location and that will restore all Mailbox Databases inside of that volume, and that is what we are going to go over in the first section of this article.

However, in some cases, we may have only one mailbox database that requires restore, and if we restore the entire volume we will overwrite information from a healthy mailbox database, and that is where we should consider restoring just one Mailbox Database and we will cover that in the second section of this article.

Restoring all Mailbox Databases from the same volume using Windows Server Backup…

In this scenario, we are going to restore the Mailbox Databases to their original location. This type of recovery is often used when the only server that you have crashed, and you restored the Exchange Server using the /RecoverServer switch (we cover this process on the sixth article of this series) and now it is time to restore the Mailbox data that was being protected previously with Windows Server Backup.
Let’s say that we have the administrator mailbox with two items on its Inbox, as shown in Figure 01, and then all of a sudden the Exchange Server crashed. Well, the first action is to perform the recovery of the server (covered on the article number 6 of this series), and then we need to restore the Exchange Mailbox Databases.

Figure 01
As soon as the server restarts from the recovery process, we will notice that all mailbox databases are dismounted (Figure 02), and at this point we should have all drive letters but without any mailbox database files on them. We can always check the properties of the mailbox databases to make sure that the path defined on the Mailbox Database object exists on the server.

Figure 02
Since we have been protecting our Exchange Server using Windows Server Backup (as shown in the seventh article of this series), we can open Windows Server Backup and then click on Recover… (Figure 03) and follow these steps.
Note:Since this server was just recovered, the Windows Server Backup may not have been installed, and if that is the case, we need to install the feature before continuing.

Figure 03
In the Getting Started page. Here we can select an existent backup location, by selecting A backup store on another location, then click Next.
In the Specify Location Type page. Click on Local Drives and click Next.
In the Select Backup Location page. Select the drive that was used to store the backup information, and click Next.
In the Select Server page. In case one or more servers exist on the location, they will be displayed on the list, select the Exchange server name from the list and click Next.
In the Select Backup Date page. Here is the key area for the restore, we have a calendar where every day that we had a backup is in bold letters, and after selecting the day, we can select the Time (in situations where we have more than one backup a day).
After selecting the day and hour of the previous backup to be restored, we can click on the link on the Recoverable Items folder and a new window with the volume (in our case M:) and two items will be listed. That weird number of the first two items is the GUID of the Mailbox Database that we can retrieve using the following cmdlet. The Windows Server Backup and the Exchange Management Shell used to retrieve the guid are shown in Figure 04.
Get-MailboxDatabase –Server <ServerName> | ft Name,EdbFilePath,LogFolderPath,Guid -AutoSize

Figure 04
In the Select Recovery Type page. Select Applications and click next. (Figure 05)

Figure 05
In the Select Application page. We will have Exchange listed under applications, just click on Next.
In the Specify Recovery Options page. Select Recover to original location (Figure 06) and the reason is that we do not have any data on the disks right now and we need to restore the Mailbox Database, click Next.

Figure 06
In the Confirmation page. A summary with all the items that will be recovered will be displayed, click on Recover (Figure 07). To start the process and that may take a while depending on the size of the Mailbox Databases that are being restored (I’m sorry, we are talking of Windows Server Backup, so in fact we are restoring the entire volume, thus all mailbox databases that we have in it).

Figure 07
The final page will be similar to figure 08, where we will see each item restore status, and how much information was transferred.

Figure 08
If we look back to the databases in Exchange Admin Center (EAC), we will notice that they are mounted (Figure 09) and the users have access to their information and all the information available is from the backup that we choose during the recover process.

Figure 09

Restoring a Single mailbox Database…

Now, we have a different situation we have our server with two Mailbox Databases residing on the same volume (M: drive) however just one database is corrupted and since we do not want to touch the databas that is healthy we cannot use the previous procedure to restore the information.
We can check the databases information using Exchange Admin Center (EAC) where we can see that only DB01 is Dismounted however, DB02 is healthy (Figure 10).

Figure 10
In the Getting Started page. Select This Server (<ServerName>), click Next.
In the Select Backup Date page. Select a day, and then the time that you want to restore, and click Next.
In the Select Recovery Type page. Select Applications and click next.
In the Select Application page. We will have Exchange listed under applications, just click on Next.
In the Specify Recovery Options page. Select Recover to another location (Figure 11) and we are going to create a folder on the temporary drive (X: drive), and the name for that folder will be Restore, after defining the location click Next.

Figure 11
In the Confirmation page. Just click on Recover to start the process, which may take a couple of minutes/hours to finish depending on the size of the volume. In the final page of the wizard just click on Close.
In the folder that we defined as destination for the restored files we will have a subfolder for each mailbox database (the name of the folder will be based on the guid attribute of the database, which makes it easy to identify what we want to restore). Inside each main folder, we will have the volume and the directory structure where the mailbox database was protected.
We must look for the Exx.chk file (where XX is the Log Prefix of the Mailbox Database that we are trying to restore) and the DB01.edb is the mailbox database file (Figure 12), and we will use that information in a few moments.
Note:If the logs and database files are not in the same volume, we must restore them as a pair. Just restoring the database volume will not help, in this current situation the database and logs are on the same volume which makes things much easier.

Figure 12
In order to check if the database is in a healthy state we can use the command below, but first we need to be on the same location of the EDB file using either Exchange Management Shell or command (we should use cd FolderName to go deeper in the structure of directories).
Eseutil /mh <file.edb>
In Figure 13, we can see that the database is in Dirty Shutdown state and in this state, we cannot mount it.

Figure 13
We need to use the eseutil utility in recovery mode (/r) to bring the database to a clean shutdown state and we can do that by using the following syntax, the results of that command line is shown in Figure 14.
Eseutil /r <LogPrefix> /l <Path-Log-Files> /d <Path-Database-File>

Figure 14
Now, we can run the same eseutil /mh <database.edb> and the state will be clean shutdown, as shown in Figure 15.

Figure 15
In order to restore the database we can just place the EDB file in the original location on the Exchange Server (Figure 16). If there are files from the previous database, we can move them to a temporary location to be safe, but the goal is to keep just the brand new restored EDB file on that folder.
Note:If a folder does not allow removal, then we can stop the service Microsoft Exchange Search Host Controller and then try to remove that folder (related to the Search Service)

Figure 16
After cleaning up the folder and making sure that the EDB is in clean shutdown state, we can use Exchange Admin Center (EAC) to mount the database (Figure 17), a confirmation will be required. After that, the users will have access to their content, which was restored from the restore process that we have just completed.

Figure 17

Conclusion

In this article, we went over the process to restore all mailbox databases contained in a volume using Windows Server Backup, and how to restore a single mailbox database using the eseutil utility.

Exchange Server 2013 Backup and Restore 101 (Part 7)

At the beginning of this article series, we defined the goal to show the administrators how to protect and restore information from Exchange Server 2013 using built-in tools. There are several tools in the market to protect Exchange data, and the vast majority uses an agent installed on the Exchange Server, and each tool has its own documented process to backup and restore exchange data.

Although many organizations are moving away from the traditional backup using Exchange native tools, there are still a lot of organizations requiring traditional backups, and there is the scenario where an Exchange Server resides on a remote/distant office and a regular backup is the only way to protect that data.

There are also customers running Office365 and they are getting used to the idea that there is no traditional backup/restore process available other than the recovery deleted items process (as seen in the beginning of this series) and the Single Item Recovery in conjunction with the high availability of the Mailbox Databases to keep the exchange data.

In this article, we are going to show how to protect using a built-in tool which is Windows Server Backup, and after that, we will be restoring the databases in several different ways which we'll see in the next article of this series.

Using Windows Server backup…

Before starting with Windows Server Backup to protect an Exchange Server database, the administrator must be aware of a few key points to make sure that Windows Server Backup will work properly with your Exchange Server environment, as follows:

• Only full backups for Exchange Server are supported, no incremental or differential backups
• Protection is done at the volume level, we are not going to see the database items during the creation of the protection job
• The tool will run only locally, there is no remote administration
• We can restore Exchange Database afterwards, but that won’t save us from protecting and restoring the entire volume first
• Exchange logs will be purged after a successful backup
• The destination of the backup can be local or a remote network share
• There is no integration between Windows Server Backup and Recovery Database feature of Exchange Server 2013 (this process is manual, and we will cover it in this series)
• The restore process is brutal, it will restore the entire content of the volume, which means that a lot of space is required to perform a restore process, so plan well how you are going to keep the information.

Now that we are on the same page with the limitations we can go ahead and install Windows Server Backup We can add a new feature using Server Manager, and being at the Features page we need to select Windows Server Backup from the list (Figure 01) and use default values to complete the installation. After the installation, the tool is ready to use and there is no requirement for a restart.

Figure 01
If you prefer the PowerShell to install your windows features, then just run the cmdlet Add-WindowsFeature Windows-Server-Backup as shown in Figure 02.

Figure 02
In this article, we will have a single Exchange Server with a few Mailbox Databases created after the installation and all of them are on the C: drive. We are going to organize the existent environment to support better integration with Windows Server Backup, by moving all existent databases to a volume that will be used only for Exchange data, and getting rid of any additional mailbox database.
The first step is to make sure that we have a volume for our Mailbox Databases. We can use the cmdlet below (Figure 03) to list all the mailbox databases of any given server and the Mailbox Database file path and its log files.
Get-MailboxDatabase –Server <ServerName> | fl Name,EdbFilePath,LogFolderPath
As we can see, we have three Mailbox Databases on this server and all of them are on the C: drive and that is not the ideal scenario when using Windows Backup. To be honest this setup is not good in any production environment for several reasons: first, we do not want the same disk being shared between Operating System and Exchange Databases; second, if the disk is running out of space then it will bring down the server and consequently the mail system. Finally, using a single volume will affect Windows Server Backup where we do not have a place to store the backup, and the only option would be a network share.

Figure 03

Preparing the Exchange Server 2013 environment…

For this article, we added 2 additional disks (M: drive for the Exchange Databases and X: drive allocated for the backup files and restores), we know based on the previous figure (Figure 04) that we have three databases and they are still on the C: drive.
In order to move our production mailbox databases (DB01 and DB02) to the new drive we can use the cmdlet below, and we need to repeat the process for each mailbox database.
Move-DatabasePath <DatabaseName> -EDBFilePath M:\EXDatabases\DB01\DB01.edb –LogFolderPath M:\EXDatabases\DB01
Note:The directory structure defined in the cmdlet will be created automatically, after entering the cmdlet above we need to confirm the move for the database and log files.

Figure 04
At this point both production databases (DB01 and DB02) are in the new location, however we still have the default mailbox database on the same server (by default they start with Mailbox Database and a long number). Since we are adjusting the Exchange Server to support the Windows Backup, we should remove all Mailbox Databases from the C: drive.
The first step is to list all the Mailbox Databases for that default mailbox database and using the following cmdlet, we can accomplish such task.
Get-Mailbox –Database “Mailbox Database <number>”
After that we can use the same cmdlet and add | New-MoveRequest –TargetDatabase <DBName> to move all existent mailboxes to the new location. The entire process is shown in Figure 05.
Note:We should wait for the completion of all move requests, and we can use the Get-MoveRequest to track the status of the process.

Figure 05
Since we are planning to remove the first Mailbox Database, it is most likely that Mailbox Database has arbitration mailboxes, and we can find that out using the following cmdlet.
Get-Mailbox –Database “Mailbox Database <number>” –Arbitration
If there is arbitration mailboxes on that mailbox database, then we need to list all arbitration mailboxes followed by the | New-MoveRequest –TargetDatabase <DBName>, as shown in Figure 06.

Figure 06
After having all mailboxes and arbitration mailboxes moved, we should make sure that we remove all the requests using Remove-MoveRequest cmdlet. The next step is to remove the last mailbox database that still resides on the C: drive and we can use the following cmdlet (Figure 07):
Remove-MailboxDatabase “<DBName>”

Figure 07
After all changes, we can check the result in Figure 08 where we have only two Mailbox Databases on the server and now we are ready to start protecting them using Windows Server Backup.

Figure 08
The Mailbox Databases were never protected, and we can validate that by checking the Mailbox Database properties using EAC (Figure 09). We will see that there is no information about the last full or incremental backup, and we will be checking this information again after running the backup using Windows Server Backup.

Figure 09

Protecting Exchange Databases…

In the Figure 10, we show the main page of the Windows Server Backup, and in order to protect Mailbox Databases we are going to set it up for a daily backup, the first step is to click on Backup Schedule...

Figure 10
In the Getting Started page. A welcome page for the backup schedule wizard will show up, just click on Next.
In the Select Backup Configuration page. We are going to select Custom and then click Next.
In the Select Items for Backup page. We need to click on Add Items and select all volumes that contain Exchange Mailbox Databases (in our case M: volume), as shown in Figure 11. After selecting all volumes that contain Exchange Mailbox Databases and log files, click on Advanced settings, and select VSS Full Backup option under VSS Settings, as shown in Figure 12.

Figure 11

Figure 12
In the Specify Backup Time page. We are going to select once a day and we will be using 11PM as the time to run the protection, please change according to your environment and click Next.
In the Specify Destination Type page (Figure 13). Here we can define where the protection files will be placed. There are several options: we can use a dedicated hard disk (recommended), an existent volume or a shared folder on the network. In our case, we are going to use the option Back up to a volume and click Next.
Note:
The first option is recommended because all the disk activity will be in a separate disk, and that disk is going to be used only for the Windows Server Backup. Using this option the disk will be formatted and it will not be visible on Windows Explorer.

Figure 13
In the Select Destination Volume page. Click on Add and select the volume desired, and click Next.
Finally, in the last page a summary of all settings that we defined so far is going to be listed, click on Finish.
The results of this new backup job that we have just scheduled is a new Task in Task Scheduler being listed under Microsoft\Windows\Backup item, as shown in Figure 14.

Figure 14
Now it is time to wait for the scheduled task to run, and after that, we can see the results on the main page of Windows Server Backup, Figure 15 The same initial page will provide details about schedule jobs, last activities, future jobs and status of the volume/disk being used to store the backup files.

 
Figure 15
After having the first backup complete, we can go back to the mailbox database properties using Exchange Admin Center (EAC), and if everything went fine, we will have information on the Last Full Backup field, as shown in Figure 16. As part of the same process, all the logs that were committed to the mailbox database were purged as part of the backup of the database.

Figure 16

Conclusion

In this tutorial, we went over the basic steps to configure an Exchange Server 2013 to work with the built-in Windows Server Backup. In our next article of this series, we will be able to restore the database information to restore a mailbox server, and after that we will work with dial tone restore, mailbox portability and Recovery Mailbox Database, so we have tons of cool stuff to check in this series.

Exchange Server 2013 Backup and Restore 101 (Part 6)

In this article, we are going to check how we can restore the Exchange Server using different hardware in case of a major failure.

Having a high availability scenario helps a lot where a server outage will not affect your end-users. The steps that we are going to follow in this article are applicable for both type of scenarios: single servers and multiple servers in high availability mode.

Before validating the steps required in order to restore from a complete server failure, we need to review the Exchange Server 2013 roles, in this version we have three roles: Client Access, Mailbox and Edge Server. The focus of this article will be on the roles that are located in the internal network which are Client Access and Mailbox Server roles.

When recovering from Client Access Server roles failure then there are fewer steps, because the server itself does not have any data that needs to be restored. When restoring the Mailbox Server role we need to follow the same steps of a Client Access but an additional set of steps will be required to recover from the Mailbox(es) Database(s).

Like the previous versions of the product, most of the information required for an Exchange Server resides on Active Directory, and for that reason, the restore process is a simple procedure.

Recovering from a server failure…

It is all about planning, being prepared and trained so when a disaster strikes you can get over the issue as quick as possible. It is not a requirement, but here are some key items that should be documented/validated when the Exchange Organization is running (an update of these key points when there is a change in the production environment it also important for documentation purposes):

• IP Configuration
  If you use the same IP address and the exact number of adapters, then we will have less chances for an issue during the restore process. The main reason is that other components, such as Firewall, Load Balancer and DNS are using that specific IP.
• Windows Operating System (version and Service Pack)
  It is not supported to restore to a different Operating System, so we must keep the same Operating System on the new server.
• Exchange Server version
  Knowing the Exchange version will guarantee the administrator to restore the exact same version during the restore procedure.
• Exchange Server installation path
  Keep it simple, if you use default values during the first installation, then it is one less thing to worry about when restoring Exchange Server. If you have used a different path, then make sure that you remember the path because you will need to specify this during the restore process.
• Exchange Server Volumes (applicable on the Mailbox Servers)
  Make sure that all the volumes used by Exchange are available on the replacement server.
• Certificates installed on the server and their association
  We can always recreate or rekey the certificates, but if you have them documented that will save you some time.
• Test the procedure in the LAB
  Be realistic, measure the time to restore the information and document all steps. That will be key to define the time required to restore the environment.
• Third-party software installed on the server
• IMAP/POP3 configuration (service)
  These services are configured after the server installation and they will not be restored on the new server.
• Registry information
  The process to recover a server will not bring any information that was configured on the registry of the original server. Any special customization has to be added again on the new server.
• Physical and Virtual
  When recovering a server, you can recover a physical server in a virtual server, as long as your VM is following the Microsoft best practices
• OWA Customization
  If you have any OWA customization, then you will need to restore those settings.
• Anti-spam features
  The anti-spam agents must be installed on this new server.

Preparing the new server for the recover process…

The first step is to install the requirements on the Operating System, for this article our original server was running on Windows Server 2012 R2. If you have documented your Exchange Server deployment, then that is the same procedure. In our case, we are going to run this cmdlet and after installing all the features, we will then restart the server.
Install-WindowsFeature AS-HTTP-Activation, Desktop-Experience, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, RSAT-Clustering-Mgmt, RSAT-Clustering-PowerShell, Web-Mgmt-Console, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation, Telnet-Client, RSAT-ADDS
The second step is to download and install the Microsoft Unified Communications Managed API 4.0, Core Runtime 64-bit. The installation process is straight forward (Figure 01 shows the first page of the installation wizard), we will use default settings to complete the installation.

Figure 01
The last step is to use the same Exchange version that we had in the original server. If you have another Exchange Server in the environment, the following cmdlet can be used (Figure 02)
Get-ExchangeServer | ft Name,ServerRole,AdminDisplayVersion –AutoSize

Figure 02
The next step is to identify which is the Cumulative Update of the failed server. We need to compare the output of the AdminDisplayVersion with the Build number (Figure 03) and on the same page, we can download the right version (the page that contains all Build Numbers is listed at the end of this article).

Figure 03
After downloading the same Cumulative Update that was installed in the production server, the next step is to extract it into a folder on the system drive (in this Tutorial we are going to use C:\EXCU6 folder).

Recovering the Exchange Server…

We have an environment for this article with 2 (two) servers: QC-EX01 and QC-EX02. The server QC-EX02 had a server failure and we need to restore the server on different hardware.
At this point, the server original QC-EX02 is offline, and we have a basic documentation from the previous Exchange Server and we have a new server that has all the pre-requisites installed on it.
The first step is to reset the computer account in the Active Directory, open Active Directory Users and Computers, right-click on the Exchange Server computer object that we will recover, and click on Reset Account (Figure 04), click on Yes to confirm, and then OK.

Figure 04
Now our attention is on the temporary server, we must perform these tasks to this new server:

• Check if the disk layout and network adapters are the same as we used to have in the production server
• Assign the same IP address to the new server
• Rename the new server with the same name of the failed Exchange Server (in our article is QC-EX02) and restart the server
• Join the new server into the domain

The next step is to open the PowerShell as Administrator, and then go the folder where we extracted the Exchange Server source files, and the entire sequence is summarized in these cmdlets:
Cd .\EXCU6
.\setup.exe /m:RecoverServer /IAcceptExchangeServerLicenseTerms
The results of the command above is shown in Figure 05, and after checking that steps have the COMPLETED, then that is a good sign that the recovered Exchange Server is back and almost ready for the primetime.

Figure 05
If you have only the Client Access server role installed on the server, then you just need to work on the points listed below and after that our restored server will be ready.

• Install the Exchange Certificate (you can import from an existent server or recreate them using an Internal CA/Public Certification Authority) and assign the services accordingly
• If you were using POP/IMAP service, make sure that you configure the services to be automatic
• Restore any OWA customization that you had in the original server
• Install third-party applications that you had in the original server
• If you were using built-in anti-spam agents, then you need to reinstall them on the new server

If the original Server was a Mailbox Server role, then the administrator has one additional step, which is to restore the Mailbox Databases using the existent backup solution. By default, all databases configured in the restored server will show up as Dismounted, as shown in Figure 06.

Figure 06

Conclusion

In this article, we went through the steps to recover an Exchange Server 2013 using the information stored in the Active Directory.
More information:

• Exchange Server 2013 Prerequisites
• Exchange Server Updates: build numbers and release dates

Exchange Server 2013 Backup and Restore 101 - Disabled mailboxes (Part 5)

Permanently removing a disconnected mailbox...

In the beginning of this series, we went over the Mailbox Database properties and verified that we can define the number of days a disconnected mailbox stays in a Mailbox Database. That is great for recoverability of the mailboxes, however, in some cases we must make sure that the information is delete immediately.
We can use the Remove-StoreMailbox cmdlet to purge a disconnected mailbox and all its content. Let’s suppose that we have just removed the mailbox Number2 using Exchange Admin Center (EAC), and after a few minutes, we run the cmdlet below (Figure 01) to check a list of mailboxes on the mailbox database. By default the result will be all mailboxes, the one that we have just removed will be listed there as disconnected, and by now we know that we have capabilities to retrieve that information (based on the previous article of this series).
Get-MailboxStatistics –Database QC-DB01 | ft DisplayName,MailboxGUID,DisconnectReson –AutoSize

Figure 01
If the goal is to remove the mailbox for good, then we will be running this additional cmdlet using the MailboxGUID of the disconnected mailbox (Figure 02).
Remove-StoreMailbox –Database <Database-Name> -Identity <MailboxGUID-from-the-previous-cmdlet> -MailboxState Disabled
Note:
The Remove-StoreMailbox only works against Disconnected and soft-deleted mailboxes.

Figure 02
If we run again the Get-MailboxStatistics towards the Mailbox Database, the Number2 mailbox is really gone after running the Remove-StoreMailbox cmdlet.

Figure 03
In the previous scenario, we removed a user using Exchange Admin Center and then ran a cmdlet to remove the disconnected mailbox from the Mailbox Database and these are the steps when the mailbox is removed using Exchange Admin Center (EAC).
However, we can remove the mailbox and not leave any disconnected mailbox using Exchange Management Shell. Therefore, if you know that you want to remove the mailbox and its entire content from the Mailbox Database, then we need to use the parameter –Permanent of the Remove-Mailbox cmdlet.
In order to test the procedure, we will check first the mailbox Number6 and we can see that is a valid mailbox and it is hosted on the Mailbox Database DB01 (Figure 04)

Figure 04
We will remove the mailbox Number6 using the Permanent parameter (Figure 05), and after that we will check the Mailbox Database using Get-MailboxStatistics to make sure that there is no trace of the removed mailbox.
Remove-Mailbox <Mailbox> -Permanent:$True
Note:The –Permanent parameter is only available on the Remove-Mailbox cmdlet. The same parameter is not found on the Disable-Mailbox

Figure 05

Moving Mailboxes….

For this section, we are going to use the mailbox Number16 that is located initially on Mailbox Database DB01, and we will be moving it to the Mailbox Database DB02, the migration process of the mailbox is shown in Figure 06.

Figure 06
When a mailbox is moved among Mailbox Databases, the content is transferred to the new Mailbox Database but it is not deleted from the original Mailbox Database, and the mailbox stays disconnected for the retention period defined in the Mailbox Database properties (if you don’t remember this one, please check the first article of this series).
In order to show you what happens with the mailbox during a move mailbox process to a different database we will run the Get-MailboxStatistics in three different moments, as shown in Figure 07. In the first moment (Number 1 in the red box), we have the mailbox hosted on the Mailbox Database DB01; In the second moment (Number 2 in the red box) the move mailbox was completed and the mailbox shows up as SoftDeleted on the original Mailbox Database; at the same time the mailbox is showing up on the destination Mailbox Database which is DB02 where the user is accessing its data.

Figure 07
How about if you want to restore the information of that SoftDeleted mailbox that is located on the first mailbox? That disconnected mailbox has the entire content of the mailbox content just before the move process was complete and in some scenarios, we can use that to retrieve information.
To be honest, it is not very common a restore request of that information, however, throughout the years I have seen a couple of scenarios where this procedure can be useful, as follows:

• Special users (VIP) complaining that after a move some content has disappeared off their mailboxes;
• A large mailbox was moved to a distant site and you need a piece of information from the mailbox right away
• The destination Mailbox had a major issue, and the information was lost (right after the move) and in that case, the information before the move can be useful.

If you see it fit in your environment to restore that information, then the New-MailboxRestoreRequest is the cmdlet that will be used to retrieve that information. We are going to use the following syntax and the restore data will be available on a new folder in the administrator mailbox (Figure 08)
New-MailboxRestoreRequest –SourceStoreMailbox <MailboxGUID> -SourceDatabase <Mailbox-Database> -TargetMailbox <Mailbox> -TargetRootFolder <Name-of-the-target-folder> -AllowLegacyDNMismatch

Figure 08
The results of the previous cmdlet can be seen in the Figure 09, where the administrator (the target mailbox of the cmdlet) will have a new folder that we defined in the same cmdlet with the entire content of the mailbox Number16 before it was moved to the new Mailbox Database.

Figure 09

Mailbox Database protection…

The point in this section is to show that if we have a valid backup of the database, we can always restore the information using the techniques that we have seen throughout this article series. Let’s say that we have the standard limits on any given Mailbox Database (30 days), and on the first day of the month, we deleted a mailbox, then on the fifth day of the month, we create a backup of the Mailbox Database. Next month, the deleted mailbox content will be purged from the Mailbox Database however, we can use the backup of the Fifth to access that information.
That being said, if we understand how to restore information and wisely use the built-in features of Exchange Server we can always restore the data and at the same time keep historical data with a few backups (if they are required at all, in some situations we can avoid backups completely).
You can protect your Mailbox Database using any backup solution that supports Exchange, but in this section, we are going to use the native tools. The most manual process is to stop the Microsoft Information Store (stop-service MSExchangeIS) or dismount the database, and then copy the EDB file, the drawback of this method is that for the time being your users won’t have access to their mailbox information which is not a good thing.
The second method introduced with the latest Cumulative Updates of Exchange Server 2010, and it is present in Exchange Server 2013, is using eseutil utility to create a consistent backup of the Mailbox Database without stopping access to the mailbox information. The first step is to identify the Mailbox Databases and their physical locations on the disk (Figure 10).
Get-MailboxDatabase | ft Name,EDBFilePath,LogFolderPath,LogFilePrefix -AutoSize

Figure 10
Now that we have all the information we will be creating a backup of the Mailbox Database DB01 (Figure 11), using the following command:
Eseutil /y <EDBFilePath> /vss /vssrec <LogFilePrefix> <LogFolderPath> /d <Path-of-the-Backup>

Figure 11
After having the backup complete we can run eseutil /mh <Database-File> (Figure 12), the State field must be Clean Shutdown, and that means that we can mount this Mailbox Database afterwards without any issues.

Figure 12

Conclusion

In this article, we went over the process to protect a database using eseutil, restored information from moved mailboxes from the original Mailbox Database, and the steps required to permanently delete data from disconnected mailboxes.