Email Records Management, Part 1

Hi everyone! Now that Vista, Exchange, and the Office System are available to businesses, we thought we’d switch gears on this blog. So far, the blog has focused on the records management capabilities in Microsoft Office SharePoint Server 2007. However, around the office, we always talk about compliance and records management as spanning the entire information lifecycle and not just one particular product or service. When we were researching customer needs for the 2007 release, one of the themes we constantly heard was that there is a need to manage all types of content – no matter where it lives – and a need to integrate various products together for a complete end-to-end experience.

 

E-mail is a key type of content in organizations. Therefore, the next couple posts will focus on managing the information contained in corporate e-mail. We’ll introduce some of the compliance and records management features in Microsoft Exchange 2007 and Microsoft Outlook 2007. Of course, we’ll be sure to mention the tight integration with MOSS 2007 as well.

 

At first glance, e-mail is a pretty strange place to talk about records management. When most people think of managing corporate records, they think of archiving signed contracts, financial statements, and the like. They don’t think of trying to manage ad hoc communications like e-mail.

 

Increasingly, though, e-mail is where a lot of an organization’s important information lives. A recent AIIM survey showed that over 70% of information workers spend a fifth of their time or more on e-mail related tasks. Certainly here at Microsoft we live in an e-mail centric world. On average, over 3 million e-mail messages are sent internally within Microsoft every day!

 

For many organizations, what used to be communicated in written memos or other easily archivable formats is now being sent as e-mail. Since e-mail is where business is being conducted, important information that needs to be retained is stored there as well.

 

What’s more, the need to manage e-mail has been emphasized in recent headlines. For instance, this year marked a landmark case in electronic records retention: Perelman vs. Morgan Stanley. In this case, Morgan Stanley was heavily punished by the judge for consistently failing to produce e-mail records during the discovery process. On several occasions, employees at Morgan Stanley found tape backups of e-mail records related to the case even after the company signed statements stating that they had turned over all relevant records. Morgan Stanley had no consistent process in place for managing the flow of information in e-mail, and this could end up costing the firm hundreds of millions of dollars.

 

Flashy court cases aren’t the only wake up call, though. The oft-mentioned changes to Rule 26 of the Federal Rules of Civil Procedure finally codify the requirement to manage electronic information. Specifically, these new rules focus on the eDiscovery process and they make it clear that companies must have a policy for managing all types of electronic information, regardless of where it is stored. If you want to learn more, our partner Iron Mountain has an excellent whitepaper on the new rules.

 

And yet, in a recent ARMA survey, 43% of respondents have no plan for managing e-mail records. So we have a situation where a lot of information is being generated, there is a new and urgent need to manage that information flow, and most companies don’t have a plan yet.

 

It was with this customer problem in mind that we developed a solution to the e-mail management problem. As we describe the solution in the next few blog posts, we’ll be talking about things like:

· How end users can classify e-mail messages according to a corporate schema

· How e-mail can be retained and then ultimately deleted based on its classification

· How storage quotas can be enforced on individual folders (e.g. this folder is limited to 200MB)

· How important e-mail can be sent to a SharePoint Records Center – directly from the Outlook client

· How Exchange and Outlook search can be used to search for e-mail during the eDiscovery process

To a certain degree, managing e-mail is very different from managing other corporate records. The sheer volume of information requires broad strokes and less attention to each individual item. Process and rules becomes very important.

 

However, even though there are some differences, records are records because of their content, not their format. So we’ve made sure that the e-mail management features we’ll describe in the next few posts align with the “big picture” we outlined in the early posts on this blog. Themes like “low tax on the end user” and “low deployment costs” will run through our e-mail experience as well.

 

Thanks for reading and stay tuned!

Adam Harmetz

Program Manager

