E-Discovery and Microsoft Technology : Exchange 2007

Tag-inator 3: Rise of the Machines

chris.chalmers — Fri, 27 Mar 2009 22:18:18 GMT

Can a machine categorize or tag email any better than a person?

In our previous post, we explored how to make it easy for users to categorize an email inside of Outlook. But what if the user still isn't doing it, in spite of how easy we've made it? Or what if the user has good intentions, but makes an honest mistake? Is there any way to automate this?

Yes we can automate this, with Exchange 2007 Transport Rules. Does it do a "better" job than a human? Let's take a look.

First off, here's a nice summary of the "Transport Rules" feature on the MS Exchange Team blog. It's useful for many things besides message classification: http://msexchangeteam.com/archive/2006/12/12/431879.aspx

Next, let's take a sample email, and see how a transport rule would work.

FROM: Legal Department

TO: Executive Staff

SUBJECT: Courtroom strategy for Them v. Us

Please do not bring your Blackberry into the courtroom on days when you are testifying. It makes us look bad, and if you keep looking at your Blackberry while giving answers, the opposing council may want to see it, too.

Transport rules can use many fields as inputs (also called 'conditions' or 'predicates') when making a decision about whether or not to classify an email. For example, in the sample email above, the fact that the sender was a member of the Legal group, and/or the recipient was a member of the Executive staff can be considered by the transport rules engine. Also, the appearance of the phrases "Them v. Us" and "courtroom strategy" in the body of the message can be added to the evaluation.

Here's a complete list of conditions/predicates that Transport Rules can use to classify an email: http://technet.microsoft.com/en-us/library/aa995960.aspx

Is it a guarantee that the sample message above is attorney-client privileged? No, but it's likely. And knowing that is valuable, especially when it can be calculated for free.

Transport Rules bring three benefits to message classification:

1) They’re always working. They don't get tired, or forgetful, or confused. They don’t get in a hurry on Friday afternoon. They always fire, no matter what.

2) They reduce the search scope. You're still going to have lawyers review emails as part of the e-discovery process, but anything you can do to reduce the search scope will save you money. If an expert is double-checking the 5% of messages that the machine thinks might be privileged, you’ve just made your search problem 20 times smaller.

3) Classification happens immediately when the message is sent, there's no waiting around for a skilled person to review it. Suppose in our example, two employees who are not members of the legal team are discussing "Them v. Us." Their conversation might be privileged and they don’t know it. Or their conversation might be forbidden by company policy. Or any email discussing the case cannot be sent outside the company. Transport Rules can help with all of that.

Transport Rules can do more than just classify.

Expanding upon example 3 above, I noted you can suppress (not deliver) certain kinds of emails. There's a whole host of actions that can be taken based upon the message's contents, including:

Notifying managers,
Logging the message in a special archive,
Altering the contents by appending a disclaimer,
Etc.

Here's a complete list of actions that can be take: http://technet.microsoft.com/en-us/library/aa998315.aspx

Regular Expressions in Transport Rules

People sometimes ask me, "What kinds of patterns can I use? Can I trap social security numbers (nnn-nn-nnnn) or credit card numbers (nnnn-nnnn-nnnn-nnnn) in emails?"

The answer is yes, but it gets pretty geeky pretty fast. Exchange uses a technology called Regular Expressions. These are pretty common in the world of programming (and Unix administration), but not for the faint of heart. Here's a quick primer on what they are : http://en.wikipedia.org/wiki/Regular_expressions

What is so great about this feature is that it has all the power and flexibility of serious computer programming, but the features are exposed right in the Exchange Management Console: All you have to do is type your expression into a dialog box, there's no scripting or programming required to use the feature.

Here are specifics for adding Regular Expressions to your Exchange Transport Rules: http://technet.microsoft.com/en-us/library/aa997187.aspx

In conclusion, an existing out-of-box Exchange feature can automatically categorize email, with varying degrees of precision depending upon how complex a rule you want to write. If you're concerned about end-user compliance with tagging schemes, or just want an extra layer of security and common sense around your message handling, Transport Rules are for you.

