Duplicate items are appearing in the archive due to multiple archiving instances of the same content.

Problem

Duplicate Archiving Behavior with Specific Archiving Policy Configuration

Items may be archived multiple times, resulting in duplicate entries within the archive, when the following archiving policy settings are applied:

• Age-based Archiving Policy: 0-day (archive items immediately upon eligibility)

• Shortcut Creation: Disabled (Do Not Create Shortcut)

• Original Item Handling: Do Not Delete Original Item

This configuration causes the archiving process to retain the original item in the source mailbox while also archiving a copy. On subsequent archiving runs, the original item remains eligible, leading to repeated archiving and duplication in the archive.

Error Message

"No errors are observed in the Event Viewer. However, the following snippets may appear in the DTrace logs during archiving:

(ArchiveTask)    <5136>    EV:H    {CExchangeShortcutAccessor::SaveChanges:#7860} Wrapper SaveChanges() returned error code [0x80004005], Input Flags [2]. Retry with FORCE_SAVE flag.
(ArchiveTask)    <5136>    EV:H    {CExchangeShortcutAccessor::SaveChanges:#7865} Wrapper SaveChanges() returned error code [0x80004005], Input Flags [6] with FORCE_SAVE flag.
(ArchiveTask)    <5136>    EV:H    {CExchangeShortcutAccessor::UndoMarkForArchiveEx:#3156} IMessage::SaveChanges returned error code [0x80004005]
(ArchiveTask)    <5136>    EV:M    {CExchangeShortcutAccessor::InternalCancelPending:#5776} ::InternalCancelPending() - An error occurred 0x80004005
 

Cause

This issue has been predominantly observed with large items.

When an item is archived, Exchange’s BigFunnel Indexing Engine is triggered to index the item. During this process, it updates certain MAPI properties, including the PR_LAST_MODIFICATION_TIME. It’s important to highlight that the BigFunnel Indexing Engine does not modify the content of the item itself, so any changes made during indexing should not affect the item’s archiving eligibility.

However, since the PR_LAST_MODIFICATION_TIME property is updated to a timestamp later than the configured ArchiveDate, the item appears eligible for archiving again in subsequent runs. The time difference between PR_LAST_MODIFICATION_TIME and the ArchiveDate can vary from a few seconds to several hours.

Because PR_LAST_MODIFICATION_TIME is used to determine an item’s eligibility for archiving, this property becomes unreliable when the Exchange Indexing Engine updates it post-archiving. Consequently, items are repeatedly selected for re-archiving due to these modifications, causing duplicate entries in the archive.

Solution

Controlling Re-Archiving Behavior Using the ‘ReArchive’ Registry Setting.

To address the issue of items being archived multiple times due to changes in the PR_LAST_MODIFICATION_TIME property, a new registry DWORD setting named ReArchive will be introduced.

This setting controls whether items that already have an archived date should be considered for re-archiving when their modification date changes.

• Default value: 1 — Items will be re-archived even if they already have an archived date.
• Value 0: Prevents re-archiving of items that are already archived, even if their modification date changes

            HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\KVS\Enterprise Vault\Agents
            ReArchive = dword:00000000

Note: The above setting only applies to EV version 15.2.1 or later.

EV 15.2.1 can be downloaded from here (Veritas Downloads).