PST (Personal Storage Table) files were introduced over 15 years ago and are used to archive e-mails, calendar appointments, and other data into a single PST file (or multiple files if you like).

 

The main reason people use PST files is because mailbox size limits imposed by administrators give them no alternative but to archive their mail in this manner.  Additionally, depending on how Outlook is configured the end-user may have accepted its kind offer to auto-archive mail without fully understanding the consequences.

 

By default new PST files are created in a folder under the user’s profile so they are stored on the local hard disk.  Hang on a minute; we’ve all been warned about the perils of saving data locally so surely PST files should be stored in a secure network location.  Not so I’m afraid – Microsoft does not recommend the use of these archive files over the network.  PST files can grow to enormous sizes and as Outlook maintains a constant connection to the archives it’s easy to see why Microsoft makes this recommendation.  However it creates a catch 22 situation.  Your choices are to save PST files on the network and suffer degraded Outlook performance coupled with an increased risk of PST file corruption or save the PST files locally and risk losing data in the event of a hard disk failure, laptop theft etc.

 

PST files are prone to corruption regardless of where they are stored and this can be caused for any number of reasons – bad sectors on a hard disk, power failure, application or OS crashes, network connectivity issues, virus/malware attacks, etc.  There are utilities to recover from corruptions (scanpst and some third party tools) but getting data back is never guaranteed.

 

Now, I’m not denying that PST files were invaluable in the early days of Exchange/Outlook but the time has most definitely come to banish them once and for all.  With a bit of planning and maybe a little investment I believe this is absolutely achievable.

 

Obviously every organisation is different but I’ll outline a couple of recent implementations I’ve worked on.

 

Case 1

An SMB customer had a legacy internal Exchange 2003 server for circa 100 users.  There was no resilience on this single server solution and the client suffered a fair amount of downtime over the last few years for various reasons.  Unhappy with the cost and complexity of maintaining this solution we agreed to move forward with a migration to office 365.  Taking the Staged Exchange Migration approach the users were migrated over the course of a week to ensure minimum risk/disruption.  Due to the small number of users the onsite support technician then assisted the users in importing any PST files they had into their new Office 365 mailbox.  The IT Director has deemed that the 25GB mailbox limit is perfectly sufficient for any individual’s needs.  In the future server based archival is an option that can be taken up.  Office365 has provided the additional collaboration tools of SharePoint and Lync and the company has also made move from BES/Blackberry to ActiveSync and opened up this capability to all staff.

 

Case 2

Working at a large corporation with several thousand seats we migrated all mailboxes to Exchange 2010. All end-users are now being upgraded to a new Windows 7 / Office 2010 laptops.  As part of the migration a custom built tool moves all local and network PST files to a network file share.  A PowerShell script executes as a scheduled task every night and ingests the data into the users Online Archive.  The users come in the following morning to receive their new Laptop with all their historical PST data available in their online archive.

 

The Online Archive is a new feature in Exchange 2010.  Essentially think of it as a secondary mailbox associated to the user’s primary mailbox that can be provisioned to a different mailbox DB.  This allows organisations to implement separate storage strategies for less frequently accessed e-mail (i.e. hosting the archive mailboxes on cheaper storage solutions).

 

In both of the of the above cases above applying a simple group policy setting to prevent the use of PST files was an absolutely essential step to ensure the problem does not return.  So to all sys admins out there who turn a blind eye to the use of PST files I say the time has come to do something about it!!

 

Comments welcome…