Article by Casper Manes
Using outdated technologies created for personal use in an enterprise environment has never been a good idea. Using Outlook's PST files in 2016 is a typical example of such a poor practice.
I was working with a customer the other day on their Office 365 deployment, and the topic of OneDrive for Business came up. Everything was going along just fine, until they mentioned in passing that amongst all the files they want to move from fileservers to users' OneDrives, PSTs will be the most beneficial, since they are clogging up the fileservers and bogging everything down.
I wasn't sure at first if I heard him correctly, but then I couldn't decide which surprised me more. Was it that they planned to move PSTs files to a storage location, which then wouldn't work, or that with a 50GB mailbox size in Office 365 they felt like they still needed PSTs. Regardless, I had to educate them on PSTs and why they are evil... uhm, I mean unsupported, and why storing them on anything other than a local hard drive is not only explicitly unsupported, but also a very bad idea. In case you are still using PSTs in your organization, or know someone who is, even though it's the year 2016, I would like to share some thoughts about this practice.
What are PSTs?
PST files are Personal Storage Table files, first introduced in early versions of Microsoft Outlook to store personal data, but which have since grown beyond all reckoning as a local storage repository for data, especially when your mean ol' Exchange admin won't give you enough space in your mailbox. PST files are an old, proprietary, monolithic file format which Outlook can use to store data, but really shouldn't. You see, the nature of this file format is to be very "expensive" in disk I/O terms, they are easily corrupted when a write operation is interrupted, and were actually never intended for enterprise use.
So what are they meant for?
PST files were originally intended to provide a local storage for non-critical, non-enterprise data. If you had Outlook connected to both your enterprise Exchange environment and your personal email account, you were supposed to keep your enterprise mail on enterprise storage, but since your ISP would want you to keep your mailbox small, preferably empty, PST files were a good way to store your personal emails coming from POP3 or IMAP systems.
And where did things go wrong?
Unfortunately, this was just a theory. In practice, combined with the extreme costs of high performing disks for Exchange, low mailbox quotas drove users to save company emails to PSTs when they ran out of space in Exchange. Admins, having no alternative recourse, actually encouraged this practice. And since storing mail in PSTs meant that enterprise data loss was a real risk, users were encouraged to store their PSTs in their home directories, so they could be backed up. And this is where things went horribly wrong.
The monolithic file format of PSTs means that reads and writes must be performed using serialized I/O. When one machine is doing this to one local file, it's not that noticeable or impactful. But store a PST on a network drive and the client must encapsulate the serialized I/O in RPC packets, which the file server must fulfill using a very costly mechanism that creates an execution lock, depletes non-paged pool memory, and ultimately can lead to server crashes.
Remember scheduling reboots of 32-bit file servers every night? Odds are good that PSTs were the root cause of the NPP depletion. And since writes to PSTs are not ACID, if a server crash, client crash, or network connectivity loss occurs, you can get a corrupted PST. Microsoft actually published a KB article in the early 2000s, warning against PST use by the enterprise: https://support.microsoft.com/en-us/kb/297019.
Why is storing them to the cloud a bad idea?
As bad as storing and accessing PST files is over the LAN, trying to take them to the cloud "as is" can be an even worse idea. OneDrive for Business, Dropbox, and other cloud storage solutions keep a local copy of the file on the client's hard drive, and sync any changes up to the cloud. But when Outlook mounts a PST it creates a lock on that file, which prevents the sync engine of your storage solution from synching the deltas, so it must cache each of the reads and writes until Outlook closes, and only then it can sync. The more changes you make, the larger that cache will grow.
Of course, consider the moment when most users close Outlook. It's usually about 10 seconds before they shut down their computer, which means that the cloud sync engine cannot sync the changes of such a large file before the PC shuts down. The next day, the user logs on, and what's the first app they are likely to launch? Yes, Facebook, but what comes next? That's right, Outlook. And if the sync engine hasn't finished synching yet, that's too bad. Eventually either the sync cache runs out of space, or the drive does, either way, it's bad news for the PST, your emails, and your company's bandwidth.
Many users want to access their mail from multiple clients. But when two different clients try to access PSTs one at a time, you can get file corruption. When you try to do it at the same time (like when you left your home computer on and Outlook running) the PST file on the local drive is locked and cannot sync to the cloud instance, so the other computer cannot sync changes back down. You wind up with, at best, an inconsistent view of the data, and at worst, with a corrupted PST file.
What's the alternative?
Give users enough space to store the data they need. Use a combination of messaging records management (MRM) policies and corporate guidance to help figure out what that space is, and remember that today's Exchange servers are very happy with JBOD and can perform quite nicely with that. With today's prices of hard drives and enterprise storage, keeping user mailbox quotas like it's 2006 is really unnecessary.
Or if you don't want to provision that much storage for users, look at cloud-based solutions like Microsoft Office 365 or Google for Work. Office 365 in particular offers users a 50GB mailbox, and has license plans that can provide an unlimited archive mailbox. Google has similar plans, with competitive pricing, and these two are not the only enterprise cloud providers out there. Email is very much a utility offering these days, and moving to the cloud may let you get out of the mailbox database quota management business altogether, allowing you to focus on more important things.
How can I stop the pain?
Use Group Policy to stop the creation and expansion of PST files by deploying the administrative templates for your version(s) of Outlook. But also provide users with enough space to store what they need, and use MRM policies to deal with the hoarders. If you move to the cloud, either rehydrate your mailboxes from PSTs before you move, or use the free tools from Microsoft or for pay tools from third parties to migrate PST data.
Do NOT let your users drag and drop from PST to the cloud unless you want to get nothing else done that day. You can stop PST drag and drop by implementing a regkey called "DisableCrossAccountCopy". I tested it and it works great; you can read more about it at http://blogs.technet.com/b/exchange/archive/2015/07/08/deep-sixing-pst-files.aspx.
So with all of that in mind, make sure you don't continue the madness or grow the problems worse than they are. Stop PST use immediately, ensure that users cannot do bad things with them, and ensure that between MRM policies and cheap disks, your users have enough space to save what they really need.
The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.