Four Ways to Collect PST Files
Created: 04 Apr 2013 | Updated: 06 Sep 2013 | 2 comments
Organisations have many options available to them when it comes to finding and collecting end-user PST files ready for ingesting into Enterprise Vault or Exchange 2010 Personal Archives. Each of the products and tools available have pro's and con's, so making the decision of which to choose can be quite difficult for a company. Many of the products also have their own associated costs, such as training needs, consultancy time and so on. In this article I'll describe a few of the big players in this area (it's not an exhaustive list) and I'll offer you an example of a 'new kid on the block', and that might surprise you a little!
Enterprise Vault Locate/Collect/Migrate
If you're migrating PST files to Enterprise Vault then the first tool of choice might be the in-product feature Locate/Collect/Migrate. As the name implies this essentially covers a three step process:
During this phase an Enterprise Vault process will discover Active Directory Domains in your environment, and then computers (laptops and workstations) by contacting each machine found in the Active Directory Domain of your choice. It can take quite some time to scan hundreds of thousands of computers, but does yield good results. You then move on the next stage of actually scanning the machines to locate PST files, and whilst there might be a bit of manual intervention needed the process also attempts to indicate the owner of the PST file using several different criteria.
The collection process is usually relatively straight forward and and involves copying the PST files to a holding area ready to process. Of course to stop the deluge of files that might land in that area Enterprise Vault allows you to limit the number of files that can go in to the Holding Area. One thing to note is that the Holding Area is a site wide setting, and you can specify an overall size limit. It being a site wide setting means you have to make sure that the location is well connected from a networking point of view because if you have multiple migration tasks in the environment then they will all be pulling data from this location.
The migration part of the process simply churns through the PST files and ingests them in to Enterprise Vault according to the PST policy. It's worth noting that if you have opted to create shortcuts to the ingested items then they are first created in the PST file itself (this in part, is the reason why some migrations fail) and at the end of the migration they are copied in to the mailbox in the appropriate location (again defined by the PST migration policy)
For many scenarios, environments and organisations this process is pretty good, and does the majority of the work. There are issues though, mainly:
* Password protected PST files. These are a pain to handle in the Locate/Collect/Migrate process - you have to get the user to tell you the password, and it has to be stored in the entry for the PST file. This is often hard to do/get because the user might be unwilling to give out the password.
* ANSI PST files fail. ANSI PST files are usually very, very, old. In some ways it's a wonder they're not corrupt before the ingest process takes hold, but believe or not, sometimes they get as far as ingestion, and then fail. This is sometimes related to the size limit of the file, 2 Gb. Files close to this when the migration process starts can be tipped over the age by the creation of the shortcuts - and that will lead the migration of that file to fail.
QUADROtech PST FlightDeck
One of the biggest products available on the market right now is PST FlightDeck from QUADROtech. This offers many of the features of the Enterprise Vault Locate/Collect/Migrate approach and also a huge list of other features. It contains a number of modules for handling the migration of PSTs in a much smoother flow, and has a password remover module which instantly removes PST file passwords, and an ANSI -> Unicode converter module to get around the issues that are often seen with ANSI PST files. PST FlightDeck also has great reporting built in, so it's easy to see how far through the migration has progressed.
Another huge product on the market right now is PST Accelerator from PSTAccelerator. This too offers many features over and above the ones included in Enterprise Vault. Like PST FlightDeck this handles PST file processing in a much better way than Enterprise Vault and it has a great module for discovering PST files over wide area networks.
Exchange PST Capture Tool
At the beginning of the article I promised you a 'new kid on the block' and this is it. There is actually a Microsoft tool available which can be used for many different PST migration scenarios, and is well worth investigating to see if it will suit your migration needs. It too searches for PST files on end user workstations and consolidates them to a central location. From there the PSTs can be ingested into either a regular Exchange mailbox or archive mailboxes, and it can go into on-premise Exchange environments or Exchange Online mailboxes. The simplicity, and perhaps the power of this tool lies in the fact that it is a server-side 11 Mb download, and a client side 632 Kb download. It's super-small. The two download components provide three pieces of functionality:
* Capture Central Service - this maintains the list of PST files found in the organisation and manages the data through the migration process
* Capture Agent - this is installed on end-user workstations and looks for PST files. It reports its findings to the Central Service
* Capture Console - enables you to manage the migration. This tool also allows you to ingest PSTs from network attached storage, file shares on servers, and so on.
More information about the tool can be found here: http://blogs.technet.com/b/exchange/archive/2013/02/22/time-to-go-pst-hunting-with-the-new-pst-capture-2-0.aspx
As you can see there are actually quite a few options available when it comes to managing any organisation wide PST migration project. Which you choose can come down to a number of factors including complexity, requirements, and cost. It's worth weighing up these different options, and others, before taking the plunge and starting the migration project.
Have you used any of these approaches? Let me know in the comments.