Microsoft's Messaging Records Management strategy still evolving

Microsoft first introduced Messaging Records Management (MRM) in Exchange 2007. This version is commonly referred to as MRM V1.0 and is based on the concept of “managed folders”. A managed folder can be one of the default folders such as the Inbox or Sent Items or a folder specifically designed for retention purposes, such as one called “Audit 2011” that might be assigned to store items required for this year’s audit exercise. MRM groups a set of managed folders into policies that are then assigned to mailboxes. The act of assigning a policy creates the purpose-designed folders covered by the policy in the user’s mailbox and the user can then move items into those folders. Each folder has a retention action and period assigned to it and the Managed Folder Assistant (MFA) processes items in the background according to those actions and periods.

MRM V1.0 sounds like it could work and indeed, in the hands of administrators who build well-designed and logical policies and users who have the discipline to realize how the managed folders should be used, MRM V1.0 does work. However, for the vast majority of humanity, MRM V1.0 foundered on the single salient fact that most of us are just too busy to take too much notice of the managed folders carefully constructed by administrators and therefore carried on as before. The result was that the valuable items that should have been moved into the managed folders remained scattered throughout the mailbox. Such is life. Technology often fails after it encounters the hard reality of user behaviour.

Microsoft therefore went back to the drawing board and launched MRM V2.0 in Exchange 2010. Instead of expecting users to do the right thing, MRM V2.0 allows administrators to build policies that instruct MFA to move items into the Deleted Items folder, blow them away totally, or move them into an archive mailbox if one exists. MRM V2.0 includes the concept of default policy tags that cover every item in a mailbox that does not have a more specific retention tag applied to it. A more specific retention tag can be inherited because an item is held in a folder. MRM V2.0 supports specific tags that can be applied to each of the default folders as well as personal tags that a user can apply to an individual item, folder, or conversation. For example, you might decide that you never want an item to be deleted and can accomplish this goal in a practical sense by applying a personal tag that instructed MFA to respect a retention period of 25 years or more (after which you probably won’t be too worried if the item eventually winds its way to the great byte wastebasket in the sky).

MRM V2.0 seems much more flexible and powerful, if only because it supports both delete and archive actions. Some experts beg to differ and there has been much spirited debate on the topic in various communities. In any case, Microsoft has thrown its weight behind MRM V2.0 and that’s what we have to use going forward.

Exchange 2010 supports both MRM V1.0 and 2.0 policies. Exchange 2010 RTM included the UI to work with MRM V1.0 policies but this UI was replaced in Exchange 2010 SP1 with UI that allows administrators to create retention tags and policies and apply them to mailboxes. Logically, a mailbox can only be assigned either an MRM V1.0 or an MRM V2.0 policy and the two do not mesh or integrate. In fact, migration from MRM V1.0 to MRM V2.0 is a purely manual affair.

Microsoft also made some fairly fundamental changes to MRM V2.0 in Exchange 2010 SP1 when they cut back the set of supported actions to a simple choice of either delete or archive. Other options that appeared in the RTM version of Exchange 2010 such as “simply mark the item as expired” disappeared, perhaps because users wouldn’t know what to do with such advice. A big change was also made to the way MFA processes mailboxes as part of the move that Exchange has made to put its background assistants on a “workcycle” basis rather than being constrained to a set period daily (usually about 4 hours beginning around 1am). In practical terms, operating on a workcycle means that MFA attempts to process retention policies for mailboxes in such a way that each mailbox is processed at least once a day. This avoids the danger that existed under the previous scheme that a mailbox might never be processed because MFA had too much work to do to complete in the assigned period. My experience of MFA in Exchange 2010 SP1 is that it now processes mailboxes more reliably than before and, if necessary, you still have the choice to run MFA manually to force it to process a mailbox. For instance, you might run MFA to process a mailbox to force retention policies and tags to appear in the client UI if you don’t want to wait for MFA to pick up the mailbox in its regular workcycle.

Of course, no messaging record management scheme can work really satisfactorily if clients progress in a state of blissful ignorance. To apply MRM V2.0 tags to items you’ll need to use Outlook 2010 or Outlook Web App (OWA). No other client incorporates the necessary UI to deal with retention tags. Of course, MFA will continue to do its thing in the background and it will process items in a mailbox soon after an administrator assigns a retention policy to the mailbox. This can sometimes have an unfortunate effect as users don’t understand why Exchange has automatically moved items around in the mailbox. Indeed, a side-effect of enabling an archive mailbox is that Exchange assigns the default archive and retention policy to the mailbox and this can result in a lot of information moving into the archive, sometimes to the enormous surprise and disappointment of the user.

Today’s EHLO post from the Exchange development team reveals that MRM V2.0 is still being tweaked. It’s good that work continues to refine MRM and to communicate to administrators exactly how retention tags and policies work together to create a solid messaging record management environment. The question is whether MRM V2.0 has been received any more successfully in production than its predecessor. My experience is that MRM V2.0 is more successful. What do you think?