Invalid SIS part

[Sortid]

Hi, I'm using EV10 SP3.  I'm getting the 7110 error: 

"An invalid SIS part was encountered while doing watch file scan....

Invalid Reason = Verification failed for sis part when post processing Saveset with TID = [50B0519E9218ABAC4A9DBC89179405C1]."

So I ran a dumpsaveset on this TID and I get  

EVSVR Command>ds 101E1FFCF7FA5D647A7DB240CFD8534C81210000CDCAAPEVSVR01 50B0519E-9218-ABAC-4A9D-BC891
79405C1
2013-10-10 10:33:15  Log file 'C:\Program Files (x86)\Enterprise Vault\Reports\EVSVR\EVSVR_DumpSaves
et_20131010103315\EVSVR_DumpSaveset_20131010103315.Log' created/opened
2013-10-10 10:33:15
2013-10-10 10:33:15  EVSVR Version (10.0.3.1090)
2013-10-10 10:33:15
2013-10-10 10:33:15  Initialising operation
2013-10-10 10:33:15  Arguments: 101E1FFCF7FA5D647A7DB240CFD8534C81210000CDCAAPEVSVR01 50B0519E-9218-
ABAC-4A9D-BC89179405C1
2013-10-10 10:33:15  Output folder: C:\Program Files (x86)\Enterprise Vault\Reports\EVSVR\EVSVR_Dump
Saveset_20131010103315\
2013-10-10 10:33:15  Log file path: C:\Program Files (x86)\Enterprise Vault\Reports\EVSVR\EVSVR_Dump
Saveset_20131010103315\EVSVR_DumpSaveset_20131010103315.Log
2013-10-10 10:33:15  Found a vault store: Parameter 101E1FFCF7FA5D647A7DB240CFD8534C81210000CDCAAPEV
SVR01 is the entry id for vault store 'Mail Vault Store 01'.
2013-10-10 10:33:15  Log file closed
2013-10-10 10:33:15
DumpSaveset Initialisation failed: ERROR: The second parameter 50B0519E-9218-ABAC-4A9D-BC89179405C1
is not a valid saveset or transaction id. Error: The specified Saveset does not exist.      (0xc0041
aac). Error: 0xc0041aac

So I jumped on the SQL server and ran:

select * from EVVSMailVaultStore01_1.dbo.JournalArchive where TransactionID = '50B0519E-9218-ABAC-4A9D-BC89179405C1'

and it returned a result. "201310091306457~201302100614000000~Z~50B0519E9218ABAC4A9DBC89179405C1"

So from that I can see the location is somewhere in \2013\10-09\5\0b0\

I then went to the partition to check out the files but it was not there.  I then checked a few other items which generated 7110 warnings and they were not there either.

These items in the JournalArchive have a BackupComplete=0.

Does this mean that the item was deleted before it could be backed up?  Did users delete a PendingItem/SafetyCopy from their Outlook? 

Is there a way to clean these entries out of the database?

Thanks.

[JesusWept3 · Accepted solution]

You would use EVSVR to clean surplus database references
If it wasn't backed up, then it wouldn't be in a CAB file if you use collections, but just because BackupComplete = 0, does not necessarily mean it hasn't been backed up, so its worth checking your backups to see if the item exists, that being said, with that date, that is today, so unless you do snapshot backups, it may not be on your backups at all

Have a look at the event logs, it could be that it failed to store the item properly and didn't complete its roll back, also if you do After Backup for the mailboxes, then no data loss should incur, as the item should remain as a pending item

[Sortid]

Thanks for your quick response JW.  The event logs don't show anything that has not been stored.  We do get those 7110 errors consistently, about 10 every day.  I chose some random ones and their DVS files are not on the system, but are still referenced in the DB.  I'm curious as to how the files were removed/deleted.

As a test, I archived an item which generated a DVS file; then leaving it as a pending item, I deleted the item from the archive straight away.  The DVS files were not removed, however.  I thought they would be removed immediately, is there another process that does this?  We do have "Enable recovery of deleted items" on.  The item is now also listed in the JournalDelete table. (Not sure exactly how these tables all fit together).

[plaudone]

You may want to take a look at this post- http://www.symantec.com/connect/forums/event-7110-invalid-sis-part-was-encountered-while-doing-watch....  

The above issue did not have missing DVS files from storage but references another issue that should have been resolved by 10.0.3.

Are you using Archive Bit or Trigger file for backups?  Are the same items being referenced in the errors or potentially the same SIS Parts? 

Does the following query return data?  

select * from EVVSMailVaultStore01_1.dbo.Saveset where IdTransaction = '50B0519E-9218-ABAC-4A9D-BC89179405C1'

When an item is stored it goes into the Saveset (SS) and JournalArchive (JA)  table.  The Saveset table data should remain until the item is deleted.  The JA table data is temporary and used to track whether the item is indexed and backed up.  It is removed from this table after a period of time.  

The JournalDelete (JD) table will only have entries in it after items have been deleted from the archive.  This will track whether the item has been removed from the index.  It is also used to allow for recovery of items.  

In your case deleting the item from AE would leave it in the JD until the time to recover has expired and then Dumpster expiry would remove the item from the DB and the DVS from storage.  

Is AV scanning the vault store?  This could explain the missing DVS file.

[Sortid]

Hey Plaudone.  The article references saveset sizes being recorded as 0, but I am not seeing that issue. 

We use a trigger file.  I don't believe they are the same SIS part as the transaction IDs return different SaveSetIDs which have different names (and hence different paths to the files).  And they are not the same messages being referenced.

The query in the SaveSet table did not return a result. So if it's not in SaveSet but returns a result in JournalArchive and JournalDelete, does that mean it has been deleted by a user?

Thanks for the explanation on the tables   :)

We don't have AV installed on the server.

Cheers.

[plaudone]

Sortid...if the item was deleted by a user the DVS should still be in storage to be able to recover should they want to recover deleted items.  Without the DVS the item cannot be recovered. 

I would go with JesusWept3 on the use of EVSVR at this point to validate the items in storage.  It could very well be that a rollback did not happen properly in SQL.  Is SQL maintenance occurring regulary?