PST Capture: Congratulations and some caveats from Transvault's CTO

In addition to the welcome extended by many, the much-heralded and long-delayed arrival of Microsoft’s PST Capture tool was always likely to generate comment from the software vendors who already have offerings to help companies control the spread of dreaded PSTs. It therefore came as no surprise to see Dan Clark, the CTO of Transvault Software, post some notes about PSTs in general as well as the limitations he sees in PST Capture on the Transvault blog.

I’m sure that the “congratulations” echoed by Dan in opening his piece reflects the satisfaction that the software vendors in this space feel now that Microsoft has implicitly affirmed that companies do have a problem dealing with PSTs. After all, once Microsoft publishes a solution, there must be a problem for it to solve.

I’ve already published my views on some of the challenges that exist for any project that embarks on the elimination of PSTs using PST Capture, including the fact that Microsoft has only tested the tool against Exchange 2010 and is therefore not a good option for those still using Exchange 2007. Dan brought some other issues to the fore that I consider valid. Amongst these are:

  • PSTs hold a lot of rubbish: “No so!” you might hear users say as they attempt to relate the essential nature of all of the wonderful business-critical information that they have squirreled away in PSTs. Of course, they shouldn’t have any business-critical information in a PST because it’s insecure, but let’s move on from that truth. The sad fact is that the majority of data that you might capture and lovingly import into your immaculate Exchange database is not worth keeping. It might be interesting to a few, historical in nature, perhaps even essential if certain unlikely conditions were to arise, but there’s a fair probability that it’s not worth your while importing the data. But clutter up your databases if you wish, lengthen your backup times, and improve the profitability of storage vendors. Seriously, the point is that PST Capture is an all-or-nothing import tool: the dross flows into mailboxes along with the couple of jewels that should be imported and kept.
  • New PSTs appear all the time: At least, they will if you let users create the blessed files. If you plan to start to use PST Capture or another tool to import from PSTs, you should also stop the creation of new PSTs unless you want to be in perpetual motion on a search-and-locate for PSTs across all the PCs in the business. I’d spend some time reading MVP Mike Crowley’s notes on a PST suppression project that he recently undertook and then figure out what you’re going to do in your company.
  • Reporting is limited: Dan makes the point that demonstrating how information is handled might be important in the context of a legal discovery action (was that item interfered with en route from PST to mailbox?), but just as important is the requirement to be able to understand how a migration project is progressing from start to finish, how successful the imports are, what percentage of imports fail and why, how many bad items and of what type are encountered, and what the impact is on the destination primary and archive mailboxes.

At the end of the day, any free software is worth as much to you as you’ve paid for it. There’s no one to complain to, no one to ask about new features, and no method of getting support except through places like the TechNet forums where your queries might or might not get intelligent responses. I say this with my tongue firmly in cheek but there’s some truth in the assertion. 

Microsoft’s PST Capture tool has the backing of the Exchange development team behind it and that’s probably its best and most compelling characteristic. Given its status, I imagine that there will be many articles published on the net to offer advice on how to configure and use the PST Capture tool and also how to fix common issues. A good example of this is the three-part series on the topic published by MVP Andy Grogan.

Aside from the advantages mentioned above, you have to live with the limitations of the functionality as provided by Microsoft. Alternatively, you can make the decision to go and spend some money to buy a different PST ingestion solution from a software vendor such as Transvault, Sherpa Software, or QuadroTech. At least when you are prepared to hand over some money, you'll be able to report bugs that are likely to be addressed in a reasonable timeframe (failing that, you can shout loudly at the vendor and get some satisfaction that way), request new functionality, receive exciting marketing literature, and all of the other fun stuff that goes along with the necessary assessment, testing, selection, and deployment of software to address business problems.

Follow Tony Redmond on Twitter @12Knocksinna

Please or Register to post comments.

What's Tony Redmond's Exchange Unwashed Blog?

On-premises and cloud-based Microsoft Exchange Server and all the associated technology that runs alongside Microsoft's enterprise messaging server.

Contributors

Tony Redmond

Tony Redmond is a senior contributing editor for Windows IT Pro and the author of Microsoft Exchange Server 2010 Inside Out (Microsoft Press) and Microsoft Exchange Server 2013 Inside Out: Mailbox...
Blog Archive

Sponsored Introduction Continue on to (or wait seconds) ×