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
Thoughtsofanidlemind's Blog 
Pingback: Weekly IT Newsletter – August 11-15, 2014 | Just a Lync Guy
Pingback: NeWay Technologies – Weekly Newsletter #108 – August 14, 2014 | NeWay
Pingback: NeWay Technologies – Weekly Newsletter #108 – August 15, 2014 | NeWay
I enjoyed this article. I found it very informative about MRM policy’s.
Thanks for sharing.
Pingback: Document Retention - What's in Your File Cabinet? | Create Resumes | Find Jobs | FastJobz.Com
Tony:
We are getting set to formalize a retention policy in our Exchange 2010 SP3 (Outlook 2013) environment. I want to have a Default Policy Tag to delete messages after 27 months, but I’d also like to be able to back that up with a second DPT to move content to the online archive after say 4 months. In addition, I will throw in some personal tags to allow the user to archive/delete certain folders sooner or to block folders from archiving.
My problem is that although Exchange allows adding two Default Policy Tags to one policy (one for retention and one for archiving), my tests show that the archive tag is ignored. I can only have one or the other. Seems like Exchange only supports one DPT per policy. Microsoft’s own documentation is very unclear on just how many DPT’s can be combined in one policy, and I’ve never seen a sample policy that has two DPTs. https://technet.microsoft.com/en-us/library/dd297955.aspx
That article has been updated per Exchange 2013, but I cannot tell if 2013 supports this.
As it stands right now, I have to set a DPT for retention and then a user must set a personal tag to accomplish the archiving. This is not optimal. Am I missing something?
You can have two DPTs in a policy; one for archiving and one for deletion. The archive tag will only be processed if a mailbox has an archive. You can certainly have a tag that archives content after 4 months and then deletes them after 27 (i.e. a further 23 months after archival). You can actually have a third DPT in a policy – one to process voicemail items.
Thanks for the quick reply. If what you are saying is true, then it just isn’t working properly in my policy for some reason. I have the policy applied to my test mailboxes which do have an archive, but when I run the MFA against these mailboxes, the folders and messages only indicate that there is a retention policy applied. They do not show that the messages will be archived,
It is true. Have any items been moved to the archive after 4 months? That’s the real test.
In my own environment, items are archived after 2 years and deleted after 5 (unless tagged for retention with a personal tag). It works.
I presumed the archive DPT wouldn’t work if there was no visual indication in either the message or by looking at the folder policy. Perhaps it just doesn’t show up?
Do you know if having two DPT’s in a policy was something added over the course of Exchange 2010 Service Packs? I worked on an Exchange 2010 RTM, and I remember experimenting with two DPT’s in a policy. The MFA would throw an error in the event log processing a mailbox. I traced this to having two DPT’s. When I took one out, the MFA processed the mailbox. That led me to the conclusion you can’t have two. Under SP3, I don’t get the error, but then again, I don’t see anything to lead me to believe the archive DPT is working, either.
Still, you say it works. I’m glad to hear that. Now I have to try to make it work. I will test some more.
a) I don’t think archiving actions show up in client user interfaces. The most important thing to indicate here is deletion.
b) AFAIK, the two-DPT-in-a-policy arrangement has been in place since at least Exchange 2010 SP1.
c) The real test of an archive tag is whether items are moved into the archive. In fact, it is the only way to verify an archive tag.
Tony, thank-you so much. I just figured out the issue. First, you are right. Archive actions do not show up in the client interface unless the user applies a Personal Archive Tag. That is confusing.
My second problem was that I had applied Retention Policy Tags to system folders like Inbox and Sent Items in my policy. When I took those out of my policy, the archive DPT kicked in and moved old mail out!!!. Microsoft does state that the DPT only applies to folders that don’t have other tags. I’m going to clean out some of the unnecessary RPT’s from my policy. I should only need those for folders where I want to override the DPT. I had originally presumed that the DPT only applied to all other *non-system folders.* That was my mistake. I can actually simplify my policy quite a bit now.
By the way, we are also combining this new policy with group policies forbidding PST use or creation. I have been testing a GPO I made for this purpose, and it is really quite effective. Users can’t open, export to, or even add to a PST. This may come back to haunt us. We will probably need to make some exceptions here and there.
So what happened here is that your more specific folder tags applied to the default folders (like Inbox) trumped the generic catch-all DPT… That works.
Tony, in a prior comment, I mentioned that my company was formalizing a policy to set retention at 27 months. That is now in effect. There is a default policy tag moving messages into the archive after several months and a second default policy tag deleting old mail at 27 months. This is all working just fine, but there were some people who had an online archive before there was a formalized policy. For them, we had set retention at 4 years purely based on reasonable practice. With the new DPT of 27 months, it seems like all messages that were already in the archive will still have the older retention of 4 years. Is there any way to forcibly update retention against specific online archives?
We run Exchange 2010
Are the items in the archive mailboxes tagged with a retention tag? If so, you can change the period of the tag and MFA will reevaluate and restamp the items. Or you can delete the tag from Exchange to force the default tag to be applied.
Yes, the tag shows 4 years. It was based on the original DPT of 4 years that was used in the policy. My early tests made me think replacing the original DPT with a 27 month tag would only process and update the primary mailbox while not updating the archive.
Tags should be respected by both archive and primary mailboxes and I’d expect a change to the retention period for a default tag to be assessed by MFA and applied to archived items too. After all, if it wasn’t, then out-of-policy data would be incorrectly retained and that’s not a good thing. It will take time for any change to be applied across all mailboxes though… But I will ask some folks I know who know more about this than I do.
My Microsoft contacts say updating the retention period for the default tag should have the desired effect. MFA will revaluate the tag on the archived items and those older than 27 months will be removed.
This is great news. Thanks so much for checking this out. Perhaps I just didn’t allow enough time to see the archive mailbox processed. I guess the server might not have gotten to it in the first 24 hours.