Enterprise Vault 10
We are getting 2270 errors against corrupt items being logged every now and again. I can't open the message in Outlook and can't do anything with it (move, delete etc.)
The strange part is that the event is logged and then the journaling server stops processing for exactly 24 hours before processing the offending message and continuing (there's nothing else logged against it). It doesn't remove it or drop it out the queue, it actually processes it like nothing happened and moves on.
It's not just the one task on the EV server stops though - we have 5 other tasks processing journal mailboxes and the entire server just seems to stop dead for 24 hours.
I've tried using MFCMAPI to remove the message but all I get is access denied to the message (any other message can be hard deleted fine).
I've tried running a corruption repair via powershell against the mailbox (hosted on exchange server 2010).
This is happening quite regular - we have 2 million messages per day being archived and is causing us significant backlogs when it occurs.
Has anyone seen anything similar or can shed some light on where to look next? We've got a support case open but haven't had much success so far in tracking it down.
I assume you've gone through https://www.veritas.com/support/en_US/article.000020478 ?
Have you tried moving the mailbox to another DB with a 'BadLimitLimit' gretear than 1 (i.e. corrupt messages get left behind)?
Does the Journal mailbox have a quota set? have you tried removing it for the mailbox?
I've seen the article you're referencing but I think that is for user mailbox archiving, not journaling (correct me if I'm wrong) - we see no HEX/HRESULT codes to reference the exact error detail.
We've not tried moving the journal mailbox yet - but I don't actually think the item is genuinely corrupt. It disappears precisely at 24 hours after the 2270 is logged and is archived. It's like something in EV has grabbed it and won't let anything else touch it... MFCMAPI or Outlook, If the item was genuinely corrupt then it should be getting dropped into the subfolder, from my understanding.
And definitely no quotas. Given that we had 20 million messages queued at one point it's safe to say there are no quotas...