Why is MFA not moving archiving or deleting expired contents from the mailbox.?

  • Article

When retention policy stops working, the common questions asked are;

• How do I know if retention policy is processing my mailbox?

• How often does my mailbox is processed by retention policy ?

• Why is MFA not moving emails to archive or deleting expired contents from the mailbox.?

Before we discuss this in detail, let understand some basic concepts

Managed Folder Assistant (MFA). The Managed Folder Assistant is a process that runs on Mailbox servers and applies policies to mailboxes located on that server. The assistant processes items in those folders,Items for which retention is enabled are stamped with the retention age. The retention action specified in applicable on items that have reached their retention age. Managed Folder Assistant is a throttle-based assistant. Throttle-based assistants don't run on a schedule. Instead, they're configured to process all mailboxes on a Mailbox server within a certain period of time (known as a work cycle). Additionally, at a specified interval known as the work cycle checkpoint, the Managed Folder Assistant refreshes the list of mailboxes to be processed. During the refresh, the assistant adds newly created or moved mailboxes to the queue. It also reprioritizes existing mailboxes that haven't been processed successfully for a while due to failures and moves them higher in the queue so they can be processed during the same work cycle.

At times you may need to manually start the assistant during testing, troubleshooting, or to process mailboxes immediately. Below is the command to run MFA against the mailbox on demand.

Start-ManagedFolderAssistant JDoe@contoso.com

In Office 365 , the SLA for a mailbox to be processed by  MFA is 7 days , it means that service will makes sure that a given mailbox will be processed at least once within 7 days, normally the mailbox does get process at least once a day.

Below command can be used to identify when a given mailbox was processed by retention policy.

Export-MailboxDiagnosticLogs "mailbox" – ExtendedProperties

Above command provides some interesting information which is grouped together with an Elc* (email lifecycle) prefix. Above command processes the user’s primary mailbox. If you add the –Archive parameter, you’ll see data for their archive . The output is in XML format.

The output can be formatted in readable format.

PS C:\> $ElcProps = Export-MailboxDiagnosticLogs JDoe -ExtendedProperties

PS C:\> $xmlprops = [xml]($ElcProps.MailboxLog)

PS C:\> $xmlprops.Properties.MailboxTable.Property | where {$_.Name -like "ELC*"}

Description of some of the parameters is as below ;

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.

ElcLastRunSuccessTimeStamp provides the timestamp when the mailbox was successfully processed. While processing a mailbox, at times MFA may encounter errors or exceptions, when exception is encountered , it will log these exceptions, which is stored in mailbox and skip the mailbox from being processed for the current work cycle.

Exception logged while processing the mailbox can be found using below command ;

Export-MailboxdiagnosticLogs " mailbox" -ComponentName MRM

Exception will also contain a timestamp when the exception was logged. By default there are two recent instances of exception saved in the MRM.log.

Timestamp from ElcLastRunSuccessTimeStamp and timestamp in the two exceptions will help us to identify if the mailbox is processed successfully or skipped due to exception. Exception also provides us error logged while processing the mailbox.

Below are some of the common exceptions;

Below exception indicates that the mailbox hasn’t log any exception since its creation, in terms of being process my MFA.

another common exception is as shown below

 

To understand the exceptions related to ‘Resource Unhealthy” we need to understand the concept of “Workload Management”

Workload Management

“Workload Management” was introduced first in Exchange 2013 for the purposes of managing workloads “based on the health of system resources”. Each Exchange workload consumes system resources like CPU, AD requests, mailbox database operations etc. to run the background work.

By design, Exchange 2013, adjusts the resource utilization and preserves user experience automatically through:

  • Intelligent prioritization of work
  • Resource monitoring
  • Traffic shaping. It monitors the health of the following key resources to determine when to throttle workloads
  • Throttling Exchange workloads are based on the health of key system resources which protects and manages the consumption of Exchange resources. Exchange workloads may include background services and asynchronous services such as the Microsoft Exchange Mailbox Replication service and the Microsoft Exchange Mailbox Assistance service. As the health of a system resource begins to degrade, the Exchange workloads that rely on that system resource are dynamically throttled to allow Exchange to continue efficient operation. This throttling, known as shaving the peaks, allows users to continue to use resources without experiencing any noticeable performance degradation. Similarly, when system resources are healthy, background workloads are allowed to speed up and fill the valleys in resource usage.
  • Local server CPU usage
  • Mailbox database Remote Procedure Call (RPC) latency
  • Mailbox database replication health
  • Context indexing age of last notification
  • Context indexing retry queue size Exchange workloads can be assigned one of the following classifications:
  • Each Exchange workload (ex: Calendar Synchronization Assistant workload), is assigned a classification and workload policy settings are used for the classification to control both priority and target resource usage.
  • Urgent
  • Customer Expectation
  • Internal Maintenance
  • Discretionary

For example , below exception is logged while processing a mailbox, it indicates that MFA encountered disk latency issues while processing the mailbox.

The exception also logs the resource which is unhealthy , using the database name logged in the exception we can easily identify whether the primary mailbox or archive mailbox is delayed from being processed.

In short, troubleshooting exceptions like unhealthy resource needs monitoring . There might be no immediate resolution.

Proactively if we have identify that the unhealthy resource is a disk and we have identified mailbox database from the exception. We can find whether the primary or archive mailbox is hosted on that database, we can always opt to move that mailbox to another database.

Above mentioned are some of exceptions that are commonly logged, there are different exceptions that can be logged for different resource or any issue with mailbox itself or even archive mailbox, which needs further investigation.

Gather MRM Data from Office 365 and / or On-Premises

https://gallery.technet.microsoft.com/Gather-MRM-Data-On-56f0de4c

Hope this helps !!

Vikas