Fighting Journal Delete and transaction history

[SymStudent]

Good morning my connected comrades.

I have a series of problems that I have been fighting (non personal ... all professional) and was wondering if there was any advice that someone could offer.

Content was added to EV via API and due to a defect in the third party application, something in the archivefolder table got messed up, which would cause the Admin service to stop EV to save it from dire badness. Although the defect in the product may have only been partially corrected, the support of the utility have requested that I use a new archive to test with. The archive was not only having content pushed to it, but also had been actively used as a user archive.

Part of the tool being used also added a custom index attribute so that the content placed into the archive could be identified. To correct this I have deleted the content and can confirm that it is in Journal Delete and no longer in the index. Now that you have what happened... onto my issue.

I know (but have issues believing) that this defect/enhancement still exists and the reason I have far more than I expect when exporting to PST is because of it. I thought that working around that issue I could use the following TN's method 2 (since method 1 really does not address the issue presented in the TN): http://www.symantec.com/business/support/index?page=content&id=TECH160685 .

I used the following query :

USE EnterpriseVaultDirectory
Update Archive
Set RetainArchiveHistory=1
where VaultStoreEntryId = 'MyOnlyVaultStoreEntryID'

After doing that... I ran USPD_Journals with 0,0 parameters. I was wholly disappointed to find that this did not reduce the number for this user within the JournalDelete table .

Am I doing something wrong? I did not think so. I could change the history to 0 or run the SP to reflect the changed figure to 1... but I really did not think that would matter. I am hoping for suggestions.

Thanks so much in advanced for any assistance you can provide. If I get past this I can start working on my gobs of personal issues. . . .which will make everyone happy.

[GertjanA]

Hello Student,

Which EV version are you talking about? also please note that several of us here do know EV, and some offical tools, but ' some'  tool inserting data into EV using the API is not always supported or supportable...

The version would help hopefully.

What are the events that cause ev to stop?

[SymStudent]

Thanks for the response. The environment is running EV 9 SP2. the tool is a supported and supportable tool sanctioned through SYMC.

Most telling was the following:
 
Type :                    Error
Date :                    2/2/2012
Time :                    7:12:44 AM
Event :                  6469
Source :                                Enterprise Vault
Category :           Storage Online
User :                    N/A
Computer :         SomeComputerName
Description:
An exception has occurred.
[Internal reference CArchiveAssister/CF/ce]
[
Details:
ContainerArchiveVEID: null
ParentFolderVEID: ValidParentFolderID
FolderName: FolderName (First
FolderPath: ?Inbox?FolderName (First
]
 
For more information, see Help and Support Center at http://evevent.symantec.com/rosetta/showevent.asp?EvtID=6469

In the example above the issue was the actual folder name was "FolderName (First\Second)" (or close enough to that) and the tool created a new folder based on the slash.

I do appreciate your comments but I think you are missing the point of my posting. The root cause of the issue is presently being investigated by the supported third party application support team. I would like to know how to successfully export a users archive that has content in the JournalDelete table without exporting the content that was deleted. The tool, initial issue, events, or details in this posting (outside of potentially the version)... in this case.... should not really matter.

So the summary of what I am asking:

If you delete  1000 items from an archive with a 32 day transaction history, and then export that archive to PST, how can you do so and NOT include the 1000 items deleted?

The steps I tried should have worked in my opinion. I know why it exports the deleted items, I know it is a defect or non-enhanced feature in the version I am using. . .I believe there is a way to make it work that does not involve waiting out the time-line.

Thanks for the reply and effort to assist .

[JesusWept3]

Your best bet is to call support and even then I dont think they can help, I just don't think this forum is the place to deal with this issue as you could just end up making things worse

[SymStudent]

Thanks JW2.

I assumed since this defect/enhancement has been in the product since version 8 base (the TN implies it does not exist in EV 8 SP5 . . .but just via version info) that this is an operation that has been successfully accomplished. I do not see the same potential for potential "making things worse" but do see that support will likely show me the TNs that I have already shared and close my case. All of this made me think that this would be the ideal place to seek a solution.

I mean the issue is that the following TN does not appear to be working for me:

http://www.symantec.com/business/support/index?page=content&id=TECH160685

It also seems somewhat incomplete. ... so let me rephrase; does anyone have any experience with the circumstances of that technote where they needed the changes retroactively applied (so method 1 will not do the trick) and have had success with method 2? If so ... any pointers.

I assume if there were potential to make things worse, this technote would not be made available to everyone. Is this an incorrect assumption.

I do not mean to question your advice, just hoping for something more from someone out there...

Thanks for taking the time and all your contributions to the forums.

[JesusWept3]

well the thing is JournalArchive and JournalDelete are two absolutely different beasts
The journal archive items will stay until BackupComplete = 1 and IndexCommited = 1 and then the amount of days until the TansactionHistory applies

With JournalDelete those items can stay there for a long long time, it has to get commited to the index (i.e. removed from the index), then it has to wait out the dumpster period and switch from a soft delete to a hard delete, then it has to go past the transactionhistory time as well (But at this point is non recoverable)

I believe the technote, regardless of how badly written it is, does not apply to your situation

[SymStudent]

Hey JW2.

Thanks for your continued discussion about this issue.

you stated:

With JournalDelete those items can stay there for a long long time, it has to get committed to the index (i.e. removed from the index), then it has to wait out the dumpster period and switch from a soft delete to a hard delete, then it has to go past the transaction history time as well (But at this point is non recoverable)

I missed that that appeared to be related to only Journal Archive. So would you suspect that changing the dumpster period and changing the transaction period should clear it out. Shouldn't executing the SP specified with the parameters provided emulate that?

The index entries are removed... so that is good. I am attempting ... really attempting... to not wait out the dumpster and transaction period histories. How would I go about "overriding" that if desired.

Thanks for the clarification and continued assistance.

[JesusWept3 · Accepted solution]

Well the RetainArchiveHistory is really just for virtual vault and vault cache so it easily knows whats been added, removed etc rather than having to correlate its entire contents with what is in the vault stores.

Once the DumpsterPeriod has expired which by default if you enable it, is 14 days, it will then go from a soft delete to a hard delete, which means that its removed from storage (unless its in a CAB file) and at that point even if you DID want to export deleted items, you could no longer do that.

Simply changing a column or deleting the record however will not help as there are other processes that need to kick off in the storage delete process to do clean up on the disks and what not