Blogs

I’m always struck by the difference between Records Management’s perception of IT processes and IT’s perception of Records Management processes. For example, I’m looking more closely at Messaging Records Management for Exchange Server 2007. As I read the usual sources and dissect the Microsoft (or similar) verbiage, “Messaging Records Management” is couched as “email content at rest”, which equates to emails sitting in a folder in the Exchange environment (as opposed to “emails in transit”). So, here’s how it works: the administrator creates folders, using the recognizable names (that hopefully map back to the records retention schedule); and connects a managed folder mailbox policy to the mailbox (that hopefully map back to the records retention schedule); assigns the managed folder mailbox policies to users; and configures the mailbox server to run the scheduled policies. Voila. Right?

Nope. So much is dependent on the user. Never a bad thing, but it means intensive training. End users move their pertinent emails into the appropriate default folders, because the administrator is going to set up rules to purge default folders every 60, 90, or 180 days. If end users don’t have their items in the right folder, and the items are deleted out of their inboxes, be prepared for recovery request phone calls. Some flexibility exists in the archiving versus sit-on-the-server protocol, but that’s determined internally (I shudder to think at the consequences if the Records team doesn’t participate in that decision). To complicate matters further, the administrator specifies the content type (i.e., calendar items, documents, faxes, tasks, etc.) in order to set the destruction period, which can be one of two options: When Delivered, End Date for Calendar or When Item is Moved to the Folder. Be warned: there is a Delete and Allow Recovery option that might be selected. Make sure you, the Records and Information Manager, are aware whether or not that option has been selected.

Meanwhile, custom folders are a whole other level of good times, because the Administrator sets the quota for storage at the folder level. Ok—I have a question. How do you know when the folder is within 95% of reaching its storage limit? Do I need a notification mechanism in place to help me monitor this? Is that written by a Powershell cmdlet? Out of the box I see four cmdlets: New-Managed Folder, Set-Managed Folder, Get-Managed Folder, and Remove-Managed Folder. Do I need to hire an outside consultant to write the storage cmdlet for me (Ok, I will hire an outside consultant only if they walk in with one of those shirts that say, “Will code for food”—I’d love to have one of those)? Never mind if your organization still supports Outlook 2003 and your end users only see some of the folders—that’s nothing to worry about, right? Oh, and about the legal side of things: the good news is you can schedule a period of time at the folder level that the policy doesn’t run—it’s optional.

Today’s lesson, if I may, boils down to one essential component: work with your IT contact to acquaint yourself with which tasks are performed by the Exchange Management Shell and/or Console. That’s where the above action takes place in Exchange Server 2007. Also, talk with them about how the seemingly simple implementation may beget serious symptoms to be addressed in Email Project Two: Return of the Killer Email Project. Sometimes the sequel is better…