Exchange messaging records management (or MRM for those who deal in acronyms) has long been an interest of mine, if only because it seems to me that it makes a heap of sense to have some intelligence that processes user mailboxes to clear rubbish out on a regular basis. Not that all mailboxes contain such rubbish, you know. Clearly mine does not and is well known in select circles for such cleanliness, which is why I was well-qualified to speak about retention policies at the Microsoft Exchange Conference (MEC) last April.
We live in a world of bloated mailboxes crammed full of items that really should be kept for as long as it takes to locate the “delete” key. It amuses me just how much of a mailbox is occupied by out of office notices, non-delivery receipts, and copies of service messages informing the recipient that some long-gone event is imminent, and so on. Not to mention the proliferation of content caused by that fateful decision so long ago to make Outlook’s default option to include the text of a preceding message in its reply. How many petabytes of crud has built up in mailboxes? No one knows, but it’s a bit like those fat balls that accumulate in public sewers – a mess that is only dealt with when it causes a problem.
In any case, the introduction of retention policies in Exchange 2010 was a very welcome step forward in addressing the problem. Of course, it was Microsoft’s second attempt at MRM because they had shipped MRM 1.0 in Exchange 2007. That didn’t work out so well because MRM forced users to move items into folders. MRM 2.0 as used in Exchange 2010, 2013, and Exchange Online (Office 365) is so much better because it automates the clean-up process and does everything in the background. Following my previous analogy, like water flushing away in a well-maintained sewer, the Exchange Managed Folder Assistant (MFA) scours mailboxes to remove old and unwanted items to keep mailboxes and databases as clean as possible.
Administrators have to do some work to set up an MRM framework. Retention policies have to be defined and then assigned to mailboxes. The retention policies are built from tags and these have to be considered in terms of what folders they should control and what action should be taken. In most cases, it’s sufficient to define a policy that contains a set of tags to control the major default folders (Inbox, Sent Items, Deleted Items) so that these folders are cleaned up by removing items after 30 days or so, some personal tags to allow users to mark items for long-term retention, and a default tag that applies to the rest of the mailbox to clean up aging items that have been stuffed into folders and forgotten.
To get the ball rolling, Microsoft provides a default MRM policy in Exchange 2010 and Exchange 2013. This policy is there to support the deployment of archive mailboxes and is applied automatically to a mailbox when it is enabled with an archive. The logic is good because the effect of the retention policy is to move items from the primary mailbox into the archive as soon as they are aged out by the default tag contained in the policy. The effect on some installations who deploy the retention policy without realizing its effect and impact can be “interesting.”
The use of retention policies are covered in all of the Office 365 plans (the spreadsheet accessed through this link is a very good resource to know what’s covered by a particular plan). In an on-premises environment, you don’t need to own enterprise CALs to use the default MRM policy. This is because the policy is there to support archive mailboxes, which are also covered by the standard Exchange CAL. However, enterprise CALs are required as soon as you begin to define and assign your own retention policies. This isn’t usually a big thing because most companies have bought enterprise CALs for other purposes, like deploying custom ActiveSync policies.
But if you’re in a situation where you only have standard CALs and want to use retention policies, you can modify the default MRM policy to fit your own purposes. This includes adding or removing tags from the policy, changing the retention period or retention action for tags, or disabling tags. In the past this was not thought to be possible, probably due to a misunderstanding of the licensing terms and some confusion about what was and was not covered by the standard CAL. But Microsoft has recently updated the TechNet documentation to explicitly state that you can modify the default MRM policy to your heart’s content.
Note that the default MRM policy is automatically assigned to new Exchange Online mailboxes as they are created. This is different to Exchange on-premises where the policy is only assigned when an archive is enabled. The logic here must be that assigning a retention policy from scratch makes sure that mailboxes stay under some form of control, even if their users are unaware of the fact (and administrators too, if you hadn’t learned about this). An archive mailbox is not automatically created for Exchange Online users, so MFA ignores the tags in the policy that have a retention action of “move to archive.”
For more information on how to design, deploy, and debug retention policies and MFA, see chapter 11 of Exchange 2013 Inside Out: Mailbox and High Availability.
Follow Tony @12Knocksinna
