cancel
Showing results for 
Search instead for 
Did you mean: 

ShortCut Processing Error in 9.0 SP1

Weasel
Level 5

Hello,

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:

Eventid 6578:
Abnormal error occurred
Object: CRetentionCategoryCache
Reference: LE/RE
 

Eventid 6578:
Abnormal error occurred
Object: CRetentionCategoryCache
Reference: RE(1)/fe

Eventid 2270:
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")
HRESULT: 0x80004005

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?

 

Regards

1 ACCEPTED SOLUTION

Accepted Solutions

Weasel
Level 5

Hi all,

I have got a message from sym support with this link to a hotfix for this and other issues:

http://www.symantec.com/docs/TECH153457

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.

View solution in original post

50 REPLIES 50

JesusWept3
Level 6
Partner Accredited Certified

I have the same errors
Create a case with support, cross reference case #413-396-627

https://www.linkedin.com/in/alex-allen-turl-07370146

GertjanA
Moderator
Moderator
Partner    VIP    Accredited Certified

The below link mentions something about shortcut expiry.

This one: http://www.symantec.com/docs/TECH73137
Might this be the issue?

Regards. Gertjan

Weasel
Level 5

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.

Nick_White
Level 6
Employee

I think a dtrace of the Archiving Task is going to be the best step forwards here as we will need to see what is happening in the background when the event is logged

Weasel
Level 5

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.

BigPhil
Level 5

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.

zmcmanus
Level 2

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

JesusWept3
Level 6
Partner Accredited Certified

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

https://www.linkedin.com/in/alex-allen-turl-07370146

Weasel
Level 5

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.

FreKac2
Level 6
Partner Accredited Certified

Seems that one of my customers have the same event.

Will check if it's exactly the same behaviour but the event looks the same.

zmcmanus
Level 2

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?

FreKac2
Level 6
Partner Accredited Certified

You can disable the "Moved Items" features in the mailbox policy (Mbx Policy->Moved Items tab).

zmcmanus
Level 2

Fantastic! I had completely forgotten to check the policy settings for that.  Thank you very much.

Weasel
Level 5

ShortCut-Processing can be deactivated in the mailbox policy. Uncheck the option to update archive location for items moved in the mailbox on the Moved Items tab.

James_Herbert
Level 5

Morning All,

 

Did you find the long term fix for this?  We have just upgraded to 9.0.1 and are experiencing this issue

Weasel
Level 5

I spoke to technical support last week. Did not hear something about any solution.

vmds
Level 5
Partner Accredited

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.

 

James_Herbert
Level 5

Thanks.  What are you currently doing as a work around?  Just disabling the ShortCut-Processing

GertjanA
Moderator
Moderator
Partner    VIP    Accredited Certified

Don't know which supporter, but this feature works fine in 8...

Regards. Gertjan