Archive Mailboxes, retention management and items to consider.

 A conversation with one of my clients today spawned thoughts once again of the age old battle between Users, Management and IT Admins that always turns out to be a heated argument with lots of pushing and shoving. Users think we are punishing them with our imposed limits and quotas. Management pulls us in many directions of budget constraints halting our storage spending and then turning right around wanting to keep all "their" data forever. All said and done, we are left holding the bag trying to come up with a plan to balance the needs of the business, the wants of the users, the constraints of budget and the requirements of Legal for regulatory retention policies. There are many things to consider here that we are touching on yet either like disaster recovery sla, backup completion times, database size limits, mailbox size limits, server performance due to item counts, and on and on.

 With the advancements in each build of Exchange we have continued to increase our I/O efficiency and doing so has made our product team point us at cheap storage alternatives like JBOD with multiple copies of our data to keep us safe. Even with these advancements, having multiple copies of databases still subtracts from our budget on storage, as even cheap storage is not free. As long term Exchange admins, our brains are embedded with thoughts of performance issues due to high I/O and long weekends of restoring or dealing with bad disks which makes us hesitant to give up our high performance quality storage and use a JBOD solution.

 Using the quota or expiration retention system places the decision of what to keep on the users. When they get close to their limit or expiry, they must decide what to keep and what to delete or even what to copy out and place in word docs or other forms of personal record retention. However, as my client said to me today, management simply comes to him with justification for why certain mailboxes should have higher quotas or longer retention and these mailboxes are ever increasing which makes both of these methods inefficient.

 Now we introduce the option for Archive mailboxes with doesn't answer all the problems by any means but it does help. From TechNet "Understanding Personal Archives" : Personal archives (also known as on-premises archives) help you regain control of your organization's messaging data by eliminating the need for personal store (.pst) files and allowing users to store messages in an archive mailbox that’s accessible in Microsoft Exchange Server 2010 or a later version, and in Microsoft Office Outlook Web App. As a best practice recommendation we advise to create separate mailbox databases to contain your Archive mailboxes. The nature of an archive, generally means that it will not be accessed at near the rate a primary mailbox would be accessed and with that means less I/O to and from disk subsystems which in turn leads to breaking those concerns of performance bound scenarios. This opens the door for JBOD or cheap storage exploration to home these databases on and save our storage budget spending.

 Why Archive? Archiving reduces risks from PSTs, it reduces eDiscovery costs, reduces risk in delete by managing content lifecycle and we meet Legal and regulatory requirements as well as business requirements. Unlike PSTs, this option is accessible from any computer that a user interfaces with using OWA and Outlook mail apps. We reduce the risk of corrupted PSTs and data loss whether On-Premising using Database Availability Groups or High Availability implemented in O365, this data can be replicated and preservation greatly increased. Users see and get a consistent experience where they can manage and access their data just like they do their primary mailbox with the ability to drag and drop, use inbox rules and use personal tags.

This again does not win our war against anti-retention and MRM rebels, but it does give us another option that offers us a flanking option that helps win a small battle! Now, using our retention policy strategy (Retention tags and retention policies) we can assign Tags to manage our data for us. Tags have 3 main controls, the Tag Type, the Action, and the Age. The Tag Type determines where it is applied, the Action determines what the tag does which can only be, Move, Delete, or Do Nothing and the Age determines when the action is performed.

Tag Types, we have three to choose from here, DPT - Default Policy Tags, RPT - Retention Policy Tag, and PT - Personal Tag.

DPTs, think of them as a catch all for the mailbox. They apply to the entire mailbox and the archive mailbox. If you only have the DPT then it is like full control for the admin to state delete all items in 5 years and you are done. This is mainly used in environments where the requirements are strict and there is no leeway.

*Note* If you do not want your calendar and tasks deleted or moved to archive the following registry key on your mailbox servers will work around this (Post Exchange 2010 SP2 RU4).

Path: HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeMailboxAssistants\Parameters

Name: ELCAssistantCalendarTaskRetentionEnabled


Value: 0 = Do not process Calendar and Task folders

Value: 1 = Process (Default with Exchange 2010 SP2 RU4)

RPTs, this is our default folder tag,  default folders are the folders that are there by default when a mailbox is created such as the Inbox, Sent Items, Deleted Items, Junk Mail, Tasks, Calendar etc. This tag allows for granular control. You can do things like create tags to empty the Deleted Items folder every 30 days and/or delete the Junk Mail folder every 15 days. However, you need to be careful with this because users will get confused when their items start disappears randomly and getting complex here can make this more difficult to manage for them.

PTs, only available to users in Outlook 2010 and later or users accessing Exchange mailboxes through Outlook Web Access, allow users to create their own tags that they can apply to user created folders or items. This sets an exception on a item or a folder that the user wants to manage. Say a user gets a company mailer daily and they want it deleted after 3 days, because if they haven't read it in 3 days it is irrelevant. They can create a tag to do this and have it manage that for them. Or they can have the tag move it to their archive mailbox if they wish for safe keeping.


So you say how can I make sure items are held for 5 years even if a user deletes an item? Because the above does not do that for us, items are being for deleted or moved by our tags but forced retention is not there. We do this with adding In-Place Hold to the mix. In-Place Hold and Litigation Hold are available in Exchange 2013, Litigation Hold holds ALL items in the mailbox until the hold is removed. In-Place Hold allows more of a granular control to decide what you want to hold and how long to hold it. You can place a user on multiple holds by using the "OR" operator and if a user is place on more than 5 holds at one time, then everything in the mailbox is held (just like Litigation Hold) until the count of holds is less than 5.


*Note* For Custom Tags, Litigation Hold and In-Place Hold, a Enterprise CAL is required as they are considered premium features.


So, there are some actions you can take as best practice as far as implementation goes. However, when it comes to overall best practices, your company's needs, storage requirements, user needs, laws and regulations imposed for your type of business, SLAs and etc etc etc have to all be taken into account to understand and define the best practice for you.


The following documentation should aid you in your research:

Retention tags and retention policies

Exchange Team Blog : compliance

Create a Retention Policy

Understanding Personal Archives

Geek out with Perry: Exchange Archiving

Channel 9 video from Bharat Suneja: Preserve, Delete, and Archive in Exchange


In-Place Hold and Litigation Hold

Comments (1)

  1. Byron Mobley says:

    Good overview of Exchange Archive mailboxes. Thanks for providing the additional links for clarification.

Skip to main content