After working with recent versions of Exchange server, you might forget what life was like back in the early days of Exchange. You quickly get accustomed to functionality as if it were always there. It is easy, for example,  to forget how tiresome it used to be to recover deleted mailboxes. With Exchange 5.5 server you had to restore the entire mailbox store on a recovery server and then had to perform an export and import exercise using PST files and a newly created mailbox.

In Exchange 2000, the mailbox retention period was introduced. This provided new capabilities for recovering deleted mailboxes, by accident or on purpose. Within the retention period, the mailbox can be recovered by reconnecting it to the same or a different user object that has no mailbox connected to it. This may prove valuable after accidental deletions or when converting to, or from, a linked mailbox account, where the user accounts resides in one forest and the Exchange mailbox in another forest.

With Exchange 2010 there are some additions to this story because of personal archives. In reality, as you probably know, the personal archive in Exchange 2010 is a special kind of mailbox which gets special treatment. For instance, personal archives can have different quota settings than regular mailboxes.

In this article I would like to explain the procedures involved mailbox recovery, disconnecting or connecting mailboxes to user objects, mailbox retention. I will also give attention to the personal archive element found new in Exchange 2010.

Relationships

In Exchange 2010 (2003 and 2007 as well) we have the option to “remove” the mailbox of a mailbox user (remove is quoted, because the action itself is called Disable). What really happens when you disable a mailbox is that the mailbox is disassociated from the related user object in Active Directory by removing the user object’s Exchange attributes. The mailbox is also said to be ‘orphaned’ because it has no associations with a user object. During the maintenance cycle, the mailbox will be marked for removal.

To better understand why a mailbox can still exist when removing it from a user object, I created the figure below. It shows the relationships between a mailbox-enabled user, its Active Directory attributes and the Exchange mailbox and personal archive (if present).

Since the objects are using different property names for the same property, some property mapping needs to take place to understand the relationships. This is indicated by the EX and AD labels. For instance, the msExchMailboxGuid property from Active Directory relates to an ExchangeGuid property in the mailbox store and the Guid attribute of a mailbox relates to the ObjectGuid of the associated user. There is also a separate mapping between a mailbox and a personal archive through the ArchiveGuid property.

For example, this is how this looks like for a mailbox:

Mailbox Retention

After disabling a mailbox it will still be present in the mailbox store and it is marked for removal. During maintenance, the MSExchangeIS process will check for mailboxes marked for removal and which are past their retention period. The retention period is a configurable setting and by default it is set to 30 days, meaning you can recover deleted mailboxes within 30 days.

In order to configure the mailbox retention setting from the Exchange Management Console in Exchange 2010, navigate to Organization Configuration > Mailbox and then select the database in the Database Management tab. Select its Properties and configure the “Keep deleted mailboxes for (days)” setting on the Limits tab:

If you want to do the same thing in Exchange 2007 from the Exchange Management Console, you would have to select the database properties from the Server Configuration > Server view, since mailbox stores are configured at the server level in Exchange 2007, whereas in Exchange 2010 they are configured at the organizational level.

You can also configure the mailbox retention setting from the Exchange Management Shell. Use the Set-MailboxDatabase cmdlet for this purpose:

For example, to set the mailbox retention setting to 60 days, use:

Now we know how to configure the retention setting, we need to know how we can check if the cleanup process has been running. The start of the cleanup process in which deleted mailboxes are removed is indicated by the following event in the Application event log:

When the cleanup process has finished the following event is logged in the event log:

The mailbox is now deleted from the mailbox store and cannot be recovered.

Deleting and Recovering a Mailbox

Now on to the fun part. For starters, we will have a user with a mailbox and without a personal archive, like in the pre-Exchange 2010 era. Nothing new here, from the Exchange Management Shell we can disable the mailbox by selecting it and selecting Disable.

Perhaps unnecessary to say, but don’t select Remove to remove a mailbox. The Remove option will not only disconnect the mailbox but will also delete the associated user object. You will not be the first to accidentally remove the user object when you only intended to remove the mailbox selecting the Remove option. After all, you are in a Mailbox view so Remove implies removing a mailbox. The action Disable is also improper naming since it doesn’t disable the mailbox but marks the mailbox for deletion. After the retention period it will be deleted permanently. That’s not what “Disable” implies. After all, disabled user accounts are not deleted from the Active Directory after their tombstone expires.

To disable a mailbox from the Exchange Management Shell use the Disable-Mailbox:

Do not make the mistake of using the Remove-Mailbox cmdlet, which is similar to the possible confusion in the Exchange Management Console as mentioned earlier. A useful addition to the Remove-Mailbox cmdlet when compared to the Remove action found in the Exchange Management Console is that you can use Remove-Mailbox in conjunction with the Permanent parameter to immediately remove the mailbox, without having to wait through the “Deleted Mailbox Retention” period. It is not possible to recover the mailbox once you have done this.

You can also use the Remove-Mailbox cmdlet to permanently remove disconnected mailboxes without needing to wait for the retention period to expire. To use this we need to specify the mailbox Database as well as the ExchangeGuid:

