Why PSTs should never show their faces on a file share

I've ranted at various conferences over the years about the horrors of the PST file format and why I hate these files so much. There's actually good technical reasons why I dislike PSTs so much, including the very horrible things that can happen to a Windows server if PSTs are hosted on network file shares.

I don’t mind it being known that I hate PSTs. Not because I buy into the “everything must be in the Store” line, even though this is an excellent approach to take for any company seeking to implement compliance standards within the organization. My opposition is more fundamental and is all to do with the many technical problems exhibited by PSTs.

It is understandable that users like PSTs and that some administrators like them too. PSTs provide a nice way for users to gain extra storage for email. But this argument is rapidly fading in light of cheap disks and the subsequent increase in mailbox quotas. If Office 365 can offer 50 GB mailbox quotas, it’s surely possible for on-premises Exchange deployments to allocate a 10 GB quota. That would go a long way to nullifying the argument for PSTs and provide a much better basis for achieving compliance too.

Getting back to the problems that cause me to despise PSTs, the first thing to understand is that PSTs were never designed to handle the kind of situations they are placed in today. In the early days of Exchange, a PST was a necessity because server disks were expensive, Exchange supported a single 16GB Information Store database, tiny mailbox quotas were the norm, and only the default mail folders (Inbox, Sent Items, Calendar, etc.) were synchronized into an OST. Using PSTs made it possible for users to hold more information offline and released pressure on the server.

Some like PSTs because they can be password-protected. The theory is that this prevents unauthorized access and allows users to squirrel away their secrets into a safe hole. Alas, PST password cracker utilities have existed for many years and a quick search reveals many possibilities (here’s one) for bypassing or recovering passwords. In addition, a PST can be opened by any MAPI client. No tie exists in the file to prevent a PST being opened by anyone but its owner or a particular mailbox. In short, give me a PST and I will have it open and exposed to all and sundry in a few seconds. Or maybe a minute.

The original ANSI-format PST was limited to 2 GB and was prone to corruption when the file size approached this limit. Microsoft addressed the issue over ten years ago by upgrading the file format to Unicode. With Outlook 2013, the PST limit is 50 GB, which seems too large for me. PST corruption is definitely less problematic now, but corruption does still happen, and when a PST goes bad you have a real problem. Few users are good at backup so it’s often impossible to restore a corrupt PST with the consequent data loss.

To get around the problem, administrators often place PSTs on network file shares. On the surface, this looks like a pretty good idea. Users can continue to use PSTs as before and administrators can take care of backups. Even though Microsoft has never supported placing PSTs, OSTs, or OABs on network file shares, the practice persists because it solves a problem. Despite the lack of support, everything works.

At least, it seems to work. And to be fair, accessing a PST on a network file share does work, albeit with unintended consequences. I doubt that you will experience problems if only a few clients access PSTs on a network file share. Problems mount as demand grows because you are asking Windows to do a job that it was not designed to handle with a file format that was always intended to be located on a personal drive.

An excellent article from the Windows Server Performance Team explains the reasons why you should never put PSTs on network shares. Despite its age (written in January 2007), the article is still pertinent and it lays out the technical issues for the server caused by forcing PSTs to do unnatural things, including such horrible problems such as depletion of the non-paged pool and the disk stutter that can happen when multiple users access PSTs on a file share. It’s a good read.

But don’t let well-founded arguments put you off from locating PSTs where you want. It is your right to put files where they seem to belong and if you choose to accept the risks, then who am I to tell you what you should be doing? For me, I think I’ll continue to abhor PSTs, avoid them as much as possible, and not worry about pool depletion. It just makes sense.

Follow Tony @12Knocksinna

Discuss this Blog Entry 5

on Mar 12, 2015

It's funny how so many IT organizations have started initiatives to "eliminate pst's", only to fail because there isn't an "as good or better" solution. 10 years on, both local and cloud storage is dirt cheap, but we're now drowning in PST's, many of which contain duplicate data. At my IT org, we were only able to get this moving because we came at the problem from a RIM and legal perspective. With PST's, these teams have zero visibility into company data, which can have disastrous consequences.

Funny side note - Microsoft themselves still use PST's :)

on Mar 12, 2015

Not sure if the reason PST shouldn't be on file servers holds true anymore.

SMB2 & SMB3 do take a lot of the issues out of the problems PST has when on network drives.

on Mar 15, 2015

If a file format is designed for personal use on a local drive, it is likely to have problems on a network drive. As I point out in the article, you can go ahead and use PSTs on network drives, but don't expect much sympathy if things go wrong. And can I say again that I hate PSTs...

on Mar 17, 2015

I wonder if SSDs would also improve things.

on Mar 30, 2015

SSDs enable faster access to PST contents but they cannot mask the fundamental nature of the access mechanism designed into this file type.

Please or Register to post comments.

What's Tony Redmond's Exchange Unwashed Blog?

On-premises and cloud-based Microsoft Exchange Server and all the associated technology that runs alongside Microsoft's enterprise messaging server.

Contributors

Tony Redmond

Tony Redmond is a senior contributing editor for Windows IT Pro. His latest books are Office 365 for Exchange Professionals (eBook, May 2015) and Microsoft Exchange Server 2013 Inside Out: Mailbox...
Blog Archive

Sponsored Introduction Continue on to (or wait seconds) ×