Introduction
In many organisations IT decision makers and IT workers want to get users involved in the migration of PST data into Enterprise Vault. They feel that by involving the users the eventual solution of having all of the data available in Enterprise Vault will be more widely accepted and lead to a good user experience. I think in some organisations, and some situations, these people are absolutely right. But from time to time this involvement sometimes just leads to problems. Problems of 'in fighting' between departments, lack of ability to make decisions because one group want one thing and another group want the opposite, and a general slow down of the whole process.
In this article I'll describe a couple of different ways of making PST migration into Enterprise Vault a reality but by performing a silent PST migration.
A 'Silent' Migration?
A silent migration usually means that end-users are not involved in the decision making, nor are they involved very much, if at all, in the overall process of migration. The PST files are located on an end-users machine, network drives, or both, they're then ingested into Enterprise Vault, and in many cases, replaced by Virtual Vault from Enterprise Vault. By using Virtual Vault in this way users are pretty much getting the same experience as they had with PSTs, but instead of having lots of PSTs attached to Outlook, or just lying on disk, they have all of the data in one place - Virtual Vault.
A Possible Solution
It is possible to perform a silent migration using Enterprise Vault's built in tools. In fact using Enterprise Vault's tools there are at least two ways that silent PST migrations can be performed.
Firstly you can use the Locate, Collect, Migrate method of PST Migration with Enterprise Vault. Using this method you run one task to locate domains, then computers, and then scan specific computers to locate actual PST files. Enterprise Vault's PST Locator task performs this function, and also helps with the process of identifying who a PST file belongs to. It's not a foolproof identification, and administrators can override any that look obvious.
Scanning remote machines especially laptop users can be tricky though. Not only is the network round-trip time a problem, but the fact that many computers might not check-in with the network that often, and when they do it might not conincide with when the locator task runs, so there is always the risk that some PSTs will just not be found, possibly for a long period of time.
After PSTs are located, and owners identified there is a simple PST Collector Task. This copies the PST files straight over the network to the PST Holding Folder, defined on the site properties of Enterprise Vault. This again suffers a little from the network bandwidth issues of the locator task, but perhaps somewhat worse than the locator. Try copying a 5 GB PST file just using regular file-copy operations over the network from an end-user machine. It can take a long time, and of course any disconnects or network issues means that the whole file will need to be transferred again. In addition if the PST file is connected to an active Outlook profile/session, then the file can't be copied because it is locked by Outlook. Tricky! Especially for 'silent' migrations where we don't want the user involved.
Once collected, the PST Migrator Task then kicks-in to actually migrate the data, and add it to the end-users archive. This is all done according to the Enterprise Vault policies, and different users can have different policies configured. Any items left in a PST file will mean that it will be copied back to the source location with the items still in it. This can be problematic with a silent migration approach. Usually to get around this you would make sure that *all* Message Classes are included, and that will usually mean that pretty much all PST files will be ingestable - well, aside from the ones that have passwords (remember just a handful of years ago it was actively encouraged to password protect PST files) and the just plain generally corrupt files (well, they end up as corrupt after copying across the network)
The second option which is perhaps in some cases better, especially when it comes to the ability to do a silent migration, is client-driven PST migration. Here the Outlook Add-in performs much of the functions. It will periodically scan a users machine, both the hard disk and the registry, in order to locate PST files. A list is built-up, and, this list is passed to the Enterprise Vault server.
There is usually less of an issue here with regards to 'mis-ownership', but it is sometimes difficult to handle PSTs that are accessed by multiple people, and PSTs on external hard drives might still be missed. Also with this approach the Enterprise Vault Directory Service needs to be able to look out and access the remote PST location, to resolve internal names and so on, and that too can pose problems because organisations (rightly) don't want to give the Vault Service Account 'god-like' permissions across all the machines on the network.
This method is good in that the PST files are broken down in to chunks which are copied up to the Enterprise Vault server using a HTTP connection, for migration. What gets migrated is again governed by policy, making it possible for an EV Administrator to say 'import the lot'.
This type of migration is also good at handling PST files which are in use. In fact it can even cope with PST files that have data added to them after migration is under way (A final sweep of the PST is made after the last chunk is uploaded and migrated).
The trouble with both of these built-in methods is that they often leave aspects of the migration down to the Enterprise Vault Administrator to sort out, and monitoring/reporting is tricky without delving into SQL yourself to get some useful reports out.
Slicker Solution
A slicker solution exists though.. in fact there are several third party products on the market which address many of these shortcomings with varying degrees of success. One of those addresses pretty much all of these shortcomings is PST FlightDeck, and it's sister product PST FlightDeck SME (specifically targeting small to medium enterprises).
With these products PST files are uploaded in the background, using a component on each workstation called the Migration Agent, and the upload process is fault tolerant to network glitches, laptop power-downs and so on - the upload just resumes where it left off. It can also get old of PST files on users external hard drives, and doesn't need any additional permissions beause it's doing it's work in the context of the end-user. Once the PST file gets to the server, the PST files are backed up before anything else is done to them - eliminating issues later where users complain of data that is missing. Passwords are instantly removed - no password cracking, just straight removal, and old-style ANSI PST files are converted to unicode.
Depending on the version of PST FlightDeck there are some other pre-processing, or pre-flight checks, that are performed, before the file is passed to Enterprise Vault for ingestion.
The files are ingested according to the normal PST file policies which are defined in Enterprise Vault.
All of this comes wrapped in a great user interface where administrators can easily see the progress of their migration, monitor resource usage, and address any issues which are encountered - and with all the pre-processing steps which are performed the number and type of issues is almost non-existent.
Summary
In summary then it can be seen that it's possible to migrate PST files from end-users without their interaction or involvement. It can be done by Enterprise Vault methods alone, but that might lead to quite a few problems, and hurdles along the way. There are several third party products, such as PST FlightDeck that dramatically improve the migration experience, and provide a much slicker 'silent' migration of PST files.
Have you performed silent migrations in your organisation? Or if you're a consultant is it an often asked-for approach to PST migrations? Let me know in the comments below...
