E-Discovery and Microsoft Technology

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.

Tag! Metadata Made Easy in Vista

chris.chalmers — Mon, 20 Oct 2008 03:47:00 GMT

Just in time for Halloween, a scary story about metadata! Who knows what awful, incriminating secrets lie hidden in your Word document's metadata, waiting to betray you? After all, isn't that why attorneys request "native format" document production? So they can revel in the smoking guns buried in your metadata that you never even knew you were transmitting?

It wasn't supposed to be this way. And in Vista, it isn't.

Metadata is supposed to help the user. And Vista makes it easier than ever to view and edit a document's metadata, search using metadata, and remove document metadata - all without having to launch the underlying application that created the file (like Word, Excel or PowerPoint).

It can also be part of a larger "Manage in Place" strategy for e-discovery. Step One is simply making the end users aware of the metadata they generate, and Step Two is giving them an easy tool to edit it. Just another little way to make it easy to categorize documents in-place, and reduce the amount of unnecessary, discoverable data lying around your network.

So how do I make it easy to view metadata in Vista's Windows Explorer?

First off, here's a quick overview of all the enhancements to Windows Explorer in Vista:

http://www.microsoft.com/windows/windows-vista/features/explorers.aspx

We're primarily interested in the new "Details" pane at the bottom of the explorer. By right-clicking on the pane, you can choose to make your view Small, Medium, or Large. Here's a screenshot of the Details pane set to display "large" amounts of metadata.

(Thanks to the Windows Live Writer beta team, which made putting this screenshot into my blog incredibly simple).

As you can see, it's easy to view the metadata associated with any file simply by clicking on it - opening is not required. Also, if you use the expanded "Details" view in Explorer, you can have any metadata field displayed, not just size and last creation date.

Next: Searching your metadata

The Search panel is in the upper-right corner of the Explorer. Of course you can type in keywords like "short-sale" or phrases like "credit default swap." By default, these searches are applied to the full text of the documents you're searching. If you want to restrict your search to just the metadata fields, begin your query with the metadata field name. For example, these are valid metadata queries:

comments: review

author: chris

And these queries can be strung together. For example, if Chris ever used the phrase "approved" or "bury it" in the comments of a document that Dave authored about Contoso, it would look like this:

Contoso author:dave comments:(“needs review” OR "fix this")

Here's a complete description of the query language built into Windows Desktop Search (built into Vista, and a free download for Windows XP) http://www.microsoft.com/windows/products/winfamily/desktopsearch/technicalresources/advquery.mspx

What about removing the metadata?

Ahh, the best feature of all. You can select one or several files in Windows Explorer, and right-click them and choose Properties…Details. From there you'll see the link to "Remove properties and personal information." Here's a screenshot

(Did you notice the "Last Printed" field? Interesting…) Note that you can remove all the metadata fields, or only some of them.

Here's more information about how bulk-remove metadata from a group of files:

http://windowshelp.microsoft.com/Windows/en-US/Help/06605e2a-3f56-488b-8415-702813f24c791033.mspx#EQB

Best of all, Windows will even prompt you to either overwrite the original file, or create a new metadata-free version of the file.

Hopefully this post has encouraged you to embrace, or at least consider, Vista's improved metadata handling features. Even the simplest usage of metadata can be superbly helpful. For example, I review lots of PowerPoint presentations in my line of work: Simply adding the word "good" to the Comments field of the ones I liked makes it much easier to find them later.

And if you're afraid the metadata bogeymen are out to get you, you can now banish them forever with a couple of mouse clicks. Happy Halloween!

Managing USB Thumb Drives - Is Vista Better Than Epoxy?

chris.chalmers — Tue, 09 Sep 2008 05:43:00 GMT

What's so bad about USB flash drives? Isn't it great that, for less than $50, I can buy device the size of my thumb that holds 16Gb of emails, product designs, and drafts of confidential memos? In a word, NO.

From an e-discovery perspective, tracking and managing all these potential sources of responsive information is a nightmare. Brad Carlson of Fios, Inc. outlines a helpful process in his article, "Collecting Personal Data for E-Discovery" in Computer Technology Review (you can read it here:

http://www.wwpi.com/fall-2007/2794-collecting-personal-data-for-e-discovery) .

But the sheer scope of the problem is overwhelming. Here at Microsoft, USB flash drives are a frequent promotional giveaway: I've seen flash drive key chains, flash drive Swiss army knives, flash drive flashlights, even a flash drive wristwatch. How can attorneys possibly have any confidence that they've identified all the sources of data they might use in their claim or defense?

I once knew a sys admin who was so concerned about the potential damage those tiny USB drives could cause his organization that he put epoxy into the USB ports of all new laptops that came into his organization!

Needless to say, there's a better way to manage USB devices in Windows Vista and Windows Server 2008.

There's a new set of Group Policy Objects (GPOs) specifically for managing USB devices. If you're not familiar with Group Policy, here's a one sentence description: it lets administrators turn off certain features of Windows in a way that users can't turn them back on. You can learn more at the Group Policy center here:

http://technet.microsoft.com/en-us/windowsserver/grouppolicy/default.aspx

TechNet Magazine has an article that explains how to use Group Policy to control which USB devices (if any) can connect to the USB ports of Vista machines. The article was written from a security perspective, but it's easy to see how it applies to e-discovery. " Security: Managing Hardware Restrictions via Group Policy"

http://technet.microsoft.com/en-us/magazine/cc138012.aspx

The controls are quite granular. In a more in-depth article on MSDN, you can learn how to "authorize" USB connections down to the individual device manufacturer's make and model. The article is "Step by Step Guide to Controlling Device Installation Using Group Policy:"

http://msdn.microsoft.com/en-us/library/bb530324.aspx

Here are some of the highlights:

Prevent users from installing any device.
Allow users to install only devices that are on an "approved" list. If a device is not on the list, then the user cannot install it.
Prevent users from installing devices that are on a "prohibited" list. If a device is not on the list, then the user can install it.
Deny read or write access to users for devices that are themselves removable, or that use removable media, such as CD and DVD burners, floppy disk drives, external hard drives, and portable devices such as media players, smart phones, or Pocket PC devices.

This gives administrators much more flexibility around using and deploying USB devices in a responsible manner. For instance, you could provide your users with a large "authorized" USB drive that they can use for their local backups. Meanwhile, all other USB drives won't be able to connect to the computer, because of your policy. It's the best of both worlds: you don't have to worry about all those USB thumb drives scattered about, and end users can still enjoy some of the benefits of USB.

No epoxy required!

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 .

Am I Retaining IM?

chris.chalmers — Sat, 02 Aug 2008 20:29:00 GMT

"It depends."

As always, the correct answer is whatever your in-house counsel tells you: we never provide legal advice here, only information for you to consider. Here's a couple of interesting bits -

First off, for regulated industries like stockbrokers, it's a no-brainer: you save IM. That was easy!

For others, it's not electronically stored information (ESI) as long as you're not archiving your conversations. Gregory S. McCurdy wrote in the Yale Law Journal, "...IM conversations - like telephone calls - are not ESI so long as they are not stored in any analogous way…" and also, "…In terms of technology and user expectations, instant messages are like phone conversations and the law should treat them as such…"

You can check out the whole article here (it's a quick 5 pages): Thomas W. Burt & Gregory S. McCurdy, E-Discovery of Dynamic Data and Real-Time Communications: New Technology, Practical Facts, and Familiar Legal Principles, 115 YALE L.J. POCKET PART 166 (2006), http://www.thepocketpart.org/2006/08/burt_and_mccurdy.html.

What are you using IM to talk about?

The nature of the conversations may come into play. If your IM chats are of the typical water-cooler variety, that's fine. But if your users are explicitly using IM to avoid email retention, or they're using IM's file-transfer feature to exchange documents outside of your email system or workflow process, you could be on shaky ground.

In the recent Bear Sterns debacle, two executives apparently used their wives' home email accounts to have business-related conversations outside their company's retention mechanism. Needless to say, the court was unimpressed. Here's an interesting quote from the news coverage:

"If you have one or a handful of damning e-mails on a personal account, prosecutors will argue that use of e-mail is consciousness of guilt because they took a route to communication that they thought wouldn't be discovered," said Daniel Horwitz, a former assistant district attorney in New York, now a partner at the law firm Dickstein Shapiro. You can read the whole article here: http://seattlepi.nwsource.com/business/368153_email24.html

Is retaining IM easy, or does it require "heroic" effort?

FIOS has on on-demand webcast (registration required), led by Ronni Solomon, Esq., Counsel, King & Spalding that explores IM discoverability in depth. One of the issues she discussed is whether or not it's easy to turn on archiving: that is, if your system cannot archive IM, then recovering messages is very difficult. However, if archiving is installed but deactivated, it is (or would have been) very easy for you to store IM. The webcast has been archived here: http://www.fiosinc.com/events/webcasts/webcast_detail.asp?id=WC20080729

Of course, being able to easily archive IM is not always a bad thing. For instance, when your company changes from a normal operating environment to "litigation is reasonably imminent," your discovery needs will change, and you just might want to turn on archiving for a group of individuals, or the entire company.

So how does OCS 2007 IM Archiving work?

With OCS 2007, there is an optional Archiving server role that can be installed. The entire OCS Archiving deployment guide is online here: http://technet.microsoft.com/en-us/library/bb894700.aspx .

Here's the highlights:

It requires Microsoft Message Queuing (MSMQ), which is free Windows add-on,
It stores the conversations in SQL Server.
The reports don’t come with the server, they're part of the free OCS 2007 Resource Kit, which is downloadable here: http://www.microsoft.com/downloads/details.aspx?FamilyID=b9bf4f71-fb0b-4de9-962f-c56b70a8aecd&DisplayLang=en
All the messages are stored in a SQL table called "Messages," so you can write your own reports if you're so inclined
You can choose to turn on archiving for everyone, or only certain individuals
You can also choose archive all of an individual's conversations, or only conversations with people outside the company
If you're using OCS 2007 for voice calls as well as IM, you can archive Call Detail Records (CDRs), which stores data similar to what you see on a monthly phone bill.

Here at Microsoft, the IT department has deployed Archiving, and our internal OCS deployment is described in this white paper (with accompanying PowerPoint presentation): http://technet.microsoft.com/en-us/library/cc297283.aspx .

It's handy to see what kind of hardware and architecture we use to archive here at a large corporation - however, please don't infer any legal advice or conclusions from the fact that we archive (or have the capability to archive). Microsoft IT has plenty of other reasons to turn archiving off and on, such as experimenting with the feature set, implementing chargebacks to business units, usage reporting, sheer curiosity, etc.

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

Why E-Discovery?

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

I wanted to make a quick post to motivate why e-discovery is so important to IT Pros. Isn't it reasonable to assume that this is just a problem for lawyers, or that the IT staff is going to play a minor, supporting role in all this?

Not anymore. There was a recent change to the Federal Rules of Civil Procedure in Dec. 2006 that expanded our definition of what's discoverable (i.e. can potentially be introduced as evidence in a civil trial) to include "electronically stored information," or ESI. There's a brief discussion of the amendment and its general implications here:

http://www.uscourts.gov/ttb/11-06/electronically/index.html

The changes to the rules are designed to bring fairness to the e-discovery process, like not punishing companies that accidentally lose data in the normal course of doing business. But it does create an obligation to understand where all your potentially discoverable information is located, and how you manage it.

Here's an example of a preservation order the court gave to the parties in a recent trial.

Just stop for a moment, and ponder the breadth and depth of material this encompasses:

"All parties and their counsel are reminded of their duty to preserve evidence that may be relevant to this action. The duty extends to documents, data, and tangible things in the possession, custody and control of the parties to this action, and any employees, agents, contractors, carriers, bailees, or other non-parties who possess materials reasonably anticipated to be subject to discovery in this action.

"Documents, data, and tangible things" is to be interpreted broadly to include writings; records; files; correspondence; reports; memoranda; calendars; diaries; minutes; electronic messages; voicemail; E-mail; telephone message records or logs; computer and network activity logs; hard drives; backup data; removable computer storage media such as tapes, disks, and cards; printouts; document image files; Web pages; databases; spreadsheets; software; books; ledgers; journals; orders; invoices; bills; vouchers; checks; statements; worksheets; summaries; compilations; computations; charts; diagrams; graphic presentations; drawings; films; charts; digital or chemical process photographs; video; phonographic tape; or digital recordings or transcripts thereof; drafts; jottings; and notes. Information that serves to identify, locate, or link such material, such as file inventories, file folders, indices, and metadata, is also included in this definition.

That's a lot of stuff! How would you respond to a request like that?

And the price of mis-handling e-discovery obligations is going up. Here's a blog posting examing three cases that have received wide attention, where the court doled out punishment to the parties for failing to properly manage their e-discovery: http://www.law.com/jsp/legaltechnology/pubArticleLT.jsp?id=1202423426906&rss=ltn

Your legal department will depend on you to understand where all this data is, and how it all fits together. A good start to your e-discovery best practices is understanding how all your systems work, and being able to explain them to your legal department.

Another best practice is having fewer systems, more tightly managed. For instance, if you're asked to produce emails relating to a certain patent, would you rather search:

Exchange, or
Exchange, plus individual .PST files on laptops, network folder shares, Outlook Express clients on home computers, Blackberry devices, and web-based email accounts?

So that's what is motivating this blog. Exchange Server 2007, Office 2007, and SharePoint 2007 have a host of features that can help you support your legal staff and your company, and we're going to explore this in more detail.

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