Tag! Episode 2: Email Messages Tagged While You Wait

chris.chalmers — Fri, 09 Jan 2009 04:31:24 GMT

When email messages need to be examined for attorney/client privilege, discovery slow to a crawl. And obviously the expense of preparing for discovery goes way up. If only there were an easy way to get users to tag email messages so people don’t have to try so hard later on figuring out what’s relevant and what’s privileged.

But most tagging systems are doomed to fail, due to lack of end-user participation. I recently had the pleasure of seeing Mark Diamond, CEO of Contoural (www.contoural.com) give a presentation, and he insisted that tagging schemes needed to obey the “5-second Rule.”

The 5-Second Rule:

If it takes the user longer than 5 seconds to tag the document, (or record, or email), he or she is going to start looking for ways to get around the system instead of providing the required metadata.

Pretty sad, but entirely believable. When you think of how much trouble an employee might be saving the company by correctly tagging a message, it just makes you shake your head. Then again, incorrectly tagging a message that probably will never get examined anyways is hardly going to bring one’s company to its knees. 5 seconds is about right. Fortunately, Outlook 2007 and Exchange 2007 have a new tool that fits the bill: Message Categorization

Exchange 2007 Message Categorization

This features lets Exchange administrators create a customized drop-down menu of message categories, like “Attorney/Client Privileged,” “Company Confidential,” etc. that end users can rapidly apply to any message (in less than 5 seconds). Administrators control the name of the Category that appears in the menu, the “helper text” that appears to the end user in Outlook, as well as any text appended to the message itself.

Exchange and Outlook ship with two “default” classifications built-in, so you can see how it works, but the system is completely customizable, you’re free to create new categories or edit the default ones. Here’s a great overview of how it works: http://technet.microsoft.com/en-us/library/bb123498.aspx

And here’s a screenshot of what the end user sees in Outlook 2007:

In our next post, we’ll examine additional rules and behaviors that Exchange administrators can configure based on message categorization.

Is it "Safe" to Store Voicemail in Exchange 2007 Unified Messaging?

chris.chalmers — Mon, 25 Aug 2008 13:46:00 GMT

I've co-authored a post on the MS Exchange Team's blog, "You Had Me At EHLO." It's entitled "Voice Mail and Discoverability with Exchange 2007 Unified Messaging," and explores the features and functions, as well as some of the legal wrangling around storing voicemail, email, and faxes in one system.

You can read it here: http://msexchangeteam.com/archive/2008/08/21/449657.aspx

In summary, Microsoft hired a law firm to write a white paper investigating the problem, and the white paper concludes ".that no aspect of Exchange alters, by increasing or decreasing, the record retention obligations of these organizations in the U.S. or E.U. ." That is, if a company is obligated to retain voice mail messages, it doesn't matter if they're stored in Exchange 2007 UM or somewhere else - they still need to be retained. Likewise, if voice mail messages have been deleted in the normal course of business prior to an obligation to retain them, the fact they were in Exchange 2007 UM doesn't create a new obligation to retain where no obligation existed before.

Anyway, it's a great post, I had a lot of help with it, and I highly recommend reading it. There's also a lively comments section down below.

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 .

POP! Goes the Evidence.

chris.chalmers — Fri, 18 Jul 2008 07:30:00 GMT

Who could resist a catchy title like this: "Court-ordered forensic search of CEO's laptop?" When I first saw that, I immediately wondered, "Just how many Michael Bolton MP3s were on there?" But if you read the tale of Treppel v. Biovail on the K&L Gates E-discovery blog, you'll discover a far less insidious finding (unless "This is the Time: The Christmas Album" was involved).

