IT tutorials

Microsoft Exchange Server 2013 : How the Managed Folder Assistant implements retention policies (part 1) - Behind the scenes with the MFA

11/21/2014 2:55:04 AM
- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019

After you apply a retention policy to a mailbox, you can either wait for the next scheduled run of the MFA or start it manually so that the new policy is applied immediately. When the MFA runs, it performs the following tasks:

  • It applies the tags specified in retention policies to the mailboxes covered by these policies and stamps the items in the various folders covered by the policies with the appropriate tag name and expiration date.

  • If a policy defines a retention or expiry period for items, it stamps a Messaging Application Programming Interface (MAPI) property (ElcMoveDate) on the items, indicating the date and time from which the retention period will start. A future run of the MFA can then use this date and time to calculate when to delete an item or mark it as expired.

  • It locates items in folders that are past their expiration date and takes whatever action is defined in the policy (delete, age out, move to another folder).

The MFA works on a work cycle basis: it assesses the expected workload in terms of the number of mailboxes it has to process and then spreads out its processing across the complete window. For example, if 600 mailboxes are to be processed over three hours, the MFA creates its own internal schedule to process 200 mailboxes per hour or roughly three mailboxes per minute. In addition, a checkpoint is defined for the work cycle, at which time the MFA looks for new mailboxes that should be added to its list for processing. The default values for the work cycle and checkpoint are both 1 day, so the MFA attempts to process every mailbox in its list daily and checks for new mailboxes daily. The MFA logs event 9017 when it begins to process mailboxes, but the more important event to look for is 9025, logged when the MFA has had to skip a mailbox for some reason, such as when the mailbox is being moved to another database.

Overall, the work cycle mechanism makes more effective use of server resources in an easy and relaxed manner throughout the day and doesn’t create potential spikes in demand.

You might want to run the MFA immediately, perhaps to apply a policy to a group of users for the first time. Forcing immediate execution for a selected mailbox is useful when you start to apply policies to mailboxes and want to gauge the effect of the policy by examining the contents of a known mailbox. This might be easier than asking users what happened to items in their mailboxes (especially if you’ve made a mistake with the policy and just removed half the items from the mailbox). To force processing for a selected mailbox, specify its name with the –Identity parameter:

Start-ManagedFolderAssistant –Identity 'Akers, Kim'

To process a group of mailboxes, either provide a set of mailbox identifiers as input or use the Get-Mailbox cmdlet with a filter to retrieve a set of mailboxes and pipe it as input to Start-ManagedFolderAssistant. In the first example, two mailbox identifiers are provided as input. In the second, you process all the mailboxes in a database. In the third, you use a filter to find all the mailboxes from a particular office.

"Redmond, Tony", "Akers, Kim" | Start-ManagedFolderAssistant
Get-Mailbox –Database 'VIP Data' | Start-ManagedFolderAssistant
Get-Mailbox –Filter {Office –eq 'Dublin'} | Start-ManagedFolderAssistant

The time required for the MFA to complete its run depends on the number of mailboxes and the number of items to which it has to apply retention policies. A run on a small server that hosts a few hundred mailboxes will complete in a couple of minutes unless the mailboxes hold thousands of items. However, processing 7,000 mailboxes, each of which holds an average of 20,000 items, could take several hours, especially if the server is loaded with other tasks or the policies cause a heavy I/O load because many items are permanently removed or moved from primary to archive mailboxes. You should monitor the first runs of the MFA on a server to gauge the scope of the activity and how long a normal run takes to complete. Equipped with this information, you can quickly assess whether future runs are progressing as expected.

After the MFA has applied a new policy to a mailbox, the next time the user connects to the mailbox with a client that supports retention policies, she will see that retention tags are shown on items and the retention policy options are visible. Another important point that you should understand is that if you apply a retention policy that contains a default policy tag, the MFA stamps the default tag on every item in the mailbox. This action forces Outlook to download the complete contents of the mailbox the next time the client connects and synchronizes with Exchange. Such a massive synchronization has the potential to flood a network and keep clients fully occupied for a long time. Including a default archive tag in a policy does not have the same effect because the MFA does not stamp every item with this tag.

Behind the scenes with the MFA

When the MFA first processes a mailbox, it creates a hidden FAI item of type IPM.Configuration.MRM in the Associated Contents table of the Inbox folder. The item stores MRM configuration in XML format in a PR_ROAMING_XMLSTREAM property. (PR = property; Roaming means that the information is available wherever the client connects, and XMLSTREAM indicates the type.) The MFA then updates the item any time a change occurs in the retention policy assigned to the mailbox, such as when a new personal tag is added to the policy. If a new retention policy is assigned, the MFA updates the item with details of that policy.

