UPDATE: Please read updated guidance due to changes introduced in SP2 RU4 here: http://blogs.technet.com/b/exchange/archive/2012/08/14/calendar-and-tasks-retention-tag-support-in-exchange-2010-sp2-ru4.aspx. It specifically addresses Calendar items and tasks.
I wouldn’t be talking about it today!
When the topic came up with my colleague, it quickly became a confusing discussion of what’s what, what works, what doesn’t and why TechNet seems to say something that doesn’t work.
So let’s start with this article: “How Retention Age is Calculated”. This clearly states how age is calculated on Calendar items, Tasks, Contacts and other items. Then it immediately mentions in the Note that retention tags aren’t supported for the Calendar and Tasks. The Managed Folder Assistant doesn’t process items in these folders.
This is really what is a start of confusion. The article “Understanding Retention Tags and Retention Policies” doesn’t mention the same fact (probably to avoid duplication).
The confusion is evident when Bharat specifically spells out in EHLO article “Prevent archiving of items in a default folder in Exchange 2010” that Calendar, Tasks and Contacts folders aren't supported.
However, above all, the confusion prevails! So let’s clear things up a little bit.
Exchange 2007 feature Managed Folder Policies, aka MRM 1.0 functionality supports Calendars, Tasks etc. However, it has its limitations. MRM 2.0 functionality provides more flexibility so individual folders can have different retention either applied to mailboxes using policy or by user using tags on folders or messages individually. Not to mention, at the cost of being able to process Calendar and Tasks along with Notes and Contacts. In SP1, Notes are processed, however, don’t expect more than that!
So if you want to process Calendar items, Tasks or Contacts, you should use Managed Folders. It does mean you won’t be able to apply one policy to one folder (i.e. Inbox) and different policy to another (i.e. Calendar). It also means that you can’t archive enable the mailbox that has Managed Folders policy applied or you can’t apply Managed Folders Policy to mailbox that has archive mailbox. If that is clear, I assume you know by now that Managed Folder Policy can’t move anything to archive mailbox. Although, never assume, so previous statement should remove my assumption and clearly tell you what it is!
Conversely, if you apply Default Policy Tags or Retention Policy Tags to a mailbox, Managed Folder Assistant will not process unsupported items. Namely, Calendar, Tasks, Contacts and Notes in Exchange 2010 RTM and Calendar, Tasks and Contacts in Exchange 2010 SP1.
Also worth noting is that you can either apply Managed Folders Policy or Retention Policy Tags (DPT/RPT whatever you call it) but not both to a mailbox. You can apply Managed Folders Policy to one mailbox and Retention Policy Tags to another in same Exchange 2010 database as these settings are per mailbox.
Oh and that “How Retention Age is Calculated” post isn’t incorrect. It correctly states how the age is calculated. Just understand it only applies to Managed Folder Policy.
Clear a mud? Perfect!
Is there any movement in adding Calendar items into the Retention Policy?
Hello, thanks for this post, it cleared a number of things up for in regards to calendar archiving. So if we can't use a retention policy or managed folders to an online archive in Exchange 2010, how to organizations handle the archiving of calendar items?
@Grill Girl and @Michael, SP2 RU4 addresses both of your concerns. Ross Smith has documented it well on Exchange Team Blog: blogs.technet.com/.../calendar-and-tasks-retention-tag-support-in-exchange-2010-sp2-ru4.aspx. Hope it helps.
We have retention policies enabled for the deleted items folder, it deletes anything older than 10 days. We recently noticed that if someone deletes a contact, it will sit in the deleted items folder until it is manually removed. The reason being that contact items are not designed to have retention tags assigned to them.... Not the end of the world, but pretty annoying.