cancel
Showing results for 
Search instead for 
Did you mean: 

Storage Expiry leads to unwanted shortcut deletion

Jakob
Level 5
Partner

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?

 

1 ACCEPTED SOLUTION

Accepted Solutions

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. Smiley Happy

--Chris

View solution in original post

11 REPLIES 11

Pradeep-Papnai
Level 6
Employee Accredited Certified

Hi Jacob,

IMO this is known issue (defect) mentioned in TechNote

Different mode of shortcut deletion is mentioned briefly in TechNote

  1. Blanket shortcut deletion (Age based shortcut deletion) - Configured via the mailbox policy --> shortcut deletion --> "Delete shortcuts in folders"
  2. Shortcut Expiry (Retention based shortcut deletion) - Enabled if "Storage Expiry" is enabled at the site level
  3. Orphaned shortcut deletion (Shortcut deletion for items that have been deleted from the archive) - Configured via the mailbox policy --> shortcut deletion --> "Delete orphaned shortcuts"

I agree the setting "Prevent automatic deletion of expired items whit this category" should stop expiry of items from EV as well as shortcut from mailbox. Again, I would recommend to contact A/C manager OR BCAM to track above defect OR enhancement in this area.

Regards
Pradeep Papnai

Hi Pradeep,

thank you for this TechNotes. But this issue didn´t only came up when the expiry runs in the reporting mode. It also happens in the regular mode. So it´s not really the same thing... 

And the technote is from 2013!?! 

I also will contact the Account Manager for this topic.

Jakob

GertjanA
Level 6
Partner    VIP    Accredited Certified

Hello,

What is the setting on Shortcut Deletion in the Mailbox policy?

The settings you refer to are for the actual archived items, not the shortcuts. It might be that because the item is expired, the shortcut now is orphaned, and thus removed.

Regards. Gertjan

Jakob
Level 5
Partner

Hi Gertjan,

the option to delete shortcuts is not checked. Delete orphaned shortcuts is also not enabled.

But as mentioned before: The archived items were not deleted, only the shortcuts for archived items which are theoretically affected were deleted... Very creepy!

By the way: In the single archive items setting the deletion protection settings are the defaults: "Delete expired items from this archive automatically". But to change this setting make also no difference. 

Jakob

 

Pradeep-Papnai
Level 6
Employee Accredited Certified

Hi Jacob,

In my understanding, it doesn’t matter if you run expiry in Normal OR Report mode. Once you set Schedule for expiry then shortcut will start to expire post retention period even though you are stopping EV item expiry using retention policy “Prevent automatic deletion of expired items whit this category”.

Just came across with one other defect TechNote that is opposite of your issue where shortcut expiry doesn’t happen even though actual item expired, leaving orphaned shortcut because of schedule is not selected.

I am not sure about the current status of all these old defects, possibly you can raise support case and get official answer.

Regards
Pradeep

I´ve already opened a case for this but it was closed with the resolution:

"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."...

The helpdesk at Veritas Support was able to reproduce this behavior and escalated it to the backline which has closed it with the "expected behavior" solution.

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. Smiley Happy

--Chris

View solution in original post

Hi Chris,

thank you for this realy good explanation of the expiry parts of EV. It helps me to understand why it is like it is. 

But from the customer/user/admin view it isn´t "expected behavior" at all if the expiry routines delete shortcuts automatically although the admin has configured not to delete this shortcuts autmatically.

@ChrisLangevin do you have an Idea when Veritas will solve this?

 

GertjanA
Level 6
Partner    VIP    Accredited Certified

Hello Jakob,

If engineering states it 'works as designed', they'll not fix it (I assume).

You might need to ask your AM to raise an enhancement request.

Regards. Gertjan

Yes, the old "expected behavior" line always leaves us with the question "expected by whom?" In this case, I agree that the admin may not understand that the options he is configuring to prevent the automatic deletion of items may not also prevent the automatic deletion of shortcuts. As Gertjan notes, this is the intentional design of the product, so we won't "fix" it like it's a defect; if you want to raise an enhancement request, then your account manager is the proper channel for that. In the meantime, the best thing we can do is educate customers and admins so that this design is not so unexpected anymore, which hopefully is accomplished by this thread.

--Chris

Ok Chris... i´m curios to see what the AM can do here.

We´ll see. Thank you for the explanation so far!