White Paper: Personal Archive Enhancements in Exchange Server 2010 SP1


Topic Last Modified: 2011-07-10

Kevin Carker, Sr. Support Escalation Engineer

Several changes are applied to the personal archive mailbox when you install Microsoft Exchange Server 2010 Service Pack 1 (SP1). Foremost among them is the ability to move the personal archive mailboxes to a database that is separate from the primary mailbox—even to a separate database in the cloud, regardless of the location of the primary mailbox. You can use the Exchange Management Shell or the Exchange Management Console to move the archive mailbox.

Additional changes introduced in Exchange 2010 SP1 include the following:

  • The ability to have delegate access to an archive mailbox that is associated with a primary mailbox to which access had been granted

  • The ability to recover an archive mailbox that was accidentally disabled if the primary mailbox was moved

  • Extension of the Mailbox Replication Service to support Mailbox Import requests and Mailbox Export requests

Exchange 2010 introduced the personal archive mailbox, a secondary mailbox that is associated with the same Active Directory account as a Primary Mailbox. The personal archive mailbox replaces .pst files. It provides both security and redundancy. The personal archive mailbox is displayed alongside the primary mailbox folders in Microsoft Outlook or in Microsoft Outlook Web App (OWA), giving users direct access to archived e-mail in the same manner as to non-archived e-mail. You can apply retention policies to a primary mailbox in a way that will move historical data to the personal archive mailbox—or simply move messages between the primary and archive mailbox as required. The personal archive mailbox is published to the client by Autodiscover, thus providing seamless access in both Microsoft Outlook 2010 and Outlook Web App.

Exchange 2010 SP1 lets you move personal archive mailboxes to a separate database from the primary mailbox. However, unless the archive is in the cloud, the mailboxes must reside in the same forest.

This change was made in SP1 for the following reasons.

Archival functionality in the cloud: The ability to manage the archive mailbox in the cloud lets customers host primary mailboxes on-premises and then have archived or “cold data” stored in the cloud. SP1 enables you to use Mailbox Move requests to separate the mailboxes. After the personal archive is moved to the cloud, the on-premises administrator does not have to plan for the cost, performance, and storage of personal archive mailboxes.

Manageability: Mailbox databases that host both primary and archive mailboxes may become extremely large and unmanageable. There are several things to consider when mailboxes become too large, such as scheduled backup and restore times, maintenance windows, and so on. If the databases get too large when filled with both primary and archive data, these scheduled tasks may run into production hours or affect service level agreements (SLAs) in recovery or maintenance scenarios.

Performance & Administration: Hosting archive data and primary data on the same store introduces limitations to performance and administration. Previously, when administrators planned for storage capacity, they were forced to consider the growth of both archive data (which may be required long term) and data in the primary mailbox (which may be required only short term). This creates a challenge for determining the quantity and planning for the cost of required storage.

Performance is another consideration when primary and archive mailboxes are stored together. Primary mailboxes that contain current (or “hot”) data should be readily available. They should be hosted on fast and reliable hardware. Usually, personal archive mailboxes contain non-critical information that is infrequently accessed. Therefore, these can be hosted on slower, less expensive hardware.

Although these recommendations apply generally, customers should design storage solutions to meet their specific business needs, environments, and situations.

Storage Costs: Customers who have a storage area network (SAN) may want to deploy archive mailboxes on less expensive storage as the demand or usage of that data is reduced. This helps to provide different SLAs for the archive mailbox cold data and for the primary mailbox hot data. Many customers have already implemented expensive SAN infrastructures with plenty of storage for future growth and performance usage. Most of these customers do not want to incorporate the archive mailboxes into this currently implemented storage setup, or have to overhaul their existing setup.

The New-MoveRequest cmdlet enables administration of the archive and primary mailbox separately. Exchange 2010 SP1 adds the following functionality to the New-MoveRequest cmdlet.

PrimaryOnly: If this parameter is specified, only the primary mailbox is moved.

