SOME archive pending items remain pending for a looooong time

[ANDREY_FYODOROV]

Hi all.

I have some mailboxes (leavers) who got archived a while ago, most their messages became archive pending and then got the "safe" icon.

But some messages just sit in the pending state.

I figured "let me cancel them by running the archiving task in report mode and try archiving them again".  Interesting result - some of these pending items became completed just by running the task in report mode.

But some go back to normal messages. Then I run the task in Archive mode, they go to pending, and stay in pending again.

My backups are just fine.

I also verified that all the files in the vault store partition lost their A flag.

Not only that, all the DVS files already got cabbed. I even traced the specific messages (using their transaction IDs and saveset IDs to the specific DVS files - and those DVSes are in CAB files already.

What is the EV server waiting for?

[JesusWept3]

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?

[ANDREY_FYODOROV]

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.

[AndrewB]

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

[ANDREY_FYODOROV]

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.

[VirgilDobos]

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

[Tremaine]

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.

[ANDREY_FYODOROV]

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.

[ANDREY_FYODOROV · Accepted solution]

Some of the mailbox folders had custom MAPI permissions that the users had set for themselves.

I had to use PFDavAdmin to wipe out the MAPI permissions, then run synchronization. After that, running the Archive task in Report mode completed the archival process.

P.S. Dtrace did not show anything for these items. This made me think "hmmm... it's as if these items are invisible... hold on... invisible... maybe it's the MAPI permissions messing everything up [again]??

[ANDREY_FYODOROV]

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.