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

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

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

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

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


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.

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

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top