Love them or hate them, PSTs (Personal STores) have been with Exchange Administrators for a long time. PSTs have traditionally been used to move information out of an Exchange mailbox database. This has allowed users, who may have relatively low mailbox size quotas, to keep any amount of information that they want.
On the positive side, this assists the Exchange administrator (and the Backup administrator) to have smaller backups and smaller Exchange mailbox databases. Those are about the only positives.
On the negative side, we have a much longer list:
- PSTs are not supported on a network drive
- Backing up PSTs on user computers is challenging
- Once information is in a PST, it is no longer available for organization-wide discovery
- Once information is in a PST, it is no longer subject to any compliance regulations
- Searching information in a PST is difficult (and slow) for the end-user
- Managing PSTs manually is prone to error.
There are others.
Note: Many companies report success with using PSTs on a network drive. However, it is not now and never has been supported. See http://support.microsoft.com/kb/297019. For information on how putting PSTs on a network drive can cause corruption of those files and destroy the performance of your network and your file servers, see http://blogs.technet.com/b/askperf/archive/2007/01/21/network-stored-pst-files-don-t-do-it.aspx.
So what should a company do?
In general, I recommend that companies should not allow the creation of any new PSTs. And, over time, all PSTs should be imported into the Exchange mailbox databases. Of course, the first step in this process is to migrate to Exchange Server 2010.
To explain further: in Exchange Server 2003 and before, Exchange Standard Edition had fairly severe limits as to the allowed size of a mailbox database (at original release, it was 16 GB; by service pack 2, that number had been increased to 75 GB). As of Exchange Server 2007, there were no longer any limits on database size in Exchange Standard Edition. However, in Exchange Server 2007, it was still recommended that organizations put mailbox databases on “expensive disk”. That is, mailbox databases and their log files should be located on enterprise-class disk in either a SAN configuration or a RAID configuration. And that disk should be fast.
With the release of Exchange Server 2010 and the Database Availability Group (DAG), that overall recommendation has changed. Exchange Server 2010 works quite well on JBOD (Just a Bunch Of Disks). This means that the Exchange administrator can now use inexpensive SATA disks, which are currently available up to 2 TB in size.
This does NOT mean that you should ignore data safety. Microsoft recommends that you have at least three copies of your data. If you are using a DAG, that would be two online copies plus a lagged copy. If you are not using a DAG, you should still use RAID on those SATA drives and be doing regular backups. Obviously, there are many other options too.
Regardless of which option you choose, the capability of having excellent mailbox performance on slow inexpensive disk means that you and your users no longer have any need for PSTs. The Exchange administrator can greatly increase mailbox quotas and do so quite inexpensively.
There is also another consideration that may come into play: Exchange Server 2010 introduced the concept of a personal archive (that is, a separate mailbox “attached” to a user’s primary mailbox that is used to store older information). In Exchange Server 2010 service pack 1, the archive mailbox can be, for example, placed on slow disk and you could keep primary mailboxes on fast disk.
Finally, locating and importing PSTs can be manually intensive. While Exchange Server 2010 has some capabilities in that area (and they are improved in service pack 1), organizations may want to examine what options are available from third parties.
Articles that may interest you:
Last reviewed on Aug 24, 2011
Hot Topics