Skip navigation

Moving Away from PSTs

Be proactive about planning and managing a transition away from PSTs

PST Migration Products
MailMover
Simpler-Webb, http://www.swinc.com/products/mailmover
PST Policy Administrator
Sherpa Software, http://www.sherpasoftware.com/pstoverview.shtml
Symantec Enterprise Vault
Symantec, http://www.symantec.com/enterprise/products/overview.jsp? pcid=1018&pvid=322_1&src=symsug_us
Transend Migrator
Transend, http://www.transend.com/products_transend_migrator.asp

Personal folder files (PSTs—files with the .pst extension) provide a means of storing data such as mail messages and calendar events in a way that makes the data accessible through Microsoft Office Outlook. Users typically use PSTs to compensate for storage quotas on an Exchange server. Because users can’t store all their messages on an Exchange server indefinitely, they'll often move most of their messages to PSTs that are stored locally instead. Although PSTs are convenient, they also have drawbacks that might cause you to consider gradually eliminating them from your Exchange organization.

Why Phase Out PSTs?


PSTs are fully supported in Microsoft Office Outlook 2007, so you might be wondering why you should bother eliminating them from your organization. The simple answer is that widespread use of PSTs often results in data loss and excessive overhead. PSTs definitely have their place; I'd be lying if I said that PSTs hadn’t gotten me out of a few jams over the years. For example, many years ago I was called in to help an organization after an Exchange server had crashed. The backup couldn't be restored because it was corrupt. Fortunately, most of the users had configured Outlook to deposit all their messages into PSTs. Although it wasn't the most graceful solution to the problem, I was able to use these PSTs to recover most of the data that had been lost. But despite PSTs' potential value as a backup repository for users' email, I believe that the use of PSTs is problematic for several reasons.

Microsoft originally created PSTs as a way of giving users a copy of their data that wasn't bound to an Exchange server. PSTs can store messages on a workstation or laptop hard disk, so that those messages are accessible even when the user isn't connected to the Exchange server. However, using PSTs for offline storage isn’t necessary in most cases. You can configure Microsoft Office Outlook 2003 to automatically cache messages to an offline folders file (OST). OSTs are more secure than PSTs because they work only with the Outlook profile that created them.

By their very nature, PSTs are susceptible to data loss. PSTs were designed to store users’ data on workstation or laptop hard disks, which typically aren't backed up. Therefore, any data on these disks could be lost if the disk fails.

