Don't Drop The Attachment! Using Microsoft Exchange 2007 to produce in a "Native" Format

chris.chalmers — Mon, 11 Aug 2008 04:21:00 GMT

Nothing sharpens your focus like a $206,000 question!

In the case of PSEG Power of New York v. Alberici Constructors, Inc. the court wrestled with the e-discovery issue of whether or not PSEG had to produce 3,000 emails and their corresponding attachments together.

It seems that PSEG's original production contained emails separated from their attachments, or the links to the attachments were broken. PSEG argued that re-attaching the attachments would cost $206,000; Alberici Constructors said it was more like $37,500.

The Court called the email attachment issue a "fiasco" and ordered PSEG to produce the emails with attachments at its own expense. We never do get to find out how much it cost to comply with the order, but it's an entertaining read nonetheless: this one issue took six months to resolve. Electronic Discovery Blog posts the whole thing here: http://www.electronicdiscoveryblog.com/cases/pseg.pdf

As usual, I have no idea which email system was actually in use, so let's explore the hypothetical case of Contoso Corporation running Microsoft Exchange 2007. Contoso has been instructed to produce emails with attachments in "native" format.

The "native" format for Exchange is actually somewhat debatable. In PSEG Power of New York v. Alberici Constructors, Inc., the Court cited FRCP Rule 34(b), which mentions two alternative forms of production in the event the parties do not reach agreement on the file format during their meet-and-confer: the form “in which it is ordinarily maintained” or “in a form or forms that are reasonably usable.”

Another interesting read, and one that specifically mentions Exchange file formats, is Craig Ball's post on "Quasi-Native format." In the article, he wrestles with various email and database formats like .eml, .edb, .pst, and their pros and cons. You can find it here: http://www.law.com/jsp/legaltechnology/pubArticleLT.jsp?id=1190797380668

If you're super-motivated, the Sedona Principles Addressing Electronic Document Production, Second Edition (June 2007), explore the issues around Rule 34(b), "native form," "reasonably usable," and forms of production in depth. The full document is available here: http://www.thesedonaconference.org/dltForm?did=TSC_PRINCP_2nd_ed_607.pdf

Let's assume that Contoso's legal team has decided to produce the emails and attachments in a separate .PST file that contains only the responsive messages. All of the email metadata (such as headers, message ID, conversation ID)will be intact, the attachments will be attached and in native format (like Word, Excel), and the .pst file won't contain other messages.

How can Exchange 2007 export do that?

Once again, the best Exchange commands are PowerShell one-liners. This time, we're going to use the Export-Mailbox cmdlet. Export-Mailbox has a parameter called "-AttachmentFilenames" that lets you extract email messages with certain attachment types, as well as a "-PSTFolderPath" parameter that lets you specify a PST file as the export target.

You can see the documentation on Export-Mailbox here:

http://technet.microsoft.com/en-us/library/aa998579(EXCHG.80).aspx

Here is how we would copy all the messages out of John's mailbox that contained the keyword "merger" and attachments with filenames matching "orgchart"

Export-Mailbox -Identity contoso\john -TargetMailbox ExportMailbox -TargetFolder MyData -ContentKeywords "merger" -AttachmentFilenames "*orgchart*"

The Microsoft Exchange team blog explores the Export-Mailbox cmdlet in further detail, with plenty of additional examples, including how to export from multiple users' mailboxes at the same time, how to specify a .PST target, and some other interesting uses of the cmdlet. You can see it here: http://msexchangeteam.com/archive/2006/11/28/431669.aspx .

First, Let's Kill All The .PSTs

chris.chalmers — Fri, 01 Aug 2008 04:49:00 GMT

Let's face it, from an e-discovery perspective, having email stored in local .PST files on individual users' hard drives is risky. You don't want them around, because:

The end user's hard drive might fail, resulting in the loss of potentially valuable email that often isn't backed up (or the backup is stale).
The process of capturing and discovering information that is stored in .pst files is labor-intensive and expensive because .pst files must first be located on user computers and then the contents must be processed by legal personnel.
Potentially significant messages might be missed during the initial e-discovery gathering process, only to turn up much later in the litigation, causing harm to your case.

Exchange 2007 SP1 can help. Generally, we suggest a two-step approach to managing stray .PST files on the network:

Start by making the .PST files read-only, so users can still access their data, but not make the problem any larger. There is a registry key called "PSTDisableGrow" that can accomplish this

Once users have reduced their dependence on PST files, you can disable local PST files, and load the existing PST files into Exchange Server 2007 SP1. The "DisablePST" registry key accomplishes this.

Of course, all this is happening within the larger context of using Managed Folders and Message Records Management (MRM) to gain control of your email and implement your retention policy.

Here's a great clip from our documentation that explains the whole process, from how to make .PSTs read-only, to providing a nice n overview of deploying MRM:

http://technet.microsoft.com/en-us/library/bb508901.aspx

And here's a great blog posting on how to load PST files into Exchange Server 2007 SP1 using the Import-Mailbox cmdlet

http://msexchangeteam.com/archive/2007/04/13/437745.aspx

E-Discovery and Microsoft Technology : PST files

Don't Drop The Attachment! Using Microsoft Exchange 2007 to produce in a "Native" Format

First, Let's Kill All The .PSTs