Video Screencast Help

Four Ways to Collect PST Files

Created: 04 Apr 2013 • Updated: 06 Sep 2013 | 2 comments
Language Translations
Rob.Wilcox's picture
+1 1 Vote
Login to vote

 

Introduction

 
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

Screen Shot 2013-04-04 at 08.55.28_0.png
 
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:
 

Locate

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.
 

Collect

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.
 

Migrate

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

fd_01_0.png
 
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.
 
 

PSTAccelerator

 
 
id1703_0.jpg
 
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.
 
 
 

Summary

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.

Comments 2 CommentsJump to latest comment

AKL's picture

Thanks for the cool blog and centralized information Rob !

I've been running a large enterprise PST migration project in our environment using way 1 - Enterprise vault native migration methods. I am using Server & Client Driven migration process in parallel so we do not miss any files.

Only pain point are:

  • ANSI files which have to be converted into Unicode file manually
  • some large corrupted files or some corrupted data withihn which needs to be recreated manually again
  • certain corrupt files which needs scanPST.exe run against them before they can be migrated.

Password based files are not much bothering if you've PSTPassword.exe, you can copy paste password into EV and it'll be able to migrate them without any issue.

We were looking into Exchange way of migration as well but we didn't want:

  1. TBs worth of data in our exchange databases which then will be archved by enterprise vault slowly.
  2. Push separate client for PST migration to all workstations.

Apart from same, I am sure way 2 - quadrotech & transvault are optimal solution for large scale migrations provided your organization is willing to spend on licensing (my organization didn't :S)

Thank You

AKL

0
Login to vote
Rob.Wilcox's picture

Thanks for the comments, it's very interesting to read more 'real world' experiences.

0
Login to vote