Behind the scenes with the Managed Folder Assistant

Given the amount of information accumulating in ever-swelling mailboxes, the Exchange Managed Folder Assistant (MFA) has a lot of work to do each time it sets out to make sure that retention policies have been correctly applied to mailboxes. 

First, some Messaging Records Management (MRM) basics. Exchange 2010 and all subsequent versions use MRM 2.0, which is based on the application of retention policies to mailboxes. A retention policy is composed of tags, each of which instruct Exchange how items should be processed. Folder tags deal with the standard folders found in every Exchange mailbox (like Inbox, Sent Items, and so on), personal tags are available for users to apply to individual items, a conversation, or a complete folder (except for standard folders), and default tags that apply to everything that doesn’t already come under the control of a tag. Each tag defines an action (delete or archive) and a retention period (in days).

Putting everything together, when MFA processes a mailbox, it makes sure that each item has the right tag and applies the defined action to items whose retention period has expired. MFA runs continually in the background and attempts to process every mailbox daily. It is throttled to ensure that MFA does not consume valuable system resources when they are needed by other Exchange components. Although I have not been able to confirm this, I believe that MFA runs on a more relaxed workcycle within Office 365.

In an on-premises deployment, you do not have to apply retention policies to mailboxes. In effect, you can decide that users are well able to manage the contents of their mailboxes and should be left to get on with the task. Inside Office 365, Microsoft applies the “Default MRM policy” to new mailboxes automatically to ensure that their contents are managed from the start. You can remove a retention policy (even with Office 365) if you want with the Set-Mailbox cmdlet. For instance:

Set-Mailbox –Identity ‘CEO Mailbox’ –RetentionPolicy $Null

Most administrators think that the combination of MRM and MFA is a very good thing.  I share this feeling as the automated clear-out of the junk that accumulates inside mailboxes can only be good for an Exchange server. Reduced mailbox sizes, reduced backup times, smaller databases, less requirement for storage, and so are all advantages that a well-planned MRM implementation can deliver.

But the big problem with MFA that is mentioned time and time again is its “black box” nature. Aside from running the Start-ManagedFolderAssistant cmdlet to tell MFA that it should immediately process a specific mailbox, there’s not much that is visible about its processing. Sure, you can see the effect of MFA by noting that items are moved from folders into the Deleted Items folder or into an archive mailbox (something that still baffles some users), but there’s no easy way to discover what MFA does when it processes a mailbox.

Unless you use the Export-MailboxDiagnosticLogs cmdlet (available for Exchange 2010, 2013, and Online). This cmdlet is really intended to validate that all is well within a mailbox but it does return some interesting information about MFA, grouped together with an Elc* (email lifecycle) prefix.

You generate a mailbox diagnostics log for a specific user as follows.

Export-MailboxDiagnosticLogs –Identity TRedmond -ExtendedProperties

This command processes the user’s primary mailbox. If you add the –Archive parameter, you’ll see data for their archive (if available). The output is in XML format and you can find the following fields.

This output provides some insight into what MFA did the last time it processed a single mailbox. By itself it won’t reveal too much about the black box innards of MFA, but something is better than nothing…

Follow Tony @12Knocksinna