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.
|ElcLastRunTotalProcessingTime||The total time (in milliseconds) that the Managed Folder Assistant spent processing the mailbox in its last run.|
|ElcLastRunSubAssistantProcessingTime||The total time (in milliseconds) that the ELCTagSubAssistant (the part of MFA that handles item tagging and expiration). Only time spent processing items in the IPM folder tree is calculated. Time spent processing items in the Recoverable Items folder structure (dumpster) is ignored.|
|ElcLastRunUpdatedFolderCount||The number of folders that were updated by MFA in its last run.|
|ElcLastRunTaggedFolderCount||The number of folders tagged (or untagged) by MFA in its last run.|
|ElcLastRunUpdatedItemCount||The number of individual items that were tagged (or untagged) by MFA in its last run.|
|ElcLastRunTaggedWithArchiveItemCount||The number of items that MFA updated with an archive tag in its last run.|
|ElcLastRunTaggedWithExpiryItemCount||The number of items that MFA updated with an expiry (delete) tag in its last run.|
|ElcLastRunDeletedFromRootItemCount||The number of items MFA deleted from the IPM folder tree in its last run.|
|ElcLastRynDeletedFromDumpsterItemCount||The number of items MFA deleted from the Recoverable Items folder structure in its last run.|
|ElcLastRunArchivedFromDumpsterItemCount||The number of items MFA moved from the Recoverable Items folder structure to the archive mailbox in its last run.|
|ElcLastRunArchivedFromRootItemCount||The number of items MFA moved from the IPM folder tree into the archive mailbox in its last run.|
|ElcLastRunSuccessTimeStamp||The last time MFA successfully finished processing a mailbox.|
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