The Judge ordered the defendants to produce documents (email) in "native format," and wouldn't you know it, the documents weren't forthcoming - even after a couple of trips to the backup tapes. The court noted that the “unique procedure” by which the CEO’s email was downloaded to his personal laptop and then deleted from Biovail's servers resulted in his email not being preserved on the backup tapes. The forensic scan was ordered in an attempt to retrieve the emails, since they weren't available by less onerous means. See the original post here: (http://www.ediscoverylaw.com/2008/04/articles/case-summaries/inadequate-preservation-efforts-necessitate-restoration-and-production-of-email-from-backup-tapes-and-forensic-search-of-ceos-laptop/)

Intentionally configuring your email system with a "unique procedure" so messages don't get backed up?

This should be interesting. Setting aside the legal implications of a "shred all" retention policy for the moment, let's see how that would work in Exchange 2007. Since I have absolutely no knowledge of which email server the defendant actually used, let's take the generic case of Contoso Corporation, our make-believe company running a very real Exchange 2007 server.

If you want to copy the email off the server to read later, you need to copy it on to the client laptop. There are three protocols for clients to retrieve email from Exchange servers: POP3 (Post Office Protocol), IMAP4 (Internet Message Access Protocol), and MAPI (Messaging API, sometimes called MAPI/RPC).

By default, Outlook uses MAPI to retrieve email: Email is always on the server, the Outlook client merely provides an easy way to manage and control it. If the Outlook client is using "Cached Exchange Mode," then there are two copies of each email: one on the laptop, and one on the server. (Outlook has technology to keep the two copies in sync).

POP is different. The email client has the option to "leave email on the server" which is a lot like MAPI or IMAP. But if the client hasn't chosen to "leave email on the server," then it is deleted as soon as the client has downloaded it.

Is it hard to do?

Not in the least. The Exchange Administrator needs to do two things: 1) Enable the Client Access servers to support POP (it's turned off by default), and 2) enable the user's mailbox to allow POP access.

1) Here's the instructions for enabling POP3. As usual, it's a one-liner in PowerShell: (http://technet.microsoft.com/en-us/library/bb124934(EXCHG.80).aspx)

Set-service msExchangePOP3 -startuptype automatic

2) And here's the instructions for enabling a user for POP. Another one-liner:

Set-CASMailbox -identity "Don Hall" -Popenabled $true

The only gotcha is having to restart the POP service each time you enable new users (yet another one-liner) (http://technet.microsoft.com/en-us/library/bb124578(EXCHG.80).aspx)

Did the forensic scan of the CEO's laptop find anything?

It's not clear from the K&L Gates blog post, but it's quite possible something incriminating was uncovered. Craig Ball, a certified computer forensic examiner, lays out some concrete steps for a client-side email scan in his "4 on Forensics: 4 Articles on Computer Forensics for Lawyers" at http://www.craigball.com/CF4_0807.pdf. Favorite spots on the laptop to search include Microsoft Outlook caches like the .ost file and .pst files, as well as other email clients' equivalent folders.

And in the ultimate irony, the server may STILL have copies of the email, even after configuring it for POP. Exchange 2007 has a "Deleted Items Retention" feature, where emails that users have deleted aren't really erased for another 14 days. This feature is designed to keep sys admins from pulling their hair out when end users call looking for email they accidentally erased.

In the end, POP3 works like an actual magic trick. It provides the illusion of making something disappear, but in actuality it's just hidden behind another curtain.

Hold Me Now! How to quickly put a retention hold on 1,400 employees using Microsoft Exchange 2007.

chris.chalmers — Tue, 15 Jul 2008 06:34:00 GMT

The consequences for failing to correctly implement a retention hold can be severe. For example, issues surrounding a litigation hold helped cause Intel to lose attorney-client privilege and work-product protection of certain materials relating to their defense against AMD and Class Plaintiffs in the ongoing saga of In re Intel Corp. Microprocessor Antitrust Litigation.

K&L Gates has an excellent blog posting discussing some of the problems Intel had that led up to the court's finding. There's challenges getting the retention letters to the right people, juggling backup tapes, and moving users from one email server to another, etc. You can find K&L's blog posting here: (http://www.ediscoverylaw.com/2008/06/articles/case-summaries/finding-waiver-of-attorneyclient-privilege-and-work-product-protection-court-orders-production-of-attorney-notes-of-employee-interviews-concerning-intels-compliance-with-evidence-preservation-obligations/).

The challenges of implementing a legal retention hold certainly are not unique to Intel, so let's examine the generalized case of a fictitious company named Contoso. Contoso has 50,000 employees using Exchange 2003. In order to avoid drowning in terabytes of email, they have implemented a 45-day purge policy using Exchange 2003 Mailbox Manager.

Because of impending litigation, Contoso's legal department has sent a litigation hold letter to 1,400 key employees who need to save emails beyond 45 days. Those employees must manually move their emails into a local .PST file on their desktop computer, or have their mailboxes moved to an Exchange database that has Journaling enabled, because Exchange 2003 only journals at the database level .

What could possibly go wrong?

For starters, there's the end users manually moving messages (or forgetting to move) to .PST files. Next, there's making sure those .PST files actually get backed up on a regular basis. You'd think people would just know to back everything up by now, but there's always an exception. Just last week I worked with a user who had a hard drive crash and lost everything. Haven't we all been there at least once?

If Contoso moves to server-side journaling to remove end-user complexity, it creates a new burden for the IT staff. Databases have an optimal number of mailboxes on them, and as you move too many mailboxes, or a few too-large mailboxes, to a journaling-enabled database , you run up against a new set of challenges: The databases' maximum size, the underlying storage design, running out of servers or having to move them from one location to another, etc. Journaling also has performance implications (since you're sending each message twice) that need to be accounted for.

