One of the topics that is often discussed in relation to PST migration is whether it is better to have an agent or agent-less technology to assist with the migration. In this article I'll describe some of the ways in which you can decide which is best for your environment.
Finding PSTs
A large part of the PST problem is finding all the PST files in any given environment. Using an agent-less approach, from a central server, it would need to remotely connect to every single machine connected to the domain (and even the whole forest) and look for PSTs. This is enormously expensive in terms of network resources, and, more to the point the privileges/permissions needed are often ones that companies just do not use (or can not allow to be used, with privacy laws in some countries).
Deploying an agent makes this an easier to task, at least in terms of locating all the PST files on a given end-user workstation. It can be a trickier task to locate ones on server farms like Citrix, and other virtualised desktop environments. It is also trickier to find ones hosted on file servers. An approach that is sometimes taken is that a different type of agent is used to scan the file servers (or server farms), or, the end-user agent can be crafted so that it can do the task, or, sometimes these types of machine are scanned 'manually' by a centralised application. Usually finding PST files on server class machines is relatively easy because there are few machines to touch, but of course there is a vast amount of data.
Accessing PSTs
Of course discovering these PSTs is only part of the battle - almost anyone can *find* the files, but you then need the appropriate access rights to open the PSTs and read the content of them. Again in agent-less approach this is going to require a very high level of privileges, whereas in an agent-based approach, running in the context of an end-user, it means that if the end-user can access the file, so can the agent.
It seems like such a simple idea, but it really does work. So long as the agent is running under the login credentials of the given end-user it will (or should) be able to access any file that the end-user can. This simplifies the permissions, and means that network and domain administrators can have a big sigh of relief, since they don't have to create an account that has access to *everything*.
Involving end-users and providing feedback
When PST migrations begin an agent-less approach has limited means of communicating what is happening with end-users. Often times this will take the form of an email to the user saying that PST migration will begin on a particular day, or at a particular time, but this communication isn't 'real time'. Usually nothing is triggered to show the user the migration is beginning 'right now'. This is all possible with an agent-based approach, in fact the agent can be crafted such that it can simply accept remote commands, and silently perform it's tasks, or it could receive commands that tell it to interact with users. Perhaps the agent will provide a list of PST files asking the user what they want to do with each of them, perhaps the agent will give feedback on the upload progress of each of the PST files, and that's just a couple of things that an agent can do quite easily.
Another important aspect is lessening the impact on end-users usage of their machine, and their network resources. An agent-less approach can't really do anything other than copy the data from the source end-user workstation to the central location, over the network. It's difficult to make this bandwidth aware, and resumable. An agent-based approach can do this much more easily, allowing for pausing of uploads if needed.
At the end of the migration the agent-less approach is back on-board sending a simple email to each end-user informing them that the data in their PSTs has been migrated. This might be sufficient for many users, but it's not as immediate and helpful as the feedback that an agent-based approach can provide.
Enterprise Vault and Others
Enterprise Vault, I think, sits on the fence with agent versus agent-less approaches to PST migration. On the one hand there is the server driven Locate, Collect, Migrate method, which is fully agent-less. On the other hand is the PST Client Driven Migration which uses functionality which has been built in to the Enterprise Vault Outlook Add-in. Using these tools gives you some flexibility but neither is fully enterprise-ready when it comes to customisation and flexibility.
Third party applications, like PST FlightDeck from QUADROtech, have an agent-based approach which has been fine tuned to meet the needs of many PST migration scenarios, and on top of that is very customisable. The agent-based approach serves the product well, but for those companies that want to do the migration without user involvement, the agent can stay 'quiet' but still makes use of things like resumable, bandwidth-aware uploads.
Conclusion
We, at QUADROtech, strongly believe an agent based approach is best for streamlining a PST migration. It has many advantages over an agent-less approach. The small size of an agent to be deployed on every workstation seems a very small price to pay in terms of the power and flexibility that the agent provides. In the end whichever approach you take be it agent-based, agent-less, or a hybrid combination of the two, hopefully this article will have given you pause for thought on some of the topics that need to be addressed to make your PST migration a success.
Which do you think is best for your PST migration? Let me know in the comments below...