Of course, you don’t have to store PSTs on a hard disk. PSTs can reside on a network share, which you can configure Outlook to access. However, Microsoft discourages this practice. According to the Microsoft article "Personal folder files are unsupported over a LAN or over a WAN link," (http://support.microsoft.com/?kbid=297019), accessing a PST over a network link degrades performance and runs the risk of corrupting the file if the link fails.

Email-retention requirements are another reason I recommend phasing out PSTs. In the post-Enron world, the US federal government has created several pieces of legislation mandating security and document-retention practices for various types of companies. If your company is required to retain email messages, allowing users to store messages in PSTs is a bad idea.

Obviously, if the PST is located on a user’s hard disk, you run the risk of losing data that you're required to keep. But there’s more to it than that. Imagine, for example, that the law requires you to keep email messages for 10 years. Now imagine that nine years from now your company is audited and subpoenaed to produce all email messages from the year 2006. If your users are using PSTs today, you’ll have problems complying with the subpoena even if by some miracle no data has been lost.

The first problem is locating all the data. Users’ PSTs are likely to be scattered all over the network, and each PST probably contains data from multiple years. Another problem you might face is incompatibility. Pretend, for example, that you put a bunch of messages into a .pst file today, burned the file to a DVD, and locked the DVD away in a safe-deposit box. What are the odds that the file will still be usable when you need it? In 10 years, DVD drives might be as obsolete as 5.25” floppy drives are today. More importantly, though, in 10 years Outlook might not support PSTs or the PST format might have radically changed, meaning that you won't be able to import the now-ancient PST archive. However, you can avoid all these problems by importing the contents of users’ PSTs into your Exchange server message store, then using your email-archiving software to archive older data as necessary.

Phasing Out PSTs


There's no easy way to phase out PSTs because Microsoft doesn’t provide tools for centrally managing them. Your best solution to the PST problem, if you don't want to use a third-party PST-management product, is to use Group Policy to restrict users from using PSTs. However, you can’t just create a Group Policy Object (GPO) to prevent users from opening PSTs. First, there’s no such GPO setting. Second, if you suddenly block access to PSTs, users won't be able to access the data contained in the files they're already using.

One way you could handle the process is to tell users that PSTs will be eliminated after a set period—say, 60 days—and that it's their responsibility to move their PST data into their Exchange mailboxes. You might need to suspend mailbox quotas temporarily so that the PST data can be imported. You could immediately set a GPO that prevents users from placing additional data into PSTs: This policy should show users that you're serious and motivate them to move their data. When the 60 days are up, you can take additional measures to prohibit PST use.

By default, Windows doesn't include GPOs that can restrict the use of PSTs. However, Microsoft makes an Administrative Template for Outlook 2003 that can control PST use. The template is included in the Office 2003 Service Pack 2 Administrative Template (ADM), OPAs, and Explain Text Update (http://www.microsoft.com/downloads/details.aspx?familyid=ba8bc720-edc2-479b-b115-5abb70b3f490).

After you download and extract the new files, start Group Policy Editor (GPE) and load the policy that you want to add PST restrictions to. Navigate through the GPE console tree to User Configuration\Administrative Templates. Right click the Administrative Templates container and select Add/Remove Templates from the shortcut menu. You should see a list of the current policy templates. Click Add, then navigate to the folder where you extracted the new templates. Select the Outlk11.adm file, then click Open, followed by Close.

After the template is loaded, you can access the PST-related settings by navigating through GPE to User Configuration\Administrative Templates\Microsoft Office Outlook 2003\Miscellaneous\PST Settings. As Figure 1 shows, the Outlook 2003 Administrative Template contains several PST-related settings.

This template makes a distinction between legacy PSTs (the file format used by Outlook 2002 and earlier) and large PSTs (the file format introduced with Outlook 2003, which has a size limit of 20GB). If you use Group Policy to impose a restriction on PSTs, you should apply the restriction to both types of PSTs unless all users are on Outlook 2002 or earlier. Even if all your users are running Outlook 2003, legacy PSTs still might be in use.

I recommend using the Size to disable adding new content setting to restrict the growth of large and legacy PSTs. Keep in mind, though, that this restriction will also affect OST files. Therefore, you might have to disable Outlook caching until you've finished phasing out PSTs.

In GPE, double-click the appropriate GPO setting (i.e., depending on whether you want to restrict large or legacy PSTs or both), and you'll see a dialog box similar to the one that Figure 2 shows. This policy setting lets you prevent content from being added to PSTs after the file reaches a certain size. Theoretically, you can set the size limit anywhere between 0MB and 4,294,967,295MB; however, a glitch in the Administrative Template makes 1MB the actual lowest limit you can set. The 1MB low-end limit probably won’t cause a problem, though, because almost any user who's actively using PSTs will have more than 1MB of data in his or her PSTs.

Getting Rid of PSTs Altogether


Preventing users from adding to their existing files is a great way to discourage them from continuing to rely on PSTs. But eventually you'll want to get rid of PSTs completely. You’ll notice in Figure 1 that the Outlook 2003 Administrative Template provides no GPO that can prevent the use of PSTs. But you have a couple of options for getting around this limitation.

One option to prevent PST use is to lock down Outlook’s UI so that users can't create or open PSTs. To do so, navigate through GPE to User Configuration\Administrative Templates\Microsoft Office Outlook 2003\Disable items in user interface\Custom, as Figure 3 shows. Select the Custom container, then double-click Disable command bar buttons and menu items to open the dialog box that Figure 4 shows. Click Enabled, then Show to view the Show Contents dialog box that Figure 5 shows. Click Add, enter the number 5575 into the place provided, and click OK. Repeat these steps and enter the number 5576. These numbers create the necessary policy settings: 5575 prevents users from creating PSTs, and 5576 prevents users from opening PSTs.

You'll probably also want to disable automatic archiving because the Auto Archive feature works by placing archived items into a PST. You can find a GPO for disabling automatic archiving at User Configuration\Administrative Templates\Microsoft Office Outlook 2003\Tools | Options\Other\AutoArchive.

Another option to prevent PST use is to edit the Windows registry to disable PSTs. For this technique to work, though, you must have Microsoft Office 2003 Service Pack 2 (SP2) installed. Before I describe how this technique works, I should mention that editing the registry is dangerous. Making an incorrect registry modification can destroy Windows and your applications. I therefore recommend making a full system backup before continuing.

With that said, open the registry editor (regedit.exe) and navigate to the HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook subkey. Now, create a new DWORD value named DisablePST and assign it a value of 1, as Figure 6 shows. If you use profiles, you'll also have to navigate to the HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\11.0\Outlook subkey, again create a new DWORD value named DisablePST, and assign it a value of 1. (For information on possible side effects of the DisablePST setting, see the Web-exclusive articles "Dealing with .pst Files," November 2003, InstantDoc ID 40961 and "Outlook Year in Review 2005," December 2005, InstantDoc ID 48920 and the Microsoft article "You receive an 'An error occurred adding the following Windows SharePoint Services folder to Outlook' error message when you link a Windows SharePoint Services Calendar or Events list to Outlook 2003" at http://support.microsoft.com/?kbid=897658.)

PST Migration Challenges


Unfortunately, migrating PSTs to Exchange mailboxes isn't simple; quite a few things can go wrong. Probably the most obvious problem is that some users won't know how to do so, although it's a simple drag-and-drop procedure. Other users won't take you seriously and won't bother to migrate their data.

Another problem is that a PST migration will consume an undetermined amount of disk space on your Exchange server. Unless you have a tool to search for all PSTs across your network, you won't know exactly how much data will be migrated. Depending on how PSTs are used in your organization, you might also have duplicate messages. For example, a user’s PST might include messages that are already in the user’s Exchange mailbox.

You can overcome these problems by using third-party migration software. Every product works differently, but generally third-party solutions automatically search your network for PSTs, determine which messages are duplicates, and automate the migration process. Such software can also help you figure out how much data will be imported into your Exchange server before the actual migration. See the PST Migration Solutions box for a list of some products that have PST-migration or reporting capabilities built in.

It’s worth mentioning that Microsoft offers a PST migration tool of its own, Microsoft Exchange Server Mailbox Merge Wizard (ExMerge). However, I recommend using a third-party migration tool instead of ExMerge. Not only is ExMerge a little messy to use, but also it doesn't support large PSTs (see the Microsoft article "Error message when you use the ExMerge tool to export an Outlook 2003 mailbox to a .pst file: 'The item could not be moved'" at http://support.microsoft.com/?kbid=916085). When shopping for a PST-migration tool, you should look for a product that's easy to use. The tool should also support both large and legacy PSTs and be able to handle password-protected PSTs. Ideally, the utility that you select shouldn't be limited to migrating items within the PST; it should also be able to migrate custom views.

Although Microsoft will support PSTs for many years to come—at least until the end of life cycle for Outlook 2007—there are many reasons to begin phasing out PSTs today. However, except in very small organizations, ridding your network of PSTs will be a challenge without the aid of third-party software. Nevertheless, now is a good time to take stock of your users' PST habits and take the first steps toward a PST-free environment.

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish