MS Exchange PST Infestation: What do you do with all that data?

Written by Dan Erelis, Microsoft Premier Field Engineer, based in Canada.

MS Exchange PST InfestationLet me start with the obvious: if you have ever supported Microsoft Exchange or Outlook you already know the fundamental DON’T of PST storage: personal folder files (.pst files) are unsupported over a LAN or WAN link.  

Now that we have the technical reasons out of the way, let’s look at some more issues associated with PSTs:

  • Higher service desk support costs
  • Data duplication contained in multiple copies
  • Document versioning issues
  • Potential for data leakage
  • Backup costs

I’ve been supporting Exchange messaging for over 10 years and observed many organizations amass an enormous data blob of PSTs. Sometimes humorously referred to as “Poor Storage Technology”, PST storage and support can represent a noticeable cost to most IT shops.

Organizations ranging from 2,500-10,000 users typically average 4-to-8 terabytes of PST data on the network at any given time, and I’ve seen  some over 20 TBs. If I took an educated guess at what percentage of this data was A) relevant to the company business, and B) not stale (meaning past company retention policies) I would say only 20-30% is relevant and in-policy data.

Solutions for Exchange PST Infestation

I’ve worked with numerous customers ranging across all industry sectors (including Healthcare, Manufacturing, Oil and Gas, Government and University institutions to name a few) and there are 5 main approaches to dealing with PST infestation:

  1. Don’t allow PSTs, use policies to prevent it. Users have a strict mailbox limit and are forced to delete mail on a regular basis. These are the customers that typically do not bend rules, increase MBX sizes and simply take a hard line.
  2. Allow PSTs stored locally but are unsupported internally and not backed up. Obviously this leaves the door open to data loss, leakage etc.
  3. Allow PSTs to be stored on the network, backing these up nightly and incurring additional support overhead that goes along with this.
  4. Don’t allow PSTs, Use a document management system for important company data, whereby company data is moved and not stored in the email system leaving only transient data.
  5. Don’t allow PSTs, implement an archiving solution such as that included with Microsoft Exchange 2010.

Ideally options #4 and 5 would be in every environment and mailboxes would never need to exceed 500MB. Unfortunately for many organizations, Enterprise Content Management (ECM) has not reached a level of maturity where users feel comfortable removing data from their mailbox and even though there is a system in place to manage their data they continue to use PSTs or their mailbox as a document repository.

Here is where Exchange 2010 archiving can step in and assist with managing this data in such a way that is familiar to both the end users as well as the administrators supporting the system. Take a look at the features of Exchange 2010 and compare the benefits from many angles. What are the support costs of a 3rd party solution such as additional SQL servers, separate provisioned storage on a SAN, licenses from third parties, high availability considerations are some examples. Take this information and compare it to what the TCO would be running the archive natively in Exchange 2010.

Start Here - Exchange 2010 Archiving, Retention, and Discovery.

*When researching Exchange 2010 documentation pay close attention to the document version as there have been several changes with the recent release of Service Pack 1.