Storage Expiry leads to unwanted shortcut deletion
Hi @all,
I have some trouble with a EV installation and I need your thoughts here:
It´s a brand new installation with 12.3 and is planned for Mailbox and Journal Archiving.
All items which were archived from the journal mailboxes should be deleted when the retention time is expired. The user should be able to delete items in his own archive.
I´ve configured two retention categories for this both purposes:
Journal Retention Category:
Period: 1 Day (because of testing purposes: should be adjusted after the pilot phase)
Settings: "Prevent automatic deletion of expired items whit this category" is checked (also only for testing purposes)
Settings: "Prevent user deletion of items with hits category" is checked
Mailbox Retention Category:
Period: 1 Day (final setting, users should be able to delete items immediately )
Settings: "Prevent automatic deletion of expired items whit this category" is checked
Settings: "Prevent user deletion of items with hits category" is unchecked
Site settings:
Storage expiry is scheduled for every night based on "Archived date".
Now we started the pilot phase and archived some user mailboxes. The journal mailboxes were not filled - so there is no journal content written.
After successful archiving and shortcutting in the mailboxes one day later all shortcuts in the mailbox were deleted. It turns out that the storage expiry was responsible for this deletion. In a dtrace we could see that the shortcut was deleted:
EV:L {CRetentionCategoryCache::GetRetentionCategoryData} (Entry) Retention category [19CB97BB50878DE4194D424D8315179401b10000DALLIEVA001]
EV:M {CArchivingAgent::ProcessShortcutItem:#12650} shortcutexpiryperiod: [0], deleteexpireditems: [True], orphanedshortcut: [False], update moved items and their RCs: [True]
The shortcut titled: XXX will be deleted due to its retention category expiring
For my understandig this couldn´t be the expected behavior. In the mailbox retention category is explicitly configured "Prevent automatic deletion of expired items whit this category" so the shortcut expiry shouldn´t process the archived items. And by the way: the corresponding archived items were not processed/deleted by the storage expiry, only the shortcuts were deleted.
I´ve opened a case for this issue but it was closed by the backline after a few weeks with the following solution:
Shortcut Expiry is expected behavior. If Storage Expiry is scheduled on the Site settings, then Shortcut Expiry by retention category automatically occurs whenever the archiving task is run.
See Article ID:100006796 ,
https://www.veritas.com/support/en_US/article.100006796 Shortcut expiry is deleting shortcuts when storage expiry is in report mode.
I think that isn´t a valid solution. The referred article is about another issue with the storage expiry in report mode.
How do you think about this behavior. What would be your expectation with this setting?
I know it doesn't seem relevant that the article is about expiry in Report Mode while you are not running that, but they both stem from the same issue. Here's why.
There are two components involved in expiry for this issue. There is the Storage subsystem, which handles expiry of the actual archived items, and there is the Archiving Task, which is the part of EV that talks to Exchange, and it handles the expiry of the shortcuts. From an architectural standpoint, these are very separate parts of EV, even though in this case both are collaborating to perform "expiry."
When Storage performs expiry on the archived items, it has a series of conditions it checks to determine whether an item is eligible to be expired. This obviously starts with the age of the item, but then it also considers things like the Retention Category's "Prevent automatic deletion..." setting, the archive's "Delete expired items..." setting, whether expiry is set to Report Mode on the Site, whether the items are on legal hold from a discovery product, whether another pass through the classification engine is required, and probably some more that I am forgetting.
When the Archive Task performs expiry on the shortcuts, it checks the age of the shortcut but it doesn't include a check on every one of those other conditions that Storage checks. In the article you cited, this manifests as deletion of shortcuts even though Storage Expiry is in Report Mode; in your case, it manifests as deletion of shortcuts despite the "Prevent automatic deletion..." setting on the Retention Category. But both stem from the basic underlying fact that Storage considers many more factors when deciding whether an item is eligible for expiry than the Archiving Task considers when deciding whether an item's shortcut is eligible for expiry.
While it certainly seems undesirable that the two components would make different eligibility decisions about objects that represent the same item, it is also true that there are performance and design drawbacks to attempting to duplicate all of the Storage logic in the Archive Task's handling of shortcuts. So that's the tradeoff we're dealing with in saying this is "expected behavior."
I hope that explanation answers more questions than it raises. :smileyhappy:
--Chris
