Video Screencast Help
Give us your opinion and win with Symantec! Please help us by taking this survey to tell us about your experience with Symantec Connect, so that we can continue to grow and improve.  Take the survey.

Delete VaultInterest Table Entry

Created: 06 Sep 2012 • Updated: 07 Sep 2012 | 4 comments
This issue has been solved. See solution.

Can someone clarify what happens when an entry is manually deleted from the vaultinterest table.   I have a couple of archives that need to be relocated to another store.   I am unable to move or export and delete these archives due to legal holds or the vaultentryid being in the interest tables.  I am told the archives are not on legal hold, but that does not mean there are no searches against them to cause the lock if I understand correctly.  Case and search deletion are not an option for various reasons.   So the question is, what happens if the entry in the vaultinterest table is removed, are there any negative impacts?   Does ev, da, or sql choke with errors down the road?  

Discussion Filed Under:

Comments 4 CommentsJump to latest comment

LCT's picture

As far as I understand from an DA point of view, if the Case still exists then everything will hold the archives on legal hold therefore you won't be able to delete any items related to those archives. I wouldn't delete those entries due to them being linked to other tables and columns etc. and it is never a good idea to delete stuff from DBs unless it is the ExchangeMailboxEntry table. If am being honest, I don't know the exact affect as I don't often delete stuff from the DBs. :-)

Your best options is to some how close the DA search case and then move the archives and then create a new Case. If you are told they are no longer on legal hold then why can't you close the case? Just curious!

Liam Finn's picture

If you delete content from this table you wail result in loss of legal hold against the items. This will result in items that should be on hold being deleted and as a result your company could possibly receive sanctions in court for failure to preserve data

The outcome would mean large fines for your company and unemployment for you.

The safe way around this is to talk with your legal team and see if the cases can be released from hold while you make your changes but be sure to explain the possible effects on their existing cases.

Once the release the hold you can make your moves then they can apply the hold again. You may find that because of the move you may have some items fail to have hold applied. In that case legal will have to rerun their searches and then reapply the hold

The simple fact is that moving vaults while data is on legal hold is not so simple. You will need to have a long talk with your legal team before proceeding

JesusWept3's picture

Actually the entry being removed from VaultInterest won't affect the legal holds at all, in fact it's probably the most useless thing because it ONLY lists users that are in a search, but if you delete the archive the contents will delete but the archive will fail to delete

So you end up with an empty archive that throws a primary key violation on each storage service startup

A user being listed in there does not mean that the user has items that are on hold, and does not stop their items from being deleted, just that the archive cannot be deleted

Removing manually does not delete anything that IS on hold and would not allow items that are on hold to be deleted

And I have had to go through the exact same scenarios before on a move archive project

AKRay's picture

I should have stated earlier the problem was when archiving runs for a couple of accounts it generates eventid error 13360 among others;

"dbo.uspcu_Vault Error: VaultId = "111E93A5678551113A5D6036DD81110000archive" does not exist."

It does this repeatedly to the point it takes ev services offline.  DTraces were done and we could not determine the problem even with Symantec supports assist. I believe the final decision prior to was to delete the case to allow the archives to be moved in hopes of solving the problem. We decided against use of the ignore error reghack as well.

Testing we placed an archive on legal hold.  We then deleted the vaultid's from the vaultinterest table.  Moved the archive to a new store and ran a query confirming JW3 is correct, the archives remain on legal hold.  Moving forward in real world we backed up the db and performed the process again on a problem archive.  Next ran a run now and no more errors.  The only downside from what we can tell will be the user if they use archive explorer will see two archives (old with cutoff date and new). The original archive now closed will remain until the legal holds are removed and the case is closed or better yet deleted.