Problems with error when moving archive.

EV version? Source and destination...

Hi,

Moving from EV 9.0.2 -> 10.0.2, I ran a Dtrace and got another errorcode that I put in EVMoveArchiveTask.exe.config so now the move is running :).

Glad to know... :)

Henfo,

The move archive 'NonFatalHexCodes' value should commonly only be used as a last resort as it will cause the Move process to ignore listed failures that would normally fail the move process.  9.0.2 had a couple of issues related to how storage handled damaged legacy items (pre-8.0 stored items) so I would recommend upgrading to 9.0.4 if you can and test without the NonFatalHexCodes set as this is a bandaid and not addressing the real issue.

Here's an example of one of the fixes:

http://www.symantec.com/docs/TECH169017
The Move Archive process fails during Copy phase with "Inner storage error code: 0x80004002"

When there is a Move Archive failure during the copy stage, you can test the individual items using EVSVR - Dumpsaveset to confirm the item is retrievable from storage.  See below for details:

http://www.symantec.com/docs/TECH75791
How to extract the Saveset and SIS parts of a specific archived item using EVSVR.exe

I hope this helps.

Ok,

The error I got in the log is:

"An internal failure occurred. Internal Error: '<0x80040e14>"

Dtrace of the move shows:

1124 15:05:40.660  [11888] (EVMoveArchiveTask) <8104> EV-H {MoveArchiveItem.HandleException} Exception thrown for item F1515667F34EB6DA6EDD7E18C9D1FA41. Exception: System.Runtime.InteropServices.COMException (0x80040306): An internal failure occurred. Internal Error: '<0x80040e14>'.|   at KVS.EnterpriseVault.Interop.IItem.Insert()|   at KVS.EnterpriseVault.MoveArchiveTask.ItemProcessor.CopyItem(QueuedSourceItem sourceitem, IContentManagementAPI4 cmAPImaThread, String& srcSSID, String& destSSID)

11125 15:05:40.660  [11888] (EVMoveArchiveTask) <8104> EV-H {MoveArchiveItem.HandleException} Item with transaction id F1515667F34EB6DA6EDD7E18C9D1FA41 could not be inserted. Error: . Error code: 0x80040e14. Non fatal error.

I can dump the saveset to disk and read message.

/Henfo

Henfo,

I've seen the "0x80040e14" error be the result of a SQL error on the destination.  Specifically, failure to insert a duplicate row in the destination vault store DB.  Check your event logs on the source for any 13360 errors with "Cannot insert duplicate key row in object 'dbo.Saveset' with unique index 'IX_IdTransaction'."

If this is what is happening, then check the destination Vault Store to confirm the transaction is already there and what archive it is in:

a. Take the transaction and convert it to IdTransaction format:
Example from the reference above - F1515667-F34E-B6DA-6EDD-7E18C9D1FA41

b. Perform the following SELECT query on the destination vault store DB:

SELECT IdTransaction, IdDateTime, ArchivePointIdentity
FROM Saveset
WHERE IdTransaction = 'F1515667-F34E-B6DA-6EDD-7E18C9D1FA41'

c. If this returns a result, record the ArchivePointIdentity

d. Run the following SQL Query against the Vault Store DB to get the ArchiveID of the user:

SELECT ArchivePointID, ArchivePointIdentity
FROM ArchivePoint
WHERE ArchivePointIdentity = 'VALUE FROM b'

e. Record the ArchivePointID.

f. In the Vault Admin Console (VAC), Hold Shift+Ctrl and Right-click Archives.
- This will give a new option to Find Archive or Folder.

g. Paste the ArchivePointID here to find what archive the item is associated with.

It is very rare, close to impossible, to have a duplicate transaction randomly generated. Most commonly, this can be due to there being 2 archives on the destination due to a reattempt to move the archive from scratch and selecting new archive, even though an archive already exists there.  If this item is located in one copy of the user's archive, yet you are now moving to a second instance of the users archive in the same site, the move will fail due to a duplicate record that does not exist in the archive you are moving to.

Is there more than one archive now in the destination site for this user?

I hope this helps.

Henfo - Are you still having the above error during the move?  Were you able to identify if there was 2 archives for the user on the destination?

Hi,

I checked but found no error 13360 in the log, and there is only one archive at destination site for the user.

/Henfo

Hi again,

Made a retry on the move and now I get alot of 13360 errors on the destination site, because of the items already moved before?.

No duplicate archive for user at destination.

/Henfo.

Henfo - The error you provided on the 12th, references that the transaction already exists on the destination vault store.  When you ran the following query, did it return any results on the destination?

SELECT IdTransaction, IdDateTime, ArchivePointIdentity
FROM Saveset
WHERE IdTransaction = 'F1515667-F34E-B6DA-6EDD-7E18C9D1FA41'

- If so, is the item referenced in the destination archive you are moving to, or a different archive?

When Move Archive moves items, it will use the same IdTransaction on the destination.  By default, when MA encounters a duplicate item on the destination archive, it will skip it and move on.  If it encounters a duplicate transaction on the destination Vault Store, yet NOT in the destination archive, it will cause the failure and error out. 

I have seen a situation where a 'legacy' method of move is performed via PST export and import will cause confusion with the MA when determining if the item already exists in the destination.  The reason I believe was because PST exports-imports will alter the archiveddate value while Move Archive will not.  So when Move Archive see's the destination item with an alternate archiveddate, it thinks it is different from the moved item and so will fail.

There is a config settting named 'SkipDuplicates'.  This setting alters how MA reacts when encountering a duplicate IdTransaction on the destination vault store that is not in the destination archive.  With this value at 0, this situation will fail the Move.  If this is set to 1, it will skip the item and move on.  Caution should be used on this option since it does skip moving items it perceives on the destination.

I hope this makes sense.