Exchange uses FAIs as a means to hold configuration and other data it needs to store in a mailbox but does not want to reveal to users when they run clients such as Outlook. The item the MFA creates holds details of the retention policy that has been assigned to the mailbox, including details of the retention tags the client needs to display in its user interface. If the item does not exist in the mailbox, a client remains unaware that a retention policy is in force. This is why the MFA has to process a mailbox before the client user interface is populated with details of the policy. In addition to the tags provisioned through the retention policy, the item also holds information about any personal tags the user has selected for his own use through Outlook Web App Options . As noted earlier, you cannot see this information with a normal client, but you can with the MFCMAPI utility by opening a mailbox that has been assigned a retention policy, opening the Inbox folder, and then opening the associated contents table before finally identifying the MRM item in the set held in the table. Figure 1 shows the details of the MRM configuration item as exposed by MFCMAPI, and you can clearly see details of the retention tags specified in the policy in the text box.

A screen shot illustrating the contents of the folder-associated item that contains the MRM policy information for a mailbox, using MFCMAPI to access the information. The lower text box shows details of the retention tags included in the policy.

Figure 1. Viewing the MRM configuration item with MFCMAPI

The MFA uses a number of MAPI properties for mailbox folders and items during its processing. These properties are:

  • PR_START_DATE_ETC. For a folder, this property holds the GUID of the retention tag that governs a folder. Every tag is assigned a GUID (stored logically in the GUID property and visible with EMS). This GUID is stamped into this property so the MFA knows which retention tag, action, and period applies to the folder. For an item, the property holds a composite value containing the default retention period plus the start time for the retention period. By adding the retention period to the start time, the MFA determines the expiry date.

  • PR_RETENTION_PERIOD. This is the number of days items should be retained in a folder. When a personal tag is applied to an item, this property is set. However, if the property does not exist, the item (or subfolder) inherits the retention period from its parent folder.

  • PR_RETENTION_DATE. This is the calculated date when an item’s retention period expires. Clients display this information to users. When clients work in online mode (such as in Outlook Web App), Exchange takes care of calculating this value, otherwise clients that work in offline mode perform the calculation. otherwise.

  • PR_RETENTION_FLAGS. For a folder, this flag indicates whether the retention tag is inherited from the parent folder. If the user sets an explicit tag on a folder, the value is nonzero.

  • PR_POLICY_TAG. This exists only for items and contains a binary encoded value pointing to the policy tag that governs the item.

  • PR_ARCHIVE_TAG. This exists only for items and points to the archive tag that governs an item.

  • PR_ARCHIVE_PERIOD. This exists only when an item has been stamped with an explicit archive tag to contain the number of days in the archive retention period.

  • PR_ARCHIVE_DATE. This contains the date when an item will be archived.

You can view these properties through MFCMAPI. Figure 2 shows the value of the PR_RETENTION_DATE property for an item.

Another screen shot that shows how the MFCMAPI utility reveals details of retention item processing. In this case, the illustration is of the PR_RETENTION_DATE property for an item. The MFA has stamped a date of November 30, 2017, in the property, so the item should be retained until that date.

Figure 2. Viewing the PR_RETENTION_DATE property for an item

- Sharepoint 2013 : Security and Policy - SharePoint Security Groups (part 4) - Assigning New Visitor, Member, and Owner Groups at Site Creation
- Sharepoint 2013 : Security and Policy - SharePoint Security Groups (part 3) - Creating a New Group, Deleting a Group
- Sharepoint 2013 : Security and Policy - SharePoint Security Groups (part 2) - Removing Users from a Group, Group Settings and Permissions
- Sharepoint 2013 : Security and Policy - SharePoint Security Groups - Adding Users to a Group
- Microsoft Exchange Server 2013 : Messaging records management (part 7) - Setting a retention policy on a folder
- Microsoft Exchange Server 2013 : Messaging records management (part 6) - Customizing retention policies for specific mailboxes, User interaction with retention policies
- Microsoft Exchange Server 2013 : Messaging records management (part 5) - Applying a retention policy to mailboxes
- Microsoft Exchange Server 2013 : Messaging records management (part 4) - Creating a retention policy
- Microsoft Exchange Server 2013 : Messaging records management (part 3) - Naming retention tags, Creating retention tags
- Microsoft Exchange Server 2013 : Messaging records management (part 2) - System tags, Designing a retention policy, Managed Folder Assistant and retention policies
Top 10
Technology FAQ
- Microsoft ebs security server configuration
- IIs7 on Windows server 2003
- How to Configure Failover Clusters With Win 2008 Server R2?
- Windows 2008 Network Load Balancing
- Windows Server 2008 - Group Policy Management - Remove Computer Management
- Remove shortcuts possibility in a web page or to put in favorite
- HTA Dynamic Drop Down List
- IIS host header and DNS
- VMware or MS Virtual Server?
- Adobe Acrobat 9 inserting tab pages
programming4us programming4us