Disconnected mailboxes appear in the Disconnected Mailbox view in Exchange Management Console (if the naming were consistent, this would be called Disabled Mailbox). We can right click on a disconnected mailbox, select Connect and choose a matching user or a different user to which to connect the mailbox. A matching user will be based on matching values in the LegacyExchangeDN or DisplayName properties. When selecting a different user the requirement is that the user must not already have a mailbox connected.

Note that disconnected mailboxes may not show up immediately because of delays caused by replication or if the status of the mailbox hasn’t been updated in the store yet. To scan Active Directory for disconnected mailboxes and update the status in the store accordingly, you can use the Clean-MailboxDatabase cmdlet, e.g.

For those with Exchange 2003 experience, the Clean-MailboxDatabase cmdlet is similar to the Run Cleanup Agent function found in Exchange 2003.

Before showing you how to (re)connect a disconnected mailbox to a user object using the Exchange Management Shell, I will first show you how to find out which mailboxes are currently disconnected by using the Get-MailboxStatistics cmdlet and filter the output on having the DisconnectData property set, e.g.

Note that this example queries all mailbox stores of all available mailbox servers in the organization. You can narrow this selection down either by specifying a server or database in combination with Get-MailboxStatistics or by modifying the where filter, for example:

Now in order to (re)connect a disconnected mailbox to a user object, use the Connect-Mailbox cmdlet:

Note that if you do not specify the User parameter, Connect-Mailbox will use the matching user method to connect the disconnected mailbox. In order to connect this mailbox to a specific user, use the User parameter like this:

For MailboxID you can use the DisplayName, the MailboxGuid or the LegacyExchangeDN value. You can also specify additional parameters like ActiveSyncMailboxPolicy or ManagedFolderMailboxPolicy with the Connect-Mailbox cmdlet to assign those policies to the mailbox.

Deleting and Recovering a Personal Archive

After showing how to disconnect and connect mailboxes using Exchange Management Console and the Exchange Management Shell, I will now show how to disconnect and connect mailboxes or the associated personal archives. As we learned, the Disable command of the Exchange Management Console disconnects the mailbox. If that mailbox user also has a personal archive it will also be disconnected. After disconnection, you can find both the mailbox and the personal archive in the Disconnected Mailbox list:

When you want to disconnect the mailbox and personal archive using the Exchange Management Shell you need to use the Disable-Mailbox cmdlet twice; once without and once with the Archive parameter. The reason for this is that, when you specify the Archive parameter, the Disable-Mailbox will not disconnect the primary mailbox. Thus, this cmdlet will only disconnect the archive mailbox:

You can connect the mailbox and personal archive to a user object. Note that the personal archive can only be connected to a user object currently owning the associated mailbox based on the LegacyExchangeDN value. This means, if we connect Michel’s mailbox to user Jan, Michel’s personal archive can only be connected to Jan.

Knowing this, if we want to connect a disconnected personal archive to the current owner of the mailbox with the personal archive, we just need to use the Archive parameter:

Because we are connecting a disconnected personal archive, use the DisplayName with the “Online Archive -” prefix. Alternative option is to specify the MailboxGuid or LegacyExchangeDN as the MailboxID. As you can see in the example below, the current owner will automatically be looked up when connecting the archive:

Linked Mailboxes

As you probably know, a linked mailbox is like when you have two forests; one forest contains the accounts, the other forest contains the resources used by the accounts. In case of linked mailboxes the resource forest contains disabled user object representing users in the account forest, Exchange and the mailboxes. By creating a trust between the two forests you can link the mailbox to user objects in the account forest.

To connect a linked mailbox to a user object in a different forest, all you need to do is specify a domain controller located in the trusted account forest as well as the user object to connect the mailbox to:

In this example, MailboxID contains the ID of the disconnected mailbox and UserID the disabled user object in the Exchange forest representing the mailbox. LinkedID contains the user object in the trusted forest which is going to be the new owner of the mailbox.

You cannot connect a linked mailbox to a user object including the personal archive in one step. To add the archive to an account, use the command to connect the personal archive to the disabled account in the current forest, e.g.

As you can see, the Exchange Management Console will warn you that replication might cause delays in changes becoming effective, which makes sense, since we are dealing with two forests when using linked mailboxes.

Cleanup

Finally, if you want to clean up (i.e. purge) all disconnected mailboxes and archives in an organization and don’t want to wait for their retention period to expire, use the following cmdlets:

The first operation retrieves all disconnected mailboxes in the organization and assigns the variable $disMbx to it. The second operation loops through all entries in $disMbx and removes them one by one (the percentage symbol is an alias for foreach-object). Needless to say, perform this action only after creating a proper backup of your Exchange environment.

Service Pack 1

Note that a new cmdlet is available in Exchange SP1 to purge mailboxes: Remove-StoreMailbox. This is also great for situations when you’ve moved a lot of mailboxes and you need to make that space is available in the source database (when moved, mailboxes are soft-deleted). Usage is as follows:

For example, to remove Michel de Rooij’s mailbox from database DB1, after moving it elsewhere, use:

The command to remove all SoftDeleted mailboxes from database DB1 would be:

The new Remove-StoreMailbox cmdlet also enables us to use asingle command for removing all disconnected mailboxes: