Hi Sharon, 

<snip>
These are some of the issues I gleaned from the research (nothing more
recent than 2008): MicroSoft doesn't support .pst files in shared drives;
.pst files get corrupted (can't open) and they take up a lot of room;
converting email messages to .pst files changes the format of the file; and
.pst files have created havoc with servers.
</snip>

First, the ones you identified: 
1. Microsoft does not support accessing .pst files from shared drives.
Depending on your network bandwidth and utilization there may also be some
delays in accessing messages that way. 
2. .PST files certainly can become corrupted, just as with any other
database (and that's functionally what a .PST file is). 
3. They take up more room given that each message is stored twice, as a RFC
2822-compliant text file and as a native .MSG file. Significantly more
importantly though, a message sent to 500 people in Exchange 2003 uses
single-instance storage, where one copy is saved plus 500 pointers to that
copy. That same message stored in .PST files would be stored in *each* .PST
file. So if it's a message with a 1 MB attachment, the total storage space
required could be 500 MB or more for that single message if everyone saved
it. 
4. .PST is a native format for Outlook. It represents a database of
individual .MSG files which is also a native format for Outlook. 
5. Not sure about the "creating havoc with servers" thing. 

Now, the ones that are not included: 
1. .PST files can be password-protected. This is not unbreakable encryption
by any means, but Murphy's Law of Discovery suggests that lots of your .PST
files will have passwords, and some of those people will have left the
organization, when the email subpoena hits. That means trying to crack them
open which has its own issues in terms of resources, provenance, etc. 

2. In addition, the default file name is archive.pst or backup.pst - can't
remember which - but the point is that you might have several hundred of
these laying around with the same file names, and if they are put on a
shared drive it might not always be obvious to whom they belong. 

3. If you use a tool to interrogate, extract, and review messages from .PST
files, as noted above you may have many different instances of the identical
message (at the binary level) meaning your tool must support deduplication
or someone will have to dedupe manually so you don't have expensive
attorneys or outside counsel reviewing 50 copies of the same message over
and over again. 

4. Depending on the nature of the content in the .PST, or in other words how
well staff comply with the stated requirements to move important stuff to
the shared drive, you run a substantial risk that some of the content in
those .PSTs will be stuff that should have been gotten rid of a long time
ago in accordance with the retention schedule. As you know, whether it
*should* have been deleted or not is in a very real sense immaterial - what
matters to the discovery process is whether it's a) responsive and b)
available. You'd have the same issue with any other storage approach as
well, whether email archiving, saving shorter-term messages in .PST files on
users' hard drives, etc. But you asked so I'm answering. :)

Hope this helps - I don't do as much email work these days but I still do
some and these are the immediate issues that came to me off the top of my
head. 

Regards, 

Jesse Wilkins, CRM
Director, Systems of Engagement
AIIM International
[log in to unmask]  
http://www.aiim.org  
(303) 574-0749 direct
Twitter: http://www.twitter.com/jessewilkins 
AIIM Capture Practitioner Course now available - visit 
http://www.aiim.org/training/capture-course for details. 

List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance
To unsubscribe from this list, click the below link. If not already present, place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body of the message.
mailto:[log in to unmask]