Before you waste months on this issue like I just did, do you use a PEA for your Centera? Do you have anonymous profile turned off on the Centera? If so, then there is a bug in the Enterprise Vault code that does NOT send the PEA to Centera when deleting a vault. I worked for months on this aggravating issue and finally the boys in the UK found it in a code review after some SDK logging showed very strange commands being sent to the Cetera.
Your event logs look identical to the ones I had on my systems. I bet if you use a tool from EMC (the name escapes me right now) it'll delete that same ClipID no problem at all and the delete will replicate to your other Centera nicely.
EV 7.0 SP3 will have a fix for it and EV2007 SP1 will have a fix too. I don't know if they'll put a fix in for 6.x or not.
For the time being on your EV servers set an environment variable named CENTERA_PEA_LOCATION. The value is whatever the disk path is to your PEA file. Something like
CENTERA_PEA_LOCATION D:\PEA_FIle\MyPEAFile.pea
That will force the system to pass the PEA to Centera.
If you talk to Symantec support, tell them you think you are being affected by the same Vault Delete issue that support ticket '281-124-984' had.
We also have two Centeras that replicate between each other. You may now also have orphaned clips on your Centera now. We found even though Enterprise Vault gets an error that will not let it delete from Centera, it WOULD still delete rows of items from the SQL tables. If you stop and start the Storage process enough times, you'll eventually see the vault disappear from Enterprise Vault Admin Console. It'll be gone from EV, but the data is still on Centera.
You'll want to work with support with a tool called 'EVCenteraChecker' to scan your Centera for Orphaned Clips and get rid of them.
Message Edited by Brian Day on 07-23-200708:45 AM