we are running EV 9.0 SP1 with Exchange 2007 SP3.
Recently I upgraded from 9.0.0 to 9.0.1. Nothing else changed and everything worked fine before this. But now the shortcut processing produces a lot of errors:
Abnormal error occurred
Abnormal error occurred
A queued operation exceeded the retry count and has been discarded
m_pIBackgroundArchivingAgent->ProcessMovedItemsInFolder2(ExchangeMailboxDn = "/o=ardenne-at/ou=Erste administrative Gruppe/cn=Recipients/cn=OFFICE",
ArchiveID = "1266E621CC231C34B9318C4CEFC9CB4381110000EVSite.2a-net.intern",
ArchiveFolderID = "1F6E0CE30F4A03D419D01C4BA3091E8C11110000EVSite.2a-net.intern",
FolderRetCat = "",
SourceFolderID = "ID",
FolderPathName = "�Posteingang�Ablage�01_Organisation�Strategie",
CompressedItemRequestXML = "some XML",
EVPMFolder = "FALSE")
I testet this by a manual run of the archive task against one mailbox with shortcut processing only. Pure Archiving works ok and I disabled shortcut processing now. I can see that the A6-Queue is full with all folders the mailbox contains, even if there are definitivly never moved any shortcuts.
I opened a case but did not recieve any answer from symantec yet. Anyone seen this effect too?
Solved! Go to Solution.
I have got a message from sym support with this link to a hotfix for this and other issues:
I installed the hotfix and at first look the moved items feature is working now. I will let run an archiving with shortcut processing enabled this night and monitor the a6.
My Case is #413-430-097
@GertjanA: I don't think that storage expiry is a problem. The errors occure during "process moved items" when processing the a6-queue. As far as i know this queue reflects to the folders containing moved shortcuts.
I will do a dtrace next monday.
I turned off the option to update moved items in the mailbox policies and archiving is working in normal way.
For a test I activated this option again and let the archiving task run. The a6-queue was filled with about 12000 elements! Never seen this before the upgrade. Every folder of every mailbox is now processed. This takes hours of time. In 9.0 this did not happen, a mailbox without moved itmes never appeared in the a6 queue and moveditems_updatesummary-logs.
This seems to be a bug for me.
I also have the same errors. EV 9.0.1 on Windows 2008 R2, Exchange 2007 SP3. I traced the Archiving Task when the errors are logged and sent it to a Symantec Engineer. I'll see what he says about it. If another symantec employee wants to look at the archiving trace, it should be in case 413-350-451. that case is a separate issue with Journaltask.exe failing that should be fixed with a hotfix on monday.
My MSMQ A6 queues all maxed out, for each Archive Task... I'd have to say that 9.0.1 introduced this error since my sites have never had this issue prior.
I have unchecked the default maximum size limit for each A6. The queues are continuing to grow now, at least until I can get an answer from Symantec on it...
turn it off, if you let the queues grow and grow and grow, you will just cause instability by the MSMQ breaching its quota, and plus the amount of time EV will take to go through all those items just aren't worth it
So consider the fact that you have for exampe 100,000 items in your queue, that will take a long time to process to begin with, but then lets say that normally it would have taken a few minutes to process after its been reported, but now with this delay its taken a week.
What will happen is, if you wait 1 or 2 weeks to start processing that queue, and those users have moved or deleted the items again, you are now going to see errors from the archiving task where it couldn't update because the shortcut has been moved or deleted.
You are best of purging the queue, turning the feature off, working with symantec and then when it is fixed, re-enabling it, and then it will go through and process the items again.
Also what is happening in our case is because of these bugs we're actually getting a lot of blacklisted shrotcuts, when it attempts to update, but fails, and then tries again, and then after the 3rd attempt if it cannot update it, it will mark it so that it does not attempt to process it again.
There is no use in letting the queues fill up, will just cause more issues
I sent the dtrace-log to symantec support. It takes about 24 hours to process about 12000 items in the a6 queue, so I turned this feature off until this is solved. I will not change the Queue Limit, this makes no sense.
When you guys are saying you just turn the feature off, are you talking specifically about shortcut processing? I didnt think you could just do archiving and not shortcut processing, unless you are triggering them manually?
We have the same error in our environment. After opening a case, the workaround I got was to disable archiving and then to enable update moved shortcuts + shortcut processing bit by bit for each archiv, so the A6 queue process the items without getting brimmed.
According to the supporter, that update moved item feature never worked and must have just started working in EV9 SP1.
So far, doing it one by one works ok. The A6 queue doesnt get crowded anymore and the errors went away.