Calendar and Tasks Retention Tag Support in Exchange 2010 SP2 RU4


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

Comments (17)
  1. Michael says:

    Ha! It's nice to see that this feature finally got through to the calendar and tasks as well. I assume that – instead of placing the mailboxes on hold – you could also disable the feature, create RPT's for Calendar/Tasks and re-enable it as well?

    Perhaps a long stretch: are there any plans to allow users to set personal tags on calendar/task items in the future?

  2. Karsten says:

    I tried the following: I crated a user with a Mailbox and checked if it has a retention policy – which was not the case. When I gave that user an archiv. After this, the User has had the "default retention policy".

    So the sentece "If you don’t use Retention Policies …" is a little dangerous because one might not know that he uses Retention policies.

  3. Bharat Suneja [MSFT] says:

    @Karsten: This is covered in
    Understanding Personal Archives
    >
    Archive and Retention Policies
    in Exchange 2010 documentation:

    Exchange Setup creates the default archive and retention policy Default Archive and Retention Policy. This policy contains retention tags that have the Move to Archive action, as shown in the following table…

    If you enable a personal archive for a mailbox user and the mailbox doesn’t already have a retention policy assigned, the default archive and retention policy is automatically assigned.

  4. Andrei Kondrashov says:

    @Michael It's a new e2013 feature. I mean assigning personal tags to standard folders and mailbox.

  5. Ross Smith IV says:

    @Michael – at this time, there are no plans to enable support for personal tags against calendar and task items.

    Ross

  6. Aaron A says:

    Thanks alot, been waiting for this feature to be included.

  7. Charles Derber says:

    I never knew how MFA working so closely until I read the topic @Exchange Server 2010 Inside Out by Tony Redmond.

    This articles explores the feature further :)

  8. Paul N says:

    This is great to see!  I've been waiting for this since configuring a 2010 SP1 environment at my last employer.  

    Question: what constitutes the "end date of last occurrence" for Task and Calendar items?  With Calendar, when viewing "All Appointments" there is an "End" column which makes me think that this may be the qualifier for Calendar items, but what about Tasks?  If I choose to add "End" as a column to the view it shows as "None".  Is it the "Due Date"?  

    I just want to have a better idea of how the date is calculated and where I can find the date on the object before putting it in place and for troubleshooting.  

    Thanks!

  9. Brendan Hamilton says:

    Do all mailbox servers in the organization need to be RU4 before these retention policies can be created?

  10. timo.kinnunen@savonia.fi says:

    Thanks for this feature.

    Now I can create RPT for Calendar/Tasks but only if retention action is not MovetoArchive. What is incorrect with this: New-RetentionPolicyTag "Calendar-RPT" -type Calendar -RetentionEnabled $true -AgeLimitForRetention 1825 -RetentionAction MovetoArchive ?

  11. Steve says:

    Could this by any chance cause slow loading of Calendars after the roll up?  

  12. christian.zeidler@viritim.de says:

    Hello,

    what can be done in the following scenario.

    As-is situation:

    – Having RU4 already installed

    – Using already a retention policy for archiving, not one of the default policies, using a manually created policy

    Result:

    – Calender and task items are archived

    Goal:

    – Calender and task items should not be archived

    Workaround – not functional in my scenario:

    – Adding the registry key with value = 0 on all mailbox server, but the calender and task items are archived anyway

    Is that a wrong workaround for this situation?

    Is a restart of a service or a server necassary for making the registry key working?

    Thank you.

    Best regards,

    Christian

  13. Thomas says:

    It's a very good hint, because it seems to be impact to our Blackberry Server.

    It is necessary to reboot the Mailbox Server after adding the registry key?

  14. David says:

    This should have been in the Release notes, don't you think?

  15. christian.zeidler@viritim.de says:

    @Thomas, what do you mean?

    "It is necessary to reboot the Mailbox Server after adding the registry key?"

    Do you mean to restart the Mailbox Servers?

    or

    Is this a question, because of the "?" on the end of the sentence?

    Best regards,

    Christian

  16. Jason says:

    We use retention policies and I am trying to get details on how RU4 will affect our environment, this line concerns me as its not detailed enough for the exact days.

    “or deleted automatically based on the DPT settings” what are the DPT settings for Calendar and Task items?  I understand when it marks them, however what is the default day(s) for deletion, 120, 180?

  17. Anonymous says:

    Let’s take the following example:

    We have an Exchange 2010 User who is traveling a lot (Sales

Comments are closed.