The Move Archive process fails during Stage 1 (Copy phase) with "There is another item with the same transaction id in the destination archive".

The Move Archive process fails during Stage 1 (Copy phase) with "There is another item with the same transaction id in the destination archive".

Article: 100007874
Last Published: 2015-03-23
Ratings: 0 0
Product(s): Enterprise Vault

Problem

During a Move Archive job, a check is performed between the source and destination Archives to determine if the item to be copied is already in the destination archive.  If the item (IdTransaction) is found within the destination archive, the message "There is another item with the same transaction id in the destination archive." is reported for the item within the Move Archive report. 

Move Archive is designed to systematically skip items which were moved to the destination Archive during a previous run of the Move Archive process.

If the Move Archive process identifies a duplicate IdTransaction in the destination Vault Store, however it is not in the destination Archive, this presents a 'Transaction ID clash'. The "SkipDuplicateItems" switch within the EVMoveArchiveTask.exe.config is designed to allow the Move Archive process to continue and skip moving the duplicate items identified in the Vault Store

This article refers to an identified issue where the following error occurs when the Move Archive identifies a duplicate IdTransaction in the destination archive and determines that the source and destination items are different.

Error Message

In the Move Archive Report:

-There is another item with the same transaction id in the destination archive.
-An error was encountered while processing an item. Enterprise Vault will try again later unless the retry count has been reached. Item: <Transaction>. Exception: Item Id is not unique within the target Vault Store..

Cause

Investigation has identified a relation between this issue and the exporting of a source archive to PST (pre-8.0) then importing the PST to the same destination Archive prior to performing a Move Archive job.  In this legacy process, the IdTransactions will be the same, however the ArchivedDate values will be changed.  During a Move Archive process, the IdTransactions will be the same, however the ArchivedDate values of the items will not change.

Example:
  Site 1 - EV 7.5
  Site 2 - EV 9

1. Mailbox is moved from Exchange in Site 1 to Exchange in Site 2.
2. New Archive is created in Site 2 (EV 9.0)
3. Export of Site 1 (EV 7.5) Mailbox Archive to PST then import of Archive to Site 2 (EV 9)
- Items between Site 1 and Site 2 will have the same IdTransaction values, however ArchivedDate will change during Import.
4. Then Site 1 is upgraded to EV 9.
5. Move Archive is then leveraged to move the Archive from Site 1 to Archive in Site 2.

Workaround:

1. Disable the destination archive.
2. Export destination archive to PST.
3. Delete Archive from Destination and re-enable user for archival, generating a new Archive.
4. Run the Move Archive for the associated user to move the source archive to the new destination.

Note: The original export of the destination archive may be used for any additional items that may have been archived new to the destination archive which does not exist in the original source archive.

Solution

This issue is resolved in the following release:

Enterprise Vault 10.0.3 Cumulative Hotfix 2 Release
https://www.veritas.com/docs/000017767

Enterprise Vault 10.0.4 - Release Details
https://www.veritas.com/docs/000003643
 

References

Etrack : 2641436 Etrack : 3157942 Etrack : 3132160

Was this content helpful?