Eliminating PSTs with Enterprise Vault
Created: 25 Aug 2012 | Updated: 30 Aug 2012 | 1 comment
Removing PST file usage with Outlook clients has been in the forefront of Messaging Administrators minds since a year or two after the PST file was born. Early problems with reliability, and later with size constraints (and often times subsequent corruption) has led to all sorts of problems. Yet many organisations even of a relatively small size still report terabytes of PST data on their end-user workstations, and worse, on their network file servers.
In this article I will describe how you can eliminate PSTs, totally. Take a deep breath, and hold on!
The first step is stop the end-users creating (and maybe accessing) PST files. DisablePST is a registry key which exists in:
You can set the DWORD to either :
5575 - Disable option to create a PST file
5576 - Disable option to open an existing PST file
Before you set the option you will see the following when trying to open a data file in Outlook 2010:
After you set the option in the registry you will see:
It is a shame in many ways that you can't push this suggested change out with Enterprise Vault, but unfortunately you have to rely on login scripts of Group Policy.
The second registry key which many, many people set is PSTDisableGrow. It has been talked about in relation to Enterprise Vault dozens if not hundreds of different times in articles, blogs, technotes, and in the Symantec Connect forums.
The key can be set in two places :
A DWORD set to 1 to enable the restriction.
And it can be set here:
The biggest thing with implementing PSTDisableGrow is it's ability to break the whole end-user client experience of Enterprise Vault and Microsoft Outlook.
PSTDisableGrow literally stops PSTs enlarging, or shrinking in size. You can still access them, and create them, but, if you create one (the default size is 265 Kb) you then can't add any data to it, pretty much. Doesn't seem too bad until you realise that Enterprise Vault retrieves items to a temporary PST file in order to display the retrieved archived item to an end-user. Yes, that's right "Oops". With PSTDisableGrow set you will likely see errors on the screen like this:
The item could not be downloaded. [OIOM] 80070005
To try and make this more of an acceptable pill to swallow, more recent versions of the Enterprise Vault Outlook Add-in will display a warning when Outlook starts if this key is set, and it's corresponding override key is not set. This is how that screen will look:
What is that override key?
It is called PSTDisableGrowAllowAuthenticodeOverrides. Essentially it allows programmatical approaches to create, open, and extend PST files, provided they adher to a strictly defined interface spelled outby Microsoft.
This registry key can be set here:
A DWORD with the value of 1 to allow programmatic access to PST files
The Enterprise Vault Outlook Add-in DOES support this approach. With the key set appropriately, opening archived items will now work.
Outlook won't complain when it starts up, and overall things will be good in the world (again)
What About Reality?
In reality the actual order that you implement DisablePST and PSTDisableGrow will very much depend on your user population, their skills, their knowledge, their acceptance level and their cultures. It is very different imposing these sort of things on office workers in central London, to a largely manufacturing organisation based in Germany, for example.
Take care, consideration and time, especially with regards to your communication plans and user education in regards to the roll-out. It will be nearly always prove to be critical to the success and acceptance of the PST elimination that you desire.
Now you've communicated out the overall plan of stopping PST usage, and you've implemented key registry changes to stop people accessing, creating and using registry keys, the question is now : What Next?
Well now we have many, many static (ie not growing) PST files littered across corporate laptop, desktops, and file servers. We can now begin hoovering them up using a number of different techniques:
Native Enterprise Vault Tools
Obviously built in to Enterprise Vault are server driven locate and migrate, as well as client driven PST migration methods. These allow simple but flexible approaches to absorbing those countless PSTs that are distributed across the network.
Many people ask which option to choose and sometimes there is a clear cut favourite between the server driven approach and the client driven approach. Sometimes it's not so clear cut. It is worth investigating whether users are mostly mobile, laptop based and whether they are frequently using poor connections back to the corporate network. These would favour client driven.
If it is mostly corporate desktop machines, or laptops which are office based, with some home working then often server driven locate, collect, and migrate is the favourite.
In many cases it is a mixture of the two that ends up needing to be used in order to get those remaining, remote PST files.
Each of the built in Enterprise Vault options don't particularly excel at user feedback, which can often be a problem in corporate PST migrations. So an alternative is :
Third Party Migration Tools
Companies like QUADROtech have leapt on to some of the deficiencies in the built-in Enterprise Vault tools for PST migrations. They have developed a comprehensive tool with good workflow, communication and reporting. Tools such as this can greatly enhance the overall ingestion procedure, and they keep the end-user in the loop throughout the process.
As you can see with some thought, planning, and assistance from third party companies it is a realistic possibility that you can eliminate PST files in your organisation. It won't be an overnight task to remove them from your file servers, or your end user workstations, but there are steps that you can do straightaway to make inroads on something that messaging administrators have been trying to remove from systems since the day they were 'invented'.