ArchiveOnly: If this parameter is specified, only the archive mailbox is moved.

If neither parameter is specified, the cmdlet defaults to the RTM behavior and moves the primary mailbox and the archive mailbox together.

ArchiveTargetDatabase<DatabaseIdParameter>: The ArchiveTargetDatabase parameter is used to designate the target database for the archive mailbox.

If ArchiveTargetDatabase is not specified, the cmdlet defaults to the TargetDatabase behavior and uses the same store as for the Primary mailbox. Alternatively, load balancing logic is used.

The PowerShell cmdlets for managing the archive mailbox (mentioned in the “Move Options Using the Shell” section) are also available in the Exchange Management Console. When you use the New Local Move Request feature in the Exchange Management Console, you are presented with the following additional options:

  • Move only the user mailbox

  • Move only the archive mailbox

  • Move both the mailbox and the personal archive

Additionally, you have the option to browse to select the target mailbox database.

In addition to the delegation enhancements in Exchange 2010 SP1, the Autodiscover feature publishes delegated personal archive mailboxes together with the primary mailbox to Microsoft Outlook 2010 and to Microsoft Office Outlook 2007. Before Exchange 2010 SP1, a delegate could not access or manage an archive mailbox that was associated with a primary mailbox to which access had been granted. After Exchange 2010 SP1 is applied to the server, clients can access all the primary and archive mailboxes to which they have been delegated Full Mailbox Access permission.

The following is an example of a cmdlet that you can use to grant the required rights for a delegate to access both the primary and archive mailboxes of their manager:

Add-MailboxPermission –Identity Manager –User Assistant –AccessRights FullAccess

It is important to understand that a delegate user can access a delegated archive mailbox only when Full Access rights are granted on the associated primary mailbox. This means that the delegate has full access to both the primary and archive mailboxes. In some situations, full access to the primary mailbox would be considered unacceptable. There is no workaround for this requirement.

Manager and Delegate mailboxes must reside in the same forest. Cross forest delegation is not supported. When Outlook starts and communicates with Autodiscover, the backlinks are exposed and read and then returned to the clients. RTM and SP1 both have backlinks. However, they are read and returned only by an Exchange 2010 SP1 Client Access server (CAS). If the add-MailboxPermission task is run on an Exchange 2010 SP1 server, the backlink is updated for the delegate user. If the add-MailboxPermission task is run on an RTM server, the backlink is not updated.

The Backlink cmdlets are as follows:

msExchDelegateListLink: Lists mailboxes that have Full Mailbox Access to the current user

msExchDelegateListBL: Lists mailboxes to which the current user has Full Mailbox Access

msExchMailboxSecurityDescriptor: Added upon completion of Add-MailboxPermission and updated on the delegated account to store a backup of the Access Control Entry (ACE) that is read from the primary mailbox’s security descriptor

The following example shows the Autodiscover XML file output of a user named “The Delegate.” The Delegate has an archive mailbox enabled and is also a delegate user that is granted full mailbox access to “The Manager.” Note the three entries for AlternativeMailbox and the Type of each mailbox.



<DisplayName>Online Archive - The Delegate</DisplayName>

<LegacyDN>/o=KCE14/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=The Delegate/guid=1aad4a1f-1614-48b1-a2a9-b47812a9d24b</LegacyDN>





<DisplayName>The Manager</DisplayName>

<LegacyDN>/o=KCE14/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=The Manager</LegacyDN><Server>LAB1-E14-1.KCE14.LAB</Server>



<DisplayName>Online Archive - The Manager</DisplayName>

<LegacyDN>/o=KCE14/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=The Manager/guid=d4ff3216-e84d-4d65-aa09-64891ef69d8e</LegacyDN>



Prior to Exchange 2010 SP1, you could not recover an archive mailbox that was accidentally disabled if the primary mailbox was moved. Additionally, if the primary and archive accounts were disabled, you could recover only the primary mailbox.

To help you in the recovery process, the following attributes have been added to Exchange 2010 SP1:

  • msExchDisabledArchiveGUID

  • msExchDisabledArchiveDatabaseLink

When an archive mailbox is provisioned, the archive mailbox GUID is populated and the mailbox database is archived to the following attributes:

  • msExchArchiveGUID: 16\32\FF\D4\4D\E8\65\4D\AA\09\64\89\1E\F6\9D\8E

  • msExchArchiveDatabaseLink: CN=Backup Database,CN=Databases,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=<Organization Name>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<Domain Name>,DC=com

When the archive mailbox is deprovisioned, the value in msExchArchiveGUID is added to msExchDisabledArchiveGUID and the value in msExchArchiveDatabaseLink is added to msExchDisabledArchiveDatabaseLink. Exchange can now use these added attributes to populate their values back to msExchArchiveGUID and to msExchArchiveDatabaseLink, respectively, to recover the archive.

Consider the following scenario. An administrator wants to re-provision an archive mailbox for an account named John Smith (jsmith) whose archive was previously disabled. In this scenario, the following occurs:

  • The administrator runs the following cmdlet: Enable-Mailbox –identity “jsmith” –archive

  • Exchange checks for the presence of the msExchDisabledArchiveGUID and msExchDisabledArchiveDatabaseLink attributes.

  • If these values are populated, Exchange checks for the presence of a disconnected mailbox in the store.

    The archive mailbox ues the deletion settings value Keep deleted mailbox for (days) on the mailbox store in which it resides.
  • If the msExchDisabledArchiveGUID and msExchDisabledArchiveDatabaseLink values are populated, and if the disabled archive mailbox exists in the store, the reconnection proceeds. If the archive mailbox has been deleted or is past the retention period, the administrator receives an error message indicating that the mailbox is missing.

  • To force creation of an archive when you do not need to reconnect to the existing archive, or to avoid the missing archive mailbox error, the administrator can use the IgnoreExistingArchive parameter, as in the following example cmdlet: Enable-Mailbox –identity “jsmith” –archive - IgnoreExistingArchive

The Mailbox Replication Service in Exchange 2010 SP 1 has been extended to support Mailbox Import requests and Mailbox Export requests. The following list describes the cmdlets that are added for functionality:

New-MailboxImportRequest: Used to request the import of a .pst file or a set of .pst files into the primary or archive mailbox.

New-MailboxExportRequest: Used to request the export of a primary or archive mailbox to a .pst file.

Both cmdlets include the IsArchive parameter, which is used to specify whether the mailbox import or export command should be directed to the primary mailbox or to the archive mailbox. If you use the –IsArchive parameter, no more input is required because the archive mailbox does not have a unique identity in the recipient context.

Administrators can now use the mailbox import request to import the data from the .pst file into the archive mailbox and to manage the data by using the Exchange Management Shell. This differs from the previous arrangement that required users to import the data from the .pst filto the archive mailbox or to perform a manual import by using Outlook.

Changes have been made to the Mailbox Replication Service (MRS) to help you move the archive mailbox to a separate database in the cloud, regardless of the location of the primary mailbox. The primary mailbox can remain on-premises.

You can use the following example cmdlet to provision both a new primary mailbox on-premises and an archive mailbox in the cloud:

New-Mailbox –Name: TestUser –RemoteArchive –ArchiveAddress:CloudDomain.com

When you want to provision a new archive in the cloud for an existing on-premises mailbox, the mailbox-enabled user already exists in the datacenter. In this scenario, the on-premises administrator runs the following cmdlet:

Enable-Mailbox –Identity: TestUser –RemoteArchive –ArchiveAddress:CloudDomain.com

When you plan a rollout of personal archive mailboxes, you must consider licensing requirements. For more information about licensing requirements, see Microsoft Exchange Licensing. In addition, see the following Microsoft Office articles:

Microsoft Office Introduction to Personal Archive

Compare server integration features between Office suites available through volume licensing

For the complete Exchange 2010 documentation, see Exchange Server 2010.