Something that comes up in every PST Migration is the issue of ensuring that PST files are located everywhere that users might be using them. In this article I'll describe some different techniques which can be used to find PST files across the whole IT-organisation.
EV Server Driven - Locate, Collect, Migrate
The first and possibly the easiest sounding approach is to use Enterprise Vaults Server Driven PST Migration tools. These locate, collect and then migrate the PST data, as the title implies. Locating the data here starts with a scan of Active Directory and each computer object is queried, from the Enterprise Vault server, to figure out the physical drives on the machine. These drives are eventually scanned for PST files. This scanning can take quite some time, especially considering the default mode of operation is that the machines are first checked to see if they are a NetApp filer. Of course another problem is waiting for the poll of a machine to timeout - this is for machine which are in Active Directory, but are not currently connected to the network.
Recent improvements in this approach mean that the bulk load of machines is now supported, which helps somewhat with the initial listing of machines to scan.
One of the difficulties with this approach is that sometimes it is 'catching' users online during one of the scan operations. If the machine is offline, then it won't be scanned. It isn't something that will then be done the next time the machine does come online - it is just something that administrators need to re-run and hope that they catch more users this time around. It might be that a few iterations are needed and I imagine there will still be a percentage of users/workstations that might be missed out.
Possibly the biggest drawback of this approach though is that a super-super-user is needed to be able to scan every single machine in an environment. Many customers just won't allow an account to be used in that manner. In fact in some organisations laws may prevent it, never mind IT policies.
EV Client Driven
One of the alternatives if migrating in to Enterprise Vault is to use the Enterprise Vault Outlook Add-in to do some of the leg work for you. The Outlook Add-in can look for PSTs, and migrate them using Client Driven PST Migration. At first glance this would appear to be good as it will be running in the context of the user. However, some long standing issues have proved that this doesn't work for certain types of PST storage location, for example DFS network shares, and, in the end the EV servers Vault Service Account still needs to be 'resolve' these paths, and that in itself is troublesome.
Custom Scripts
Some customers resort to custom scripts pushed out in a login script or via a Group Policy. These can be quite good, but suffer the problem of not being particularly 'enterprise ready' or capable of handling obscure situations which are found in many Enterprise environments. At the very least they can sometimes be used to just judge the scale of the PST problem across an organisation, giving a 'good idea' of the number and size of PST files per user. Different flavours of Outlook in different languages can often lead to tricky parts of scripting though in order to be able to handle all the different possibilities, and it might be a few iterations of any potential script before the full picture is understood.
Third Party Options
Many Enterprise Vault administrators and consultants will be familiar with a number of PST Migration products and tools which can be purchased and add value to a PST Migration either to Enterprise Vault or another target environment. Some of these PST migration products, like PST FlightDeck from QUADROtech do a really good job of running the identification part of PST Migration. The QUADROtech product runs a migration agent under a user context, outside of Outlook, which reports on all PST files that a user can see, in a configurable set of locations too, if needed. This information is sent back to a central server which means that the information can be analysed and filtered to get a very good, accurate, understanding of the scope of the PST problem. Ever wanted to find out the user with the most PST files quickly?
Other aspects of the migration are also handled well by PST FlightDeck, a particular favourite of mine is the bandwidth aware, resumable uploading of PST files. Many network and Enterprise Vault Administrators love this feature and the fact that it means that the PST migration can have very little impact on end-user operations. No more Outlook hangs whilst data is pushed up a small network-pipe!
Conclusion
In some organisations that I've worked with, things like a domain administrator account have been kept under tight lock and key - literally. Having an account that can access every single machine in a domain is just not something that many organisations will allow to be used, as useful as it might be from time to time. Further, an account which has enterprise-wide or forest-wide permissions would just result in ridicule if it were suggested that it should be used for PST migration. For these types of organisations clever ways of approaching the problem need to be developed. We think that the way that PST FlightDeck does this is a great approach, and since we operate as the user we can access and see everything that a user can see, including portable media that almost every other solution will miss.
How have you scoured an environment for PST files? Let me know in the comments below.
