Why PSTs should never show their faces on a file share
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.
March 12, 2015
![Why PSTs should never show their faces on a file share Why PSTs should never show their faces on a file share](https://eu-images.contentstack.com/v3/assets/blt07f68461ccd75245/blt9eb4519b576df773/6618163d08cc756a8fa6d2ca/emailyeild_2_4.jpg?width=1280&auto=webp&quality=95&format=jpg&disable=upscale)
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
About the Author
You May Also Like