Shortcut deletion not working for draft items

[Natalia_B_]

Hello Forum,

has anyone else had problems with shortcut deletion of draft items?

Situation:

• EV 9.0.2 environment
• Draft items get archived via policy (verified using archive explorer)
• Draft items are not converted to shortcuts (TECH76747)
• shortcut deletion is configured to remove shortcuts after 1 day
• storage expiry is activated but not scheduled to let shortcut deletion occur
• regular shortcuts get deleted correctly after one day

TECH76747 describes that the draft items should get deleted even though they are not converted to a shortcut (message class still IPM.note).

Selected Item Properties of such an element:

SELECTED ITEM PROPERTIES

IPM.Note:

Subject draft 50

Last modification time 17:35:43, 10.10.2011

[...]

Archived Date 17:35:47, 10.10.2011

Calculated Date 17:34:54, 10.10.2011

When running shortcut processing a DTrace of Archive Task shows the following:

418 07:18:22.262 [3092] (ArchiveTask) <5544> EV:M :CArchivingAgent::ProcessChunkOfShortcuts() |Entering routine |

419 07:18:22.262 [3092] (ArchiveTask) <5544> EV:M CArchivingAgent::ProcessShortcutItem - processing shortcut 'draft 50', size 24945 bytes

420 07:18:22.262 [3092] (ArchiveTask) <5544> EV:M CArchivingAgent::ProcessShortcutItem - offline vault user F, shortcutexpiryperiod 1, deleteexpireditems T, orphanedshortcut T

421 07:18:22.262 [3092] (ArchiveTask) <5544> EV:M CArchivingAgent::ProcessShortcutItem - blanket deletion is turned off for non-shortcut items

422 07:18:22.262 [3092] (ArchiveTask) <5544> EV:M CArchivingAgent::ProcessShortcutItem - Using default ExpiryDateBasis: Archived Date

423 07:18:22.262 [3092] (ArchiveTask) <5544> EV:M CArchivingAgent::ProcessShortcutItem - Expiry Basis on Retention Category: [INHERIT FROM SITE]

424 07:18:22.262 [3092] (ArchiveTask) <5544> EV:M CArchivingAgent::ProcessShortcutItem - Expiry Basis on Site: [Archive Date]

425 07:18:22.262 [3092] (ArchiveTask) <5544> EV:M CArchivingAgent::ProcessShortcutItem - shortcut status flag has been set on the item with value 3

426 07:18:22.262 [3092] (ArchiveTask) <5544> EV:M CArchivingAgent::IsAMovedItem - retention category matches [true]

427 07:18:22.262 [3092] (ArchiveTask) <5544> EV:M CArchivingAgent::IsAMovedItem - archive folder id matches [true]

428 07:18:22.262 [3092] (ArchiveTask) <5544> EV:M CArchivingAgent::IsAMovedItem - item has moved [false]

429 07:18:22.262 [3092] (ArchiveTask) <5544> EV:M CArchivingAgent::ProcessShortcutItem - 'draft 50' has not moved so do checks to see if it is eligible for shortcut deletion

430 07:18:22.262 [3092] (ArchiveTask) <5544> EV:M CArchivingAgent::ThinOrphanedShortcutCheck()

431 07:18:22.262 [3092] (ArchiveTask) <5544> EV:L :CArchivingAgent::ProcessChunkOfShortcuts() |The shortcut titled: draft 50 will not be deleted |

Any ideas?

[RahulG · Accepted solution]

Do you have vault cache enabled ?

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

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

[Natalia_B_]

Thanks Rahul, this was indeed part of the issue. After setting DeleteNonShortcutItems to 1 the drafts get removed. However TECH76747 should be corrected then as drafts are apparently not treated as shortcuts regarding shortcut deletion..

One further problem, again regarding drafts in the same environment:

If a PST file (containing drafts) is imported via PST Import to the archive, these drafts are archived and shortcuts are created in the respective folder of the PST Migration. These are full shortcuts, still working, however they are NOT deleted by shortcut deletion (they are not even mentioned in the DTrace..).

Non-Draft Elements from the PST Migration are deleted as expected.

Any ideas?

[RahulG]

You may try and see if the following registry help . I am not really sure if it will help .

HKLM\Software\KVS\Enterprise Vault\Agents
IgnoreEVDates

0 = Off
1 = Ignore Archived date
2 = Ignore Restored date
3 = Ignore both Archived and Restored date

I would suggest you to open a support case for this issue  as it seems to me that it is a bug.