It’s always good to have your material checked by someone who is detail-focused. Over the weekend, Paul Robichaux, Brian Desmond, and I have been updating our presentations and other material for the Exchange 2010 Maestro Seminars. In particular, Brian is very detail-oriented and does a great job of going through material to ask that annoying but essential question “Why?”.
He pointed out that a screen capture in my “Compliance” deck didn’t match what he saw on his test servers. This came as a surprise to me as I was pretty sure that I had taken captures from my SP1 servers – but he caused doubt in my mind and I went to check. Unsurprisingly, Brian was right and what I saw on my SP1 servers (now) was different to what I had inserted into the deck. The only explanation I could come up with was that Microsoft had made a late-breaking change in SP1 that I had missed.
So off I went to browse the text written about retention tags in TechNet for Exchange 2010 SP1. I found this text on http://technet.microsoft.com/en-us/library/dd297955.aspx:
In Exchange 2010 SP1, the Mark as Past Retention Limit, Move to the Deleted Items Folder, and the Move to a Managed Custom Folder actions have been removed from retention tags.
This was brand-new information to me! These actions were available for retention tags in RTM (not in EMC because the RTM version of Exchange 2010 doesn’t have any GUI to deal with retention policies and tags) and could be assigned to tags with the New-RetentionPolicyTag and Set-RetentionPolicyTag cmdlets. The net effect is that you can have retention policies built with RTM that aren’t supported in SP1. My deck showed a screen shot taken with a beta build of SP1 when the actions were still in situ. The mystery was solved, but I was a tad annoyed that this change had occurred under my personal radar, if only because it provoked a patch to chapter 15 for my Microsoft Exchange Server 2010 Inside Out book.
Looking into the matter deeper, it appears that:
- The Move to a Managed Custom Folder action is a bug. It doesn’t make sense to move items into a managed custom folder because these folders belong to the original version of Messaging Records Management (MRM 1.0) that has been replaced by retention policies and tags in Exchange 2010 (MRM 2.0). It also doesn’t make sense because a mailbox can be under the control of MRM 1.0 or MRM 2.0 but not both.
- The Mark as Past Retention Limit action is only useful if clients support the GUI to display this information to users. In fact, a client like Outlook 2010 only shows the item as “expired” and nothing much else happens as users can keep these items as long as they like.
- The Move to the Deleted Items Folder action is useful but wasn’t implemented! However, because of its obvious utility, I feel sure that this action will make a reappearance in a future release.
The change is applicable to EMC. EMS still allows you to create retention tags with the now unsupported retention actions. For example, you can run this command:
New-RetentionPolicyTag "Test" -RetentionAction "MarkAsPastRetentionLimit" -RetentionPeriod 120 -RetentionEnabled $True -Type Personal
Set-RetentionPolicyTag -Identity "Test" -RetentionAction "MoveToDeletedItems"
Exchange is quite happy to accept both of these commands with the actions that are specified.
The good news is that the Managed Folder Assistant (MFA) seems to be sensible enough to keep on processing retention policies that include retention policies with the now-departed actions. I imagine that the actions are simply ignored. This means that you should review any policies created with Exchange 2010. The DeleteAndAllowRecovery action is the best option for tags that specify “Move to the Deleted Items Folder”, the difference being that MFA will move items direct into the Recoverable Items (Dumpster) folder rather than going through Deleted Items.
All software has late-breaking changes that occur during the drive to shipment. This is just one of those in SP1. I imagine that there are more… The Exchange 2010 architecture poster released today doesn’t shed too much light onto the topic, so I shall simply wait and see what time reveals.