Dealing with PST files

[psuttill]

I am in the midst of finding a solution to deal with the mass amounts of PST's on our network. I have looked over using EV to do PST migrations but after going over the PST's on the network it looks like it could be a demanding task since Ethe are very unorganized badly named and most are probably orphaned.

I was looking for feed back comparing actually doing PST migrations and handling them that way , or having the users manually archiving the email they want to save into EV by enabling Virtual Vault and allowing them to drag and drop. And then just doing mass deletes of PST files after a given time.

opinions on an approach?

How did you tackle this ugly job?

[Liam_Finn1]

The PST migration tool is by far the easiest way to do this. Expecting an end user to perform this task is an endless battle. Taking control of it and performing the migrations for them then deleting the PST's is by far the best solution.

[Minke]

Hi

I just finished migrating 800GB and 3000 PST's off our network about  1 month ago. The process that we chose was using EV and doing Server migration.

We would of done the client migration however we didn't want to migrate PST's on user's C: drive. and the client migration model didn't allow us to select only network based PST's

80% of our PST files were in Home Drives, or the name of the file was clearly marked...

So we injested 80% that we could identify, the other 20% we moved off onto tape and deleted from the network.  any one that wants those PST files they need to identify what mailbox they belong to and we then injest them.

We now delete *.PST from our file servers...

[WiTSend]

Depending on the corporate requirement for data retention.  "Orphaned" psts can be migrated into manually created retention archives using the import, PST Wizard or EVPM script  for the purposes of data retention and not specifically assigned to a user.  Thus the data is available for search or eDiscovery and can be managed within the corporate retention policies.

[MichelZ]

Depending on the size of your project you may want to have a look at our "PST Flightdeck" Software - http://www.evtools.net

Cheers

[El-Kabong]

We have about 6.5 TB of data in ~31,000 PSTs.  Yikes.  I set up a proof of concept with EV 8 SP4 and did some testing.  My conclusions were basically the following:
 

• EV is a relatively mature & solid product, and we didn't find anything else that really matched (BTW, we're looking into PST FlightDeck and are still waiting on a concall/demo).  It also works with VMs (we have ESX) so you can save some money there.  However, be aware that it's not yet compatible with either Exchange 2010 or Outlook 2010.  (Before I get flamed for that last comment, let me say that I know & you should know that Exchange 2010 SP1 compatibility has been promised in the yet-to-be-seen EV 9.0, and Outlook 2010 compatibiltiy not until 'sometime' at the end of CY 2010 with EV 9.0 SP1.)  If you're in either of those environments now, however, you're out of luck.

• WRT PST Ingestion, if you have a single, primary location, and users are all connected via LAN speed to the Exchange/Archive environment, the server-driven process should work pretty well.  Granted, it is not without its limitations and hassles, but I DID get it to work pretty much as designed.  Making sure that Outlook is open/closed on the user desktops during these PST Migration tasks will be one of  the more notable hassles.  Your mileage may vary. 

• If you have WAN-connected sites with alot of PSTs on remote PCs/Servers, you're in deep trouble.  There is NO officially supported method to ingest PSTs over a WAN link using the built-in EV tools and it will KILL your WAN links.  We still don't have a way to do this, and may put the entire project on hold because of this limitation.  I've researched and performed my own testing, as well as worked with Symantec Engineers on this one, all to no avail.  I don't think this is necessarily an EV-specific issue.  I suspect it is much moreso that the nature & scope of what we're trying to accomplish is very huge.  
   

When the Law of Large Numbers is introduced (such as with the scope of our situation) things get much more complicated and tougher.  If PST ingestion is a significant requirement (i.e. legal or other compliance) and your situation is primarily like the first scenario above, if you familiarize yourself with the product's limitations and find ways to fill its gaps you should be OK.  Definitely get a trial license from your Symantec rep if you have one and do a POC.  You can put everything on a single server and use test MBs, as I did. That's the best way to know if it is right for and how it will work in your environment.
 -