As the Exchange Retention and Archiving Policies is a topic many people run from, I think it is always better to get more info on the topic for easier troubleshooting.
For more information and description of the Retention Tags and Policies, please refer to TechNet “Understanding Retention Tags and Retention Policies” article.
I will summarize some key points, which I consider important in understanding the behavior of the Retention Policies and Tags.
There are three types of retention tags:
Default Policy Tag (DPT) – applies to all items that do not have a retention tag applies, either inherited of explicit;
Retention Policy Tags (RPT) – are created for the default folders, such as Inbox, Deleted Items, Sent Items etc.;
Personal Tags – are used by Outlook and Outlook Web App (OWA) users to apply retention settings to customer folders and individual items, such as e-mail messages
A Retention Policy is a group of retention tags that can be applied to a mailbox.
A retention policy can have one DPT to move items to the archive, one DPT to delete items, one DPT to delete voice mail messages, one RPT for each supported default folder, and any number of personal items.
Users cannot change a RPT applied to a default folder, but then can apply a different tag to the items in a default folder.
We cannot include more than one RPT for the same default folder type in one retention policy. For example, if a retention policy has an Inbox tag, another RPT of type Inbox cannot be added to that retention policy. RPTs cannot be applied to the Contacts folder.
Personal Tags are a premium feature. Mailboxes with policies that contain these tags (or as a result of users adding the tags to their mailbox) require an Exchange Enterprise client access license (CAL).
Although you can add any number of personal tags to a retention policy, having many personal tags with different retention settings can confuse users. The recommendation is to link no more than 10 personal tags to a retention policy.
If a RPT is removed from a retention policy, any existing mailbox items with the tag applied will continue to expire based on the tag's settings.
To prevent the tag's settings from being applied to any items, you should delete the tag. Deleting a tag removes it from any retention policies in which it's included.
Retention polices are applied to mailbox users. Different sets of users can have different retention policies.
The Exchange version is important, as starting with SP2 RU4, there were some changes regarding retention/archiving policies, as support for Calendar and Tasks was added, please verify this TechNet blog.
Starting with Exchange 2010 SP2 RU6, anew option was added.
As there were some issues reported with the default behavior or applying the Retention Policies, most of the case due to the misunderstanding of the Messaging Records Management (MRM), we decided to test, reproduce and do some tests in the lab environment.
For a test user, the Default Archive and Retention Policy (DARP) was applied and was ran in the Exchange Management Shell -> all the folder in the mailbox have the inherited tags for the default folders and cannot be changed from the client.
We can verify if a Retention Policy was applied using the MFCMapi tool: after logging to the user’s mailbox, right click one folder (in our case the Inbox folder) -> Open associated contents table -> Message class: IPM_Configuration_MRM -> PR_ROAMING_XMLSTREAM, and look for the associated policy applied.
We can see in the above screenshot the two RPTs applied for the folder: “4 Days Delete Sent Items” and “3 Days Delete Inbox”, and the details for each policy tag.
This is the safest way to verify if a specific RPT was applied after running the Managed Folder Assistant.
If the user creates a new folder (ex. under the Inbox folder), the folder policy tags are inherited from the parent folder and the user is able to change it.
For individual items in the folder, we can manually set other RPTs, or use the folder policy.
The DARP has 2 DPTs (“Default 2 year move to archive” and “Recoverable Items 14 days move to archive”) and other personal tags that can be applied to items from Outlook/OWA.
The test user had two e-mails in the Inbox folder, received on 09/19/2013. For one of the e-mails, the personal tag “1 Month Delete” was applied -> the item was to expire on 10/19/2013 and will be moved to the Dumpster, as the “Delete and Allow Recovery” action was selected. User will have the possibility to recover the item from the Dumpster.
We can set the “Permanently delete” action, so that the user will not be able to recover it anymore. The item will still be available for the Exchange administrator when doing an in-place search.
Awas created, RPTs
, type, action Delete and allow recovery;
, type, action Delete and allow recovery
The policy above was assigned to the test user that had the DARP and was ran ->">, except the e-mail which had the “1 Month Delete” personal tag applied. Retention Policy: 1 Month Delete (30 days). Expires: 10/19/2013".
Please note that the “Retention Policy” term that appear in Outlook and OWA, is the RPT that we set in Exchange.
Having the above policy applied, with only the 2 RPT, for Inbox and Sent Items folders, the user will not have the possibility to assign another RPT or personal tag, as it is not available for this policy.
DARP -> the item in the Inbox with the personal tag applied was the same, while the other items did not have the 3 days deletion tag, but the default settings from the DARP.
To conclude, when changing the Retention Policies, the tags that apply to the items in user’s mailbox can be different, depending on the personal tags from the DARP applied by the users to individual items or custom folders, or depending on the actions set by the custom delete policy.
In some cases, the behavior of the retention and archival polices might look a bit strange, that is way we need to closely check the behavior and the applied tags.
For more in depth information on the Retention Policy Tags and MRM development, please verify the “Search and Replace Retention tag on Microsoft Exchange 2010 (MRM)” blog entry.
I hope you will find the above information useful,