Calendar and Tasks Retention Tag Support in Exchange 2010 SP2 RU4

[Ross Smith IV]

In order to ensure compliance policy requirements are met within the messaging environment, messaging data must be classified and maintained for periods of time based on the classification level.

In Exchange 2003, the Mailbox Manager provided a means to delete messaging data, including calendar and task objects. Mailbox Manager was limited in its ability, however:

• The Mailbox Manager would ignore and not delete any appointments if they were tagged as recurring, regardless of end date, start date, sent date, or last modification date.
• The Mailbox Manager would ignore and not delete any tasks that were not marked as completed.

In Exchange 2007, Mailbox Manager was replaced with Messaging Records Management (MRM). Managed Folders, the MRM feature in Exchange 2007, enabled customers to apply retention settings to default folders, such as Inbox and Deleted Items, and also deploy custom managed folders. Users would sort their messages by placing them into different managed folders, with each folder having a different retention setting. With respect to the calendar and tasks folders:

• Non-recurring calendar items expire according to their end date. Recurring calendar items expire according to the end date of their last occurrence. Recurring calendar items with no end date do not expire.
• Non-recurring tasks:
• A non-recurring task expires according to its message-received date, if one exists.
• If a non-recurring task does not have a message-received date, it expires according to its message-creation date.
• If a non-recurring task has neither a message-received date nor a message-creation date, it does not expire.
• Recurring tasks expires according to the end date of the last occurrence. If a recurring task does not have an end date, it does not expire. A regenerating task (which is a recurring task that regenerates a specified time after the preceding instance of the task is completed) does not expire.

Messaging Records Management in Exchange 2010

Exchange 2010 introduced Messaging Records Management 2.0 and the Retention Policy framework. The framework consists of retention tags and retention policies. Retention tags are used to apply retention settings to messages and folders. A retention policy is a group of retention tags that can be applied to the mailbox. The use of the word “retention” in this MRM 2.0 naming convention is misleading. In addition to controlling when items are expired out of the mailbox, retention tags can also be used to control when items move to the archive .

With Exchange 2010 RTM, SP1 and SP2 through SP2 RU3, MRM 2.0 does not provide support for assigning retention tags either directly to calendar and task items or to the calendar and tasks folders. Many of you, our customers, have spoken to us about the need for this functionality and see this as a takeaway when compared to previous versions of Exchange.

In the end, compliance requirements need to be met. Excluding calendar and task items from the retention policy framework means that customers that have business and/or legal compliance policies for managing data are unable to guarantee the requirements are met.

Calendar and Tasks Support in Exchange 2010 SP2 RU4 and later

In Exchange 2010 SP2 RU4, we’ve added support for Calendar and Tasks folders to Retention Policies.

If you currently use or plan to use Retention Policies, this has important implications for your messaging environment.

1. Beginning with Exchange 2010 SP2 RU4, administrators can create retention tags via the cmdline for use with the Calendar and Tasks default folders. The supported retention actions are: DeleteAndAllowRecovery, PermanentlyDelete, MarkAsPastRetentionLimit.  Note that calendar and task items can be moved to the archive mailbox via the MoveToArchive retention action that is associated with the All or Personal retention tag type.
2. Default Policy Tags (DPTs) used to move or delete items will now apply to Calendar and Tasks folders.

How Calendar and Tasks items are expired

Calendar and task items are different than normal message items. When a calendar or task item is saved, the item is stamped with its specific properties. To ensure that a collision (or conflict) doesn't occur between the Mailbox Folder Assistant (MFA) and the assignment of the default properties during an auto-save event, the MFA will not process calendar and task items immediately. Instead, the assistant will delay processing of calendar and task items for 2 hours (based on last modification time of the item; if there is no last modification time, then it is based on the creation time).

Unlike message items, end users cannot assign different retention tags to either the Calendar or Tasks folders or calendar and task items. In other words, Calendar and Tasks retention tags are only controlled via the administrator.

The following logic is used to determine the start date for expiration or move to the archive for calendar items in the Calendar folder:

1. Non-recurring calendar items expire (or move to the archive) based on the end date of the item.
2. Recurring calendar items expire (or move to the archive) based on the end date of their last occurrence. Recurring calendar items without an end date neither expire nor move to the archive.
3. If an item is found within the Calendar folder that doesn't have a proper item type, it's ignored (as the item is might be corrupt).

The following logic is used to determine the start date for expiration or move to the archive for task items within the Tasks folder:

1. Non-recurring tasks:
1. A non-recurring task expires (or moves to the archive) according to its message-received date, if one exists.
2. If a non-recurring task does not have a message-received date, it expires (or moves to the archive) according to its message-creation date.
3. If a non-recurring task has neither a message-received date nor a message-creation date, it neither expires nor gets moved to the archive.
2. Recurring tasks expire (or move to the archive) according to the end date of last occurrence. If a recurring task doesn't have an end date, it does not expire (and isn't moved to the archive).
3. A regenerating task (which is a recurring task that regenerates a specified time after the preceding instance of the task is completed) doesn't expire (or get moved to the archive).
4. If an item is found within the Tasks folder that doesn't have a proper item type, it's ignored (as the item might be corrupt).

Before You Deploy Exchange 2010 SP2 RU4

Support for Calendar and Tasks in Exchange 2010 SP2 RU4 means you’ll need to treat this update rollup differently. If you don’t use Retention Policies or if you don’t mind Calendar and Tasks items being moved to archive or deleted automatically based on the DPT settings, you can skip the rest of this post.

However, if you are concerned about the effects of this new functionality will have on your calendar and task items, you can implement the following temporary workarounds:

If you don’t want Calendar and Tasks items to ever expire, you can disable the functionality that is included in Exchange 2010 SP2 RU4. Add the following registry key to your Mailbox servers:

• Path: HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeMailboxAssistants\Parameters
• Name: ELCAssistantCalendarTaskRetentionEnabled
• Type: DWORD
• Value: 0 = Do not process Calendar and Task folders
• Value: 1 = Process (default with RU4)

If you want Calendar and Tasks folders to expire at a different interval than DPTs, you can follow the following steps:

1. Place all mailboxes on Retention Hold
2. Apply Exchange 2010 SP2 RU4 to your Mailbox servers.
3. Create RPTs for Calendar and Tasks folders with the desired retention settings.
4. Inform users about the change.
5. When ready, remove the retention hold from mailboxes.

Conclusion

We are glad that we were able to bring this long sought after feature to the product. If you have any questions, please let us know.

Ross Smith IV
Principal Program Manager
Exchange Customer Experience