Change in Legal Hold Process with DA 9.0.4 CU2 / 10.0.2 CU2

[AKL]

Hello All

Recently we upgraded our EV 9.0.1 environment to EV 9.0.4 CU3 along with appropriate DA updates. Since the upgrade, we faced issue where cases stayed in "idle" status and the legal holds didn't apply at all i.e. items stayed in "remaining items" bucket for case.

We tried normal troubleshooting included with legal hold which can be read about here. However same didn't help. In the event logs we were getting Error 562, which basically indicates that some items could not be processed due to legal hold error.

On quick search for that error, i stumbled on this technote 66365 which tells you that after 9.0.4 CU2, DA will keep retrying applying legal hold on items which've been erroring out in hope that administrators have fixed the issue with that particular item accordingly. However, it still didn't explain why no item was going into hold state at all. The SQL query in above technote didn't help either.

Running out of option, we opened case with Symantec and after couple weeks of troubleshooting, they asked us to disable "Sync validation" configuration via DA client (which is hidden by the way, to display same, you'll need to show hidden settings in DA client, steps for which are covered here.)

After disabling Sync validation and restarting DA service, the items started processing and all items which DA didn't have any issue with were put on hold accordingly. The remaining items in our scenario basically are those which no longer exists in EV environment. The status changed from "Idle" to "To Add Holds" with some remaining items in case bucket.

According to Symantec, the DA should basically give up after n number of retries but in our case it is not doing so. Currently investigating same. If anyone has further thoughts in this direction, please do share.

Once we reach final case resolution, I'll update same here accordingly.

Hope it helps !

Thank You.

[AndrewB]

Thanks for sharing

[EV_Ajay]

How to remove Legal Hold Errors from DA Cases

-- Get the CaseID for the Colum “Errors” from Cases Tab.

Select * from tblCase where StatusID = 20

-- Check counts in tblLegalHoldSummaries

select * from tblLegalHoldSummaries where CaseID = 31

-- Update tblIntDiscoveredItems

update tblIntDiscoveredItems set LegalStatus = 420 where CaseId = 31 and LegalStatus = 425

-- Update the counts in tblLegalHoldSummaries via this SP

EXEC [usp_LegalItem_UpdateSummary] @CaseID = 31

-- Check counts in tblLegalHoldSummaries. CONFIRM NumHoldError = 0

select * from tblLegalHoldSummaries where CaseID = 31

--DONE

[AKL]

Thanks for sharing EV_Ajay. However the query you shared is not "removing errors" from holds, it's just forcing errorneous items in DA case to appear as completed so DA doesn't tries for them again. You can also find similar query with below technote:

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

The issue mentioned has been acknowledged by developer team and they're working on same via an Internal ETrack. I was just sharing infoormation via forum for others to ensure awareness as needed.

Thanks again !

[EV_Ajay]

Hi AKl,

Thanks for sharing the information. I will check the ETrack.

[Kenneth_Adams]

Greetings, AKI;

We've recently uncovered an issue with the new 'feature' in 9.0.4 CHF2 where we will automatically retry failed hold items indefinitely.  It seems that any item that failed to be placed on hold before 9.0.4CHF2 was installed AND was removed from storage keeps returning an invalid failure code, so we keep retrying the same set of items over and over.

The workaround is to uninstall the DA server portion of 9.0.4 CHF2, reset all failed items per TECH66365, then let the normal hold processing take care of itself.  Once all holds have been applied or items correctly identified and marked as no longer in storage, the 9.0.4 CHF2 installation can be repeated.

We're opening a new Etrack for this issue to obtain a fix for the incorrect error code we're receiving for items that were removed from storage after failing to be placed on hold.

[AKL]

Below technote is published for issue I attempted to describe in this forum - ETrack 3265303

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

[Kenneth_Adams]

Folks,

Engineering Track (Etrack) 3265303 has been replaced with Etrack 3262079, which shows as having the fix in DA 9.0 SP5 (9.0.5) that is currently due out in Q2FY2013 (subject to change).

Until then, uninstall the CHF for DA 9.0.4 only (leave the EV CHF installed).  Once uninstalled, run through the steps in TECH66365 to reset the failed holds to the no hold status and let the hold processing work on those reset items and any other items that need to be placed on hold.  Any items to be placed on hold that have been deleted from any vault store(s) will be properly set to the LegalStatus code of 427 (Item Deleted) instead of 425 (Hold Error).  A defect in the CHF code was causing those deleted items to be improperly left as set to LegalStatus 425, which caused a looping condition in the automatic failed hold retry procesing.

Leave the DA CHF uninstalled and upgrade to EV and DA 9.0 SP5 as soon as you can after it is released. 

[AKL]

Thanks for update Ken. Will wait for release of 9.0.5 and will install it 1 month after its release giving it proper incubation period.

[Kenneth_Adams]

You're welcome.  If you've not uninstalled the 9.0.4 CHF yet, please do so as you won't get proper Legal Hold processing until you do that uninstall or upgrade to 9.0.5.  Leaving the CHF in place could lead to items being deleted when they should be retained.

[AKL]

Already removed the CHF from DA box around same date when I posted this forum. WIll wait for 9.0.5 now.

Thanks !