Being involved in a PST Migration is something that messaging administrators are getting involved in more and more often. The migration is not always to Enterprise Vault, but there is always a seemingly endless list of things that need to be considered especially if you are performing the migration in an organisation that spans different countries. This is sometimes because of different laws in different countries, but is usually simply because of different cultures. Spanning timezones and international boundaries are other problems, never mind trying to figure out how much of a PST-estate you have to migrate.
In this article I'll explain one of the very important aspects of any migration. What I will explain is the possible ways to go about figuring out how many PST files exist in an environment and how much space they consume. Hopefully this will be useful to an individual end customer, who would only need to perform the migration once, and also to consultants who might work for several customers over time, performing multiple migrations. Those consultants will get the chance to fine tune some of the information that I will describe in this article.
PST files get everywhere! End-users store them on their laptop, their desktop, their home folder, shared folders on the network, USB drives, and maybe even CDs or DVDs. In fact people love them so much they probably have multiple copies of them, spread across one or more different locations, and perhaps even on different media (eg laptop and external drives). They turn up everywhere, and those multiple copies really can cause problems, and of course skew storage calculations slightly. Some of the PST files might truly not be needed by users any more - they might not even know that they still have them.
So how do you solve the problem of finding out where all these PST files are, how big they are, and track the ownership of them? There are a myriad of possibilities and often side-parts of different products have ways and means of scanning for files of particular type, or file extension and producing reports on what they find.
Manual and scripting
If you don't have a software deployment tool that can scan for files of particular extension, then you can always roll your own via a script to run at login, or even run remotely depending how adventurous you are with scripting. Usually you'd gather all this data back in to some sort of CSV file ready to go into Excel or similar so that you can slice and dice the results, summarise, extrapolate and eventually calculate or guestimate a value for the total size and total quantity of PST files in the environment.
Doing this via scripting is one way of semi-automating the capture of the information relating to PSTs. Of course the best way to gather all of this data is to have some properly automated capture - and analysis too. One of the great new features of PST FlightDeck by QUADROtech, is that you can deploy the server side, ie the FlightDeck server, and rollout a small MSI to each workstation, called the Migration Agent, and that agent will report back PST file size, locations, and ownership information.
Once that information starts to return to the server, you can then begin the process of analysing it and work out things like:
'Who has the most PST files?'
'Who has more than 10 PST files?'
'Who has PST files totalling over 15 GB?'
... and so on. The small migration agent is a powerful tool because it can scan local drives, network drives, and even removable storage devices.. looking for PST files belonging to a user. It runs outside of Outlook, which gives it some advantages over the client-driven migration that is built in to the Enterprise Vault Outlook Add-in. In fact, it doesn't even have to eventually lead to ingesting data in to Enterprise Vault at all (Enterprise Vault is by far the most common target though!) - the target for the migration can be things like Exchange 2010 Personal Archives, or Office 365, and other destinations which are currently being developed.
There are other tools and products that can also assist with automating this data capture, and review, so it is definitely worth exploring the different options which are available. You should way up the costs of using a full-blown solution like FlightDeck compared with trying to gather some of the statistics manually, via software deployment tools, or via scripting.
As you can see getting a handle on the size, and number of PST files in a PST migration project is key to understanding whether the target of the migration can cope with the influx of data. It is not just down to the time it takes to ingest that data in to the target it's the long term ability for the target to be handle that data, have it backed up regularly, and have the data readily searchable and accessible for retrievals. Knowing the size and quantity of PST files allows for a smoother migration, and allows for secondary work to be performed on the underlying infrastructure to support the long term storage. Gathering this data quickly and accurately is essential to the success of the migration, whatever the target for the PST data.
How have you sized your PST migration? If you're a consultant have you adapted any strategies and reused them between customers, or have you started from a blank sheet of paper each time?