How is Exchange 2007 different?

There are three excellent features that can specifically target this scenario: Retention Hold, Premium Journaling, and PowerShell scripting.

An Exchange 2007 "Retention Hold" suspends the ordinary email purge cycle applied to the user or organization. It's a simple mouse click (or a line of shell scripting, as we'll see below), and IT staff can also set an end date for the retention (which makes the feature useful for employees on vacation or infant care leave, for example). In the Contoso example above, we would apply a retention hold to each of the 1,400 mailboxes in question. Learn more here: (http://technet.microsoft.com/en-us/library/aa998580(EXCHG.80).aspx)

Premium journaling is essentially the ability to journal email to a separate system on a per-user or per-group basis. It puts an end to all the contortions IT staff used to have to undergo, because any database can have a mixture of journaled and non-journaled accounts. Users' mailboxes stay where they are, and journaling is turned on and off as needed. Learn more here: (http://technet.microsoft.com/en-us/library/bb124382(EXCHG.80).aspx)

PowerShell scripting is an exciting new innovation across the Windows platform, and Exchange 2007 is one of the first Microsoft applications to make full use of it. Here's a simple one-liner to apply a retention hold on Contoso employee Aaron Lee's mailbox:

Set-Mailbox -Identity 'Aaron Lee' -RetentionHoldEnabled $true

Easy! Now, just type that in 1,399 more times, and we'll be all set! Just kidding, PowerShell has another command called Get-Mailbox that lets you fetch mailboxes you want subject to retention hold. For Contoso, that will be everybody in the Sales and Developers departments (or Organizational Unit, as they say in Active Directory-speak).

Get-Mailbox -OrganizationalUnit 'Sales'

And there's a whole host of other attributes we can use to fetch mailboxes, like Title, Department, City, Country, etc. that can be used as a filter here. You can also mix-and-match, like all the Accountants based in New York.

Our last step is to marry the two commands together using the "pipe" character, so the final command would look like this:

Get-Mailbox -OrganizationalUnit 'Sales ' | Set-Mailbox -RetentionHoldEnabled $true

Voila! That's all there is to it. This one-line command has turned on a retention hold for the entire Sales department at Contoso! No dependency on .PST files, no dependency on end users remembering to do the right thing, and no moving mailboxes from server to server.

Next posting: we explore ways Exchange administrators might attempt to "erase" emails off their server