The Managed Folder Assistant (MFA) debuted in Exchange 2007 as part of Microsoft’s first attempt to introduce a subsystem called Messaging Records Management (MRM) intended to help users retain information that might be required for purposes such as audits and administrators impose some control over folders in terms of how long items could be retained. MFA is the component that imposed the control by implementing whatever policies are created by administrators and assigned to mailboxes. For example, if an MRM policy mandated that items could only remain in the Inbox for 30 days, MFA clears out items from the Inbox once they exceed the set retention period.
MRM 1.0 was successful in some environments but failed in the majority because its implementation requires users to change working habits in order to retain items. Microsoft received a lot of feedback from companies and introduced a new approach in MRM 2.0, which is the version included in Exchange 2010. MRM 2.0 still includes retention policies but the big difference is the introduction of retention tags that can be assigned to folders, items, or even conversations. The different types of retention tags and how they can be deployed is a topic that can easily span thousands of words so I won’t go into detail here. Suffice to say that MFA continues in Exchange 2010 with an expanded role as it not only has to deal with the new retention tags but now has to be able to process archive mailboxes too.
Exchange assistants are implemented as background processes and have to run on a server to be useful. Prior to Exchange 2010 SP1 the MFA ran on a schedule basis. In other words, you assign a slot that might span a number of hours during which the MFA processed mailboxes. Typically, the slot is scheduled in the dark of the night when servers are lightly loaded. Scheduled background processing of Store contents has been a feature of Exchange for many versions but is largely replaced in Exchange 2010 by 24x7 processing that is throttled to ensure that servers remain responsive to users.
When it processes a mailbox, the MFA examines items and stamps them with the appropriate retention tags and dates so that the items will be retained according to policy. Of course, if a retention policy is not assigned to a mailbox the MFA won’t have much to do. Note that assigning an archive to a mailbox means that Exchange automatically applies its default archive and retention policy to the mailbox, an action that can have a somewhat unfortunate side-effect.
A major reason to move away from schedules is because of the growing number of mailboxes supported by servers and the consequent increase in the amount of work that needs to be done to maintain their contents. A scheme that works well for five hundred mailboxes is not necessarily the best when ten thousand mailboxes have to be processed especially, as is the case with Exchange 2010, the size of those mailboxes and the number of items contained in the mailboxes have also increased.
In the case of the MFA, a schedule that restricts its work to a few hours could lead to a situation where the MFA would not be able to process every mailbox on a server nightly. Failure to complete every mailbox is not catastrophic for some types of background maintenance but it becomes a real problem when the reliability of retention policies depend on the ability of the MFA to process every mailbox at least once daily. After all, if the MFA can’t get to process a mailbox, retention policies will not be applied and tags will not appear in client interfaces.
To solve the problem, Exchange 2010 SP1 introduces the concept of workcycles for its background assistants. A workcycle is a way of expressing an expectation that a set amount of work will be done in a certain period. It is then up to the assistant to whom the workcycle is applied to figure out how much data needs to be processed in the period and at what speed the data must therefore be processed to meet the requirements of the workcycle. In an on-premises environment, workcycles for the various assistants are set on a per-server basis using the Set-MailboxServer cmdlet. There is no UI in the Exchange Management Console (EMC) to manage workcycles but you can view their current settings with the Get-MailboxServer cmdlet (select *workcycle from the output). You can’t run either of these cmdlets in an Office 365 environment as these are operations that Microsoft reserves for itself.
In the case of MFA, the workcycle requires the MFA to process every mailbox at least once daily and the processing proceeds on a constant basis 24 hours a day. Interestingly Microsoft uses a seven-day workcycle for Office 365 mailboxes.
Of course, sometimes MFA throttles itself back to almost a static state because the server is under other load but once server load drops as users find other more productive things to do with their lives than send email, MFA cranks up its activity to get its work done. Inevitably, most of the processing is done at night but some occurs during the day.
It is possible that you might need to run the MFA immediately for a specific mailbox to ensure that retention policies are applied to that mailbox. To do this, run the Start-ManagedFolderAssistant cmdlet and pass the identity of the mailbox. For example:
Start-ManagedFolderAssistant –Identity ‘[email protected]’
You’ll need to hold the Messaging Records Management role before the Exchange Management Shell (EMS) allows you to run this command. The same command is available for both on-premises and Office 365 administrators.
Regretfully, the EMC doesn’t include any UI to allow you to execute this command or view the results of its work, or indeed to interrogate Exchange about what work the MFA might have executed on a server in the last workcycle. But then again EMS doesn’t include a cmdlet to expose this information either. Perhaps Microsoft will cast some light into this dark corner of Exchange in a future release. It would be nice, for instance, for a system administrator to be able to receive an emailed report of all of the mailboxes that MFA had processed together with an indication of what had been done for each mailbox.
Follow Tony Redmond on Twitter @12Knocksinna
