Is there a way to identify which archives have items that are part of a DA case/research folder?

[SHI-CRO]

Often people will want to delete mailbox archives they don't need any more, especially archives whose corresponding AD account is deleted.

I noticed today on a DA server that we were getting lots of these warnings:

---------------

Log Name:      Symantec Enterprise Vault
Source:        Accelerator Service Processor
Date:          7/31/2013 2:18:51 PM
Event ID:      480
Task Category: None
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      EVDAComputer
Description:
APP AT - Customer ID: 4 - Archive '18FD793D8D0E3B847971845B8D4E5309D1110000EVxxxx' failed to registered error code: -1073472711
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Accelerator Service Processor " />
    <EventID Qualifiers="0">480</EventID>
    <Level>3</Level>
    <Task>0</Task>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2013-07-31T18:18:51.000000000Z" />
    <EventRecordID>161121</EventRecordID>
    <Channel>Symantec Enterprise Vault</Channel>
    <Computer>EVLEGAL1.admin.bcps.k12.md.us</Computer>
    <Security />
  </System>
  <EventData>
    <Data>APP AT - Customer ID: 4 - Archive '18FD793D8D0E3B847971845B8D4E5309D1110000EVxxxx' failed to registered error code: -1073472711</Data>
  </EventData>
</Event>

---------------

Searching in the console for that archive ID turned up nothing, but we could find the user name in the DA database connected to that archive ID.  I suspect that if you delete an archive while DA is referencing items in a case or research folder will cause that warning to happen.

I would like to be able to know before deleting an archive if DA is using any of the items in it.  Sometimes we're dealing with hundreds of cases, so looking at each case individually wouldn't work.  Any other way to know?

[Rob_Wilcox1]

Does this help?

https://www-secure.symantec.com/connect/forums/how-tell-specific-archive-contains-items-are-legal-ho...

[GabeV]

This TN provides several SQL queries to determine the following:

Script 1:  Determines which DA Customer databases are placing Legal Holds on Vault Store databases

Script 2:   This is designed to supply BY CASE the amount of legal holds the DA customer database reports as 'on-hold' PER VAULT STORE

SCRIPT 3:   This is designed to supply BY VAULT STORE the amount of legal holds the Vault Store database reports as 'on-hold' PER DA CASE

SCRIPT 4:  Determines the summary count of items that are currently on Legal Hold within the Vault Store by Archive ID

SCRIPT 5:  Determines which DA Customer databases have a Legal Hold on a single item by SavesetID

SCRIPT 6:  Determines which DA Customer databases have a Legal Hold on a single item by TransactionID

SCRIPT 7:  Provides a listing of all Legal Hold error codes and causes as listed in Technote TECH61297 (see Related Articles below).

http://www.symantec.com/docs/TECH72381

I believe that you will need script #4, but you need the archive ID for those archives where the AD was deleted.

I hope this helps.

[Pradeep-Papnai · Accepted solution]

Below query should give you archives where DA searches going on.
 
Use <customerDatabase>
select VaultID, KVSVaultName from tblVaults where VaultID in ( SELECT tidi.VaultID FROM tblCase tc
JOIN tblIntDiscoveredItems tidi ON tidi.CaseID = tc.CaseID
JOIN tblVaults tv ON tv.VaultID = tidi.VaultID)

I am not very good at DA, but I tried to do same testing in my lab. Some DA experts can confirm if query below is correct to know Archives ( where searches is going on in DA case) and we can stop deleting those archive proactively to avoid DA erros.

[EV_Ajay]

Hi,

Determines the summary count of items that are currently on Legal Hold within the Vault Store by Archive ID

Instructions:
1. Replace 'ABCDEF1234567890ABCDEF1234567890ABC10000EVSite'  with the appropriate ArchiveID number.

2. If the EnterpriseVaultDirectory is on a different SQL server, Add the 'SQLServerName.' in front of EnterpriseVaultDirectory (Five times within the script).
       Example: SQLServerABC.EnterpriseVaultDirectory.dbo.Archive

3. Using SQL Query Analyzer, copy the text below into a New Query window and execute the script against the Vault Store database that contains the Archive in question.

4. Verify the correct Vault Store DB is being queried through the output of the query.



DECLARE @Temp1 nvarchar(127) SET @Temp1 = 'ABCDEF1234567890ABCDEF1234567890ABC10000EVSite'

DECLARE @ArchiveName nvarchar(256)
SET @ArchiveName =
(SELECT ArchiveName FROM EnterpriseVaultDirectory.dbo.Archive WHERE RootIdentity =
(SELECT RootIdentity FROM EnterpriseVaultDirectory.dbo.IndexVolume WHERE FolderName = @Temp1))

DECLARE @VaultName nvarchar(50)
SET @VaultName =
(SELECT DatabaseDSN FROM EnterpriseVaultDirectory.dbo.VaultStoreEntry WHERE VaultStoreEntryID =
(SELECT VaultStoreEntryID FROM EnterpriseVaultDirectory.dbo.Archive WHERE RootIdentity =
(SELECT RootIdentity FROM EnterpriseVaultDirectory.dbo.IndexVolume WHERE FolderName = @Temp1)))

DECLARE @Summary3 int
SET @Summary3 =
(SELECT COUNT(*) FROM (SELECT DISTINCT SavesetIdentity, HoldGroupIdentity
FROM HoldSaveset WHERE SavesetIdentity IN
(SELECT SavesetIdentity FROM Saveset WHERE ArchivePointIdentity =
(SELECT ArchivePointIdentity FROM Vault WHERE VaultID = @Temp1))) AS new_table)


SELECT @VaultName AS 'VaultStore DB', @ArchiveName AS 'Archive Name', @Summary3 AS 'Number of Legal Holds'

[Pradeep-Papnai]

Does above answers enough for the questions you asked?

[Ben_Watts]

Doesnt the above only help if the items are on legal hold?

Correct me if I am wrong.

If the items are on legal hold anyway then you are unable to delete the items/archives so you wouldnt get into that situation where you have archives deleted but errors on the DA server for those Archives/Items.

[JesusWept3]

Easiest way is if DA is set to register an interest is simply to query the VaultInterest table, that's all that needs to be done

[SHI-CRO]

The first post by EV-Counselor was the one that worked for us.  The issue wasn't items that were on legal hold, but items that were simply part of a case or research folder via a search.