Even more reasons to stop using PSTs

burningserverThe other day I came in on the tail end of a conversation involving PSTs. The thought was to archive some former employees’ email into PST files, store them on the network, and let HR access them as needed. I waited for my turn to contribute to the discussion, and led in with “sure, and then we can roast marsh mallows over the burning server.” To say the reaction was underwhelming just doesn’t quite paint the picture. The silence was deafening. It seems that not everyone understands that PSTs are evil. Today, I hope to help fix that.

In a post earlier this year, my colleague Paul Cunningham discussed some options for “What to do With Those PST Files.” His article gives you some great alternatives to storing mail in PSTs. What I would like to do in this article is build upon that by giving you some of the reasons why you want to move away from PSTs.

I have encountered many situations where a company seems to have adopted a policy of network stored PSTs as the alternative to larger mailboxes. Whether it was to reduce the size of the information store, or simply because Exchange was deployed with smaller mailboxes in mind, the PST seems to be the logical place to store email that doesn’t have to be available online. And since storing a PST on a local hard drive puts that data at risk, most folks tend to move those PSTs over to a network share, like their home directory, so that they get backed up each night. This is a case of “good idea, bad reality.” To understand why, let’s consider the humble little PST.

The PST has been around, largely unchanged, since Exchange 4. It was designed as a short term storage solution, or for mail pulled from an Exchange server by “Internet Mail Only” mode users. The PST file is accessed by Outlook using a file-access-driven method built for local storage. This loosely parallels some virtual disk formats, where the single file holds a significant number of discrete binaries that may need to be accessed randomly. Outlook’s file-access-driven I/O does not work across network connections, so when a PST file is stored on a network drive, the access requests must be encapsulated in serial RPC calls, sent across the network, and then processed by the file server.

There are some significant challenges to performance when doing this. First, these RPC calls are serial, meaning they are processed one at a time, and one must complete before the next can commence. Secondly, the fileserver can exhaust both paged and non-paged pool memory to handle these requests, and may become unresponsive to other requests, recording events 2021 and 2022. These two limitations can lead to significant network performance issues as more and more users begin to store PSTs on the same fileserver. First, the server’s NPP will start to become exhausted. Second, response times will increase to the point where the server appears to be non-responsive for noticeable periods of time.

The performance impact of this is so severe, that Microsoft has published a knowledge base article specifically stating that Personal folder files are unsupported over a LAN or over a WAN link. Consider the significance of that. You cannot find a KB that states running a Quake server on your SQL server is not supported. You cannot find a KB that states running a public facing website on your domain controller is not supported. You can’t even find a KB article stating that defenestrating your Vista machine is not supported (no matter how good an idea that might seem to be,) but there is a KB telling you directly NOT to use PSTs over the network; it’s that big a problem. If you consult that KB, you will see that it has been updated and applies to every version of operating system through 2008.

If you are already in the situation of having PSTs on the network, what can you do? With Exchange 2010, the initial performance limitations from earlier versions of Exchange are gone, so as Paul mentioned in his article, moving the data back to the Inbox is a good way to go. In addition to the indexing, archiving, and discovery benefits he mentioned, my favourite plus is that the email will be available to users when they use OWA. I’ve gotten several calls in years past from remote users who need to get to an email stored in some archive. Additionally, Microsoft opened up the format of the PST file last year, and the market is starting to see third party tools to migrate data. If you have no choice but to keep data on PSTs for now, consider moving them back to the client for real time access, and replicating them to a file share strictly for backup. As long as the access remains local to the client, the adverse impact to the fileserver is not there. This is still not a recommended approach for long term use, but it is far better than accessing PSTs over the network.

Written by Ed Fisher

An InfoTech professional, aficionado of capsaicin, and Coffea canephora (but not together,) I’ve been getting my geek on full-time since 1993, and have worked with information technology in some capacity since 1986. Stated simply, if you need to get information securely from a to b, I’m your guy. I’m like "The Transporter," but for data, and without the car. And with a little more hair.

Leave A Reply