PST Import Failure

[dgh1981]

Good morning.  I have been having some trouble getting PST files to import into EV 10.0.3 that got exported from our old Mimosa NearPoint system.  We contracted with a 3rd party company called Archive1024 that has a stable of former NearPoint engineers.  Their product does a mass export of all of the data from NearPoint and is creating 5 GB PST files of user archived.  For example, my own export has 3 PST files.  

What I am seeing is that older e-mails (those before 2/2/11) are making the PST import function crash within EV.  When I import, it will first pop up a box that says "The PST Migration Server on ServerName has unexpectedly shut down.  Click Next to restart migration".  It then restarts and crashes again, etc. 

The event log will show a few errors such as:

Enterprise Vault could not migrate an item from a PST to an archive. Check the migration report once the migration has completed. 

PST: C:\export.pst 

Subject: Mail Log summary created on Thu Jan 27 04:02:03 EST 2011. 

Folder: Inbox 

Archive Name: David 

Archive ID: 1C858A7A00D52314197B806D11C277D241110000servername

Error: Catastrophic failure  (0x8000ffff) 

I found that our NearPoint system was updated on 2/2/11 to a new version, and there appears to have been some kind of encoding bug in the prior version of the archive.  I can see that some of the older items have "Chinese-like" characters in the "from" field.  There are also other e-mails that fail to import even though they appear to be normal and don't have those characters.  I've been going back and forth with Archive1024 on a solution and now they are wanting to know if there is a way to get more detail as to why EV is crashing on import.  I get those catastrophic errors, but they want to know if we can get what MAPI properties would be causing the crash.  Any thoughts on what I could look for on the EV side?

Thanks!

[JesusWept3 · Accepted solution]

DTrace StorageArchive and MigratorServer when importing the PST files and whatever it is throwing the event in the event log, it should help determine which message crashed and what it crashed on.

You may need to use DebugDiag and have it output the memory when that particular error is thrown if the DTrace doesn't give enough detail, but its definitely a mimosa issue at this point.

If the solution really doesn't work out well for you, and you want to try a different route, contact Andy Becker (Abecker) on this forum as he has done a number of mimosa migrations to EV

[dgh1981]

Great thank you!  I will try those things.  NearPoint was a decent product at one point, but just lost all development of it when it got purchased by Autonomy.  Now, I think it wants to be difficult because I am trying to replace it. :)

I will post any updates on these further tests.

[JesusWept3]

Autonomy was bought by HP and NearPoint was bought by IronMountain the EOL'd the product lines in 2011 i believe

Good luck though!

[dgh1981]

We all know what happens to products that HP purchases....Web OS anyone? :)

[Prone2Typos]

I have done a handfull of these migrations. I know when A1024 initially shows their product they typically show some level of failures that were known issues in Mimosa and they go to their advanced config and show how you can configure those errors to pass.

I know that the initial failure counts are pretty astonishingly high and anyone I have spoken to that knows of Mimosa knows that there were certain issues that were systemic to certian versions of Mimosa. I wonder if the issues you are expirencing are related to the making of these failures being passable failures via ADV configuration... but since they are hozed items that were configured to output anyhow if EV is not liking them.

We have done a few of these too... so if you need to talk to someone I can get you in touch with our team to discuss some other options to get the data into EV should you not be able to progress with A1024/EV support.