Move archive jobs get stuck in the Verifying phase

book

Article ID: 100033218

calendar_today

Updated On:

Description

Error Message

Dtrace of StorageOnlineOpns on the Destination Server

The dtrace initially shows the source item's Transaction ID being set on the destination item ( 410C8FAEE695CE16E8142F5476BF77C1).  However after the item is created, the Transaction ID is different ( 512F3B1ADCA86F11FCF2D06C7DBA6251).  As a result, when the FetchItem function is called to retrieve and verify the item, it is unable to find an item with Transaction ID 410C8FAEE695CE16E8142F5476BF77C1.  The Move Archive job then recopies the item as it believes that it has been deleted.   All recopies are affected by the same problem so a large number of duplicates are created in the destination archive.

3324249    10:45:45.707     [4856]    (StorageOnlineOpns)    <3620>    EV:M    {CSimpleStore::BuildSaveset} Setting override TransactionId [410C8FAEE695CE16E8142F5476BF77C1]
.
3324428    10:45:45.722     [4856]    (StorageOnlineOpns)    <3620>    EV:M    {CSavesetOnIStg2::IsSavesetUnicode:#268} Saveset is [ANSI]
.
3325197    10:45:45.785     [4856]    (StorageOnlineOpns)    <3620>    EV:L    {CSaveset2::get_SavesetIdentifier:#3643} Saveset identifier: [201006306693945~200806180821430000~Z~512F3B1ADCA86F11FCF2D06C7DBA6251]
.
2931658    10:45:46.319     [4872]    (StorageOnlineOpns)    <3620>    EV:H    {CSimpleStore::FetchItem11:#4227} _com_error exception: [The specified Saveset does not exist.      (0xc0041aac)]

 

Resolution

This issue has been addressed in the following release:
 
Enterprise Vault 12.1.2 Release
https://www.veritas.com/docs/000125196

Workaround

Export the source archive to a Unicode style PST.  In the Export to PST File wizard this is the default PST type.  Once the archive has been exported to a Unicode PST file, it can either be:

1)  Imported directly into a new archive for the user on the destination server.

or

2)  The user can be disabled for archiving on the source server and their archive deleted.  The user can then be re-enabled for archiving on the source server and the PST be imported into the new archive that is created.  These actions will ensure that all items in the archive are in Unicode format.  As a result subsequent Move Archive jobs will not be affected by the problem described in this article.

Please note that it is important to retain a backup copy of archive export PST files, as the items within the PST will be removed from the PST when it is imported into the archive.

Issue/Introduction

Some Move Archive jobs get stuck in the Verifying phase and never progress passed a particular percentage complete value. A review of the Move Archive Error log for the archive shows repeated recopies of the same source Saveset ID to a different destination Saveset ID on each occasion.

A dtrace of StorageOnlineOpns on the destination EV server will show that the transaction ID of the moved item is different to the original transaction ID. In addition, the error message "The specified Saveset does not exist. (0xc0041aac)" is logged in the dtrace as the destination server attempts to load the copied item based on its original (source) Transaction ID rather than its new (destination) Transaction ID.

This issue only affects source savesets that are in ANSI format. Unicode savesets are not affected. One possible source of ANSI savesets would be the import of ANSI format PST files (Outlook 97 - Outlook 2002) into the archive.