SOME archive pending items remain pending for a looooong time

OK so first couple of questions,
What version of enterprise vault? what version of exchange?
What is your leaving policy like from an AD side? are you disabling or hiding the mailboxes?

EV 9.0 SP1

Exchange 2007

Leaver AD accounts are disabled and mailboxes are hidden. I have had the registry settings to allow archival of hidden and disabled accounts since... forever.  I still have to babysit the leavers and manually synchronize them and also manually run archive task against them.  I wish Symantec designed a better approach for hidden/disabled users, but that's for another topic.

They do get archived. And most of their messages get processed just fine. Just some messages get stuck in the pending state for a long time. And some of those stuck messages get completed when I poke them by running the task in report mode.

i'm wondering why you bother to create shortcuts in mailboxes for leavers

Actually I don't create shortcuts for the leavers. I was too lazy to spell out all the details in my original post  :)

For the leavers, items turn to archive pending and then after a successful backup they normally disappear.  Except for some items in some leaver mailboxes.

Hi,

I've seen this issue with some corrupted emails within mailboxes, the solution beeing to identify and delete those particular items.

Can you have a look on the EV events and see whether can spot something related to that. Also, a dtrace on the archiving task might give us more clues.

Cheers,

Virgil

There are a few other things here as well.

First off to note though that if the email item is corrupt it in all likelihood would fail outright to even archive it in the first place. If there is some unexpected malformed attribute on the message that could result in odd behaviour and may be necessary to implement a code change to address that. However that would require sample messages to be investigated and solution identified.

Are you using Sharing within a Vaultstore Group within your environment? As per the previous post do you see any errors in the event log when you process these messages? If you are familiar with Dtrace could you run that as well on the ArchivingTask when you do the Shortcut processing so that you can tell from that whether there are any errors or specific information pertaining to the messages being reported.

It might be necessary to confirm what the state of these messages are within the Watchfile and JournalArchive tables for the respective Vaultstore DB and then correlate those entries as well to the Fingerprint DB to confirm that there is consistency across the board pertaining to their backup state and any SiSParts. Something worthwhile checking would be to note whether the messages left behind potentially have large attachments or large Bodies (content).

In order to do the above it may well be necessary to open a support case for further investigation.

Another thing to take note of would be there is a known issue with StorageFilewatch which is the process that is responsible for determing backup states of savesets/ Cab's etc and ensuring that these are correctly reflected in the Database. However as part of checking Sisparts it will need to extract the relevant sispart from the CAB to ensure its integrity before doing in post processing. This could under some circumstances result in a lock being put on the CAB and it never gets released preventing any other checks from being performed and the only around this is to reboot the server in question. If you are seeing any Cab file mutex errors this would be a strong indicator of this issue providing you utilize this functionality and could well prevent the messages from being finalized. The fix for this is in EV10.0.1

Hope this helps.

Thanks.

We don't share across the vaultstore Group, but we do share within a vault store (among vault store partitions).  Oen of the reasons for not sharing across the vaultstore group was that I didn't want one EV server to depend on the other EV server for things like this.

Still, something to check. I will play with DTrace.

Cleaning out MAPI permissions helped with some users.

There were still some other users that continued with archive pending. It turned out this was because our retention policies had a checkbox [that we turned on intentionally] to prevent item deletion.