Automatic clean-out of Calendar and Task items now possible (but carefully)

The Microsoft Exchange Customer Experience Team (CXP, don’t you know) reinforced the importance for administrators to carefully review and assess the contents of a roll-up update (RU) when they released RU4 for Exchange 2010 SP2 on August 14. Exchange 2007 RU8 was released on the same day. Apart from a fix for the WebReady security issue (also fixed in Exchange 2010 SP2 RU4), this RU contains less of note, possibly reflecting the relative lack of importance for Exchange 2007 given the imminent arrival of Exchange 2013 and the stage that Exchange 2007 has reached in Microsoft’s product lifecycle.

Exchange 2010 SP2 RU3 also contained some big changes, notably those that deal with cross-site failovers. Now RU4 comes along and changes the rules for how retention policies for calendar and task items are processed by the Mailbox Folder Assistant (MFA). An analysis of the fixes contained in RU4 is posted here.

The new processing behaviour is explained in a comprehensive post by Ross Smith IV so I won’t dive into the detail here. Suffice to say that the change closes a gap in Microsoft’s record retention strategy built around Exchange. Any Exchange 2010 server prior to the installation of RU4 ignore calendar and task items, even if you define a Default Policy Tag (DPT) that dictates that all items in a mailbox should be deleted or moved into an archive mailbox after a certain period. In the past, I’ve heard Microsoft representatives justify this on the basis that it would be a very bad idea if Exchange automatically cleaned up calendars and task lists because some users like to keep calendars (in particular) for extended periods so as to be able to track what they did at some point in the past. I can understand this point and agree with it as I’ve had reason myself to refer back to an old date in my calendar to recall exactly where I was and who I was meeting on a certain occasion.

RU4 allows more flexibility. Instead of ignoring calendar and task items, you can create retention tags that apply to these folders and assign the tags appropriate retention periods and actions. For example, I think it would be very sensible to assign a retention period of two or three years and then have MFA archive calendar items (that is, if you use Exchange archive mailboxes). Remember that if you plan to use archive mailboxes, be sure to consider the effect of enabling archives from a retention perspective before you start.

Unless your users habitually use Tasks to track multi-year events, these items it’s probably OK to use a shorter retention period, say one year, before the items are deleted or moved to the archive. As in all cases when you play with retention policies, it’s a good idea to secure agreement from your HR and Legal departments and to communicate any changes that you make in a very clear and precise manner to all users affected by the new retention policies.

Because RU4 has the potential to affect user data, albeit in an expected manner, it’s important that its deployment is managed slightly differently than other updates. One approach is to create the necessary PowerShell commands to update your retention policies with new retention tags for the Calendar and Tasks folders and have them ready to be applied immediately RU4 is installed onto your servers. This is easily done on a test server running RU4 and a matter of cut and paste into an EMS session running on a server that supports RU4 after the installation is complete. I think that this approach will work well in small deployments where you can inform users well in advance to prepare them for the changeover.

Larger deployments, especially those that are multi-national, always offer more challenges whenever changes occur that have the potential to affect users. To accommodate these situations, Microsoft offers two alternatives. You can either update the system registry on your mailbox servers with a new key to instruct MFA not to process calendar and task items or you can place all mailboxes on retention hold until you are ready to allow MFA to process the items. Even though it uses a registry key to control processing, I prefer the first option as the second might cause mailbox databases to swell to unpredictable sizes to accommodate all the mailboxes on retention hold. Of course, if the period when the mailboxes will be on retention hold is restricted to a week or so and you have plenty of free disk space on all your mailbox servers, then this approach would work well too. The details of the two approaches are explained in the EHLO post.

In passing, I note that Microsoft explains that you’ll have to create new retention policy tags for the Calendar and Tasks folder using EMS as the EMC and ECP user interfaces haven’t been updated by RU4. I was able to create new tags for these folders using ECP for my Office 365 domain. The question now is whether the version of MFA running in Exchange Online will process the new tags!

Follow Tony @12Knocksinna