I have to admit that I like the Enterprise Vault Client Driven PST Migration method. There are plenty of things which can be done to improve it, but right off the bat, it does a pretty decent job of getting PSTs up to the Enterprise Vault server, from client machines.
To use it effectively there are a number of things to think about:
* PST Migration Policy
Review or create new ones in the VAC and assign them to users.
Also as part of this decide whether you are going to use the template mail EnablePSTMigrationMessage.msg. This can be sent to end users when you enable them for client driven PST migration.
* Location of PSTs
Hopefully the end users are storing their Outlook connected PSTs locally on their machine. Client driven migration can scan the whole end-user workstation, or just look under the ‘Documents and Settings’ folder for the user, when it runs.
(See caveat below for network connected PSTs)
* Ideal if end users need access to PSTs
The way that Client Driven migration works is that chunks of data (by default 10 Mb) are sent from the PST to the EV server for archiving. Items are added to a temporary PST file until the 10 Mb is reached, the file is compressed, and then sent in a HTTP POST to the server. The end users can continue to access the PST whilst this is happening.
A reconciling operation takes place at the end of the chunks of data to capture any additional changes to the PST
* Good way of phasing PST ingest
Individual users can be enabled, so you can pick (for example) all of the people in a particular department. These would get enabled using the Wizard in the VAC, and migrations can then begin.
* Good for roaming users
Users who don’t frequently connect to the network are hard to migrate. Client Driven PST Migration is about the best way to pick up those types of users, since the Outlook Add-in communicates with the EV server to check for ‘work to do’ periodically. When the users are remote, it won’t perform any work, when they connect to the network, work can begin and/or resume from where it left off.
* Usually no permissions required on machines
With server driven migration (locate, collect, migrate) an account needs to be used which has access to all of the remote machines to scan the drives, and scan the registry and so on. With client driven migration so long as the PST files are stored on users workstations, the Vault Service Account doesn’t need any permissions to those machines.
Caveat: Network connected PSTs
If end users are storing PSTs connected to Outlook on network drives, even though the migration using Client Driven PST Migration is taking place on the client, the EV server, or specifically the account running the Directory Service, needs to have administrative access to the remote network location. If the PSTs connected to Outlook are stored locally on the users workstation, then the Vault Service Account doesn’t need any permissions on the workstation. It is only if the PSTs are connected to Outlook and on remote machines.