Comments

  • Anonymous
    December 22, 2006
    You say above, "E-mail is a key type of content in organizations." No, e-mail is a delivery mechanism, similar to an envelope. We should not perpetuate the idea that e-mail is a type of content, since it tends to promote the idea that all e-mail is alike and can be treated as such.

  • Anonymous
    December 26, 2006
    Alan, I must politely disagree; wouldn't your envelope analogy be more accurate if you wrote out the entire letter on the envelope and then mailed it? The argument over whether eMail is content or not is really a moot point though. Businesses can now be held liable for the information inside an electronic message; to business owners this is a new and intimidating liability and it needs to be addressed. Arguing that eMail is or isn't 'technically' content doesn't make the business problem go away...

  • Anonymous
    December 26, 2006
    I have to agree with kbennett2000. E-mail is different for a couple reasons. E-mail is not just an envelope. A record is comprised of the the content and context. The context in the case of E-mail is the date sent/received, subject, and the addressees. This information becomes an important piece of an official record. This is one of the reasons the DoD 5015.2 standard has very specific guidance on the handling of E-mail records.

  • Anonymous
    December 28, 2006
    I hate to play semantics, but ... I do not contest that e-mail is a record. What I was trying to distinguish was the confusion when we use 'record' and 'content' synonymously. I think we all agree that a record has both content and context. E-mail is a record that has content, but is not a TYPE of content. The type of content is discerned by examining the message -- memo, meeting request, procedures announcement, etc. In my discussions about e-mail with clients over the past 10-15 years, their tendency has been to lump all e-mail together as a TYPE so that a single retention can be placed on it [Witness the 30-60-90 day retentions mandated by some IT departments]. I believe strongly that we must constantly distinguish among the concepts of 'record,' 'context,' and 'content.' so that users can clearly and correctly identify the retention for individual e-mails. We get the context from the 'envelope,' the metadata, but the metadata is not the content. By investigating both the 'content' and the 'context' together, we can determine what our obligations are toward a record.

  • Anonymous
    January 02, 2007
    I have always used the analogy that no one would say all Word documents or all Excel sheets should be kept for 60 or 90 days and that email is no different. Email is just another way to create content -- it is basically a word processor with a delivery mechanism attached (the "envelope"). Is it all that different from someone creating a document in Word and then faxing it directly from their computer? It's interesting that no one seemed to care much about metadata on non-email documents ... the paper envelope with the addressee name and the postmark is routinely thrown away and the electronic version had for a long time never been considered the "official" copy. When it was, it was converted to PDF or some other non-modifiable format (which in reality modified the metadata of the truly original document). I haven't heard any rumblings about requiring that any electronically created document be saved and maintained in its native format so that the metadata isn't lost. We are becoming more aware of the metadata in these other documents and are purposely saving them in such a way that the metadata is NOT maintained. This practice will likely accelerate with the recent ABA opinion 06-442. Why is obscuring the metadata in email spoliation, but doing the same thing in Word not?

  • Anonymous
    January 03, 2007
    The comment has been removed

  • Anonymous
    January 04, 2007
    This is a great discussion and just what we always envisioned for this blog.  It's been really interesting hearing everyone's take on email management. In general, I think you'll see in the next few posts that we address a lot of what everyone is talking about.  We do indeed offer type differentiation at the capture point (that is, we don't treat all email as the same type).  We encourage the type to be determined by the content of the message (and I use Alan’s definition of content) and not the medium/context. The only item I would add here is the there might be context-specific metadata that customers are interested in capturing (Subject, To, CC are examples of context-specific metadata for email).  We support the automatic capturing of such metadata, even across different content-types.  More on that in future posts! Thanks, Adam Harmetz Program Manager

  • Anonymous
    January 05, 2007
    Hi Adam This is very timely for us - we are a Microsoft Gold Partner and our clients are looking to us to help them identify solutions to their email archival problems.  We have staff looking at products like http://www.sherpasoftware.com/ and are keen to see how much of the jigsaw is in place in the Exchange 2007 + SharePoint 2007 combo at this time.  If we can get a clear picture of that and if Microsoft can produce some marketing materials (business and technical) to support this scenario (the paper on compliance was great but only briefly mentioned email) then we would be in a position to go to market with the MS Office-based solution, which is preferable to a third party offering. Marcus Ferbrache

  • Anonymous
    January 05, 2007
    In the previous post , we covered the basics of what’s involved in e-mail records management and why

  • Anonymous
    January 06, 2007
    I agree with most of the comments here: email isn't a type any more than e.g. Word, PDF, or legal lined notepad is. It's a format, or a transport mechanism, or something else, but its "recordness" depends primarily on the content, as for any other content, and secondarily on the context. That said, I'm not sure I understand the business reason for setting an arbitrary limit on the size of a managed folder, because what that leads to is the same thing it's led to in the traditional Exchange paradigm: users who run out of space sort by size and delete the largest items rather than the trivial. I'll continue to follow the series of posts - I hope this is something that will be addressed.

  • Anonymous
    February 08, 2007
    Greetings, everyone! In this post, we are going to conclude our discussion of e-mail records management

  • Anonymous
    June 10, 2007
    Hello folks, We can see many times in the Exchange Server 2007 documentation that we can keep information

  • Anonymous
    October 22, 2008
    The comment has been removed

  • Anonymous
    January 29, 2009
    For email management there is a bunch of tools that I personally use and can recommend to everybody. The first one is <a href="http://www.scriptlogic.com/products/archive-manager">Archive manager</a> - email archiving solution. This tool is a great diskspace saver - it keeps all emails in a centralized compressed repository storing only a single copy of all messages and attachments. As for working with exchnage backups there is a tool called <a href="http://www.recoverymanagerforexchange.com">recovery manager for exchange</a> that provides item-level recovery from all exchange backup data.