Archiving of some mailboxes stop occasionally - COM exception synchronising folder permissions

[Marcde]

Exchange 2010 SP3 UR14 (2 Multiroll members in a DAG), EV 12.0.3

From time to time archiving of around about 5 to 10 (always the same mailboxes) of 400 mailboxes stops until the corresponding archiving task gets restarted.  Archiving report simple shows: Completed: no eligible items and in addition to that it shows initial count of mailbox items = 0 while at the same time initial size is filled. 

Tracing the archiving process gives us the following error: 

299 11:17:00.428 [36620] (ArchiveTask) <23492> EV:L {CFolderHelper::GetFolderSettings:#1180} Synchronising folder permissions for folder [Oberste Ebene des Informationsspeichers]
300 11:17:00.444 [36620] (ArchiveTask) <23492> EV:M {CSynchHelper::SynchroniseFolderPermissions:#735} (Oberste Ebene des Informationsspeichers) - Synchronising owning mailbox permissions to folder object
301 11:17:00.444 [36620] (ArchiveTask) <23492> EV:M {CSynchHelper::SynchroniseFolderPermissions:#754} (Oberste Ebene des Informationsspeichers) - Request to synchronise on a different user
302 11:17:00.444 [36620] (ArchiveTask) <23492> EV:H {CSynchHelper::SynchroniseFolderPermissions:#1101} (Oberste Ebene des Informationsspeichers) - COM exception synchronising folder permissions, [0x80040115]
303 11:17:00.444 [36620] (ArchiveTask) <23492> EV:H {CFolderHelper::GetFolderSettings} HRXEX fn trace : Error [0xc0040d9e],.....

Oberste Ebene des Informationsspeichers = Top of Information Store

Using a Kemp Loadbalancer. Issue is happening independent from the active DAG member. Working around the loadbalancer does not change anything. DS Server key is set. affected mailboxes seem to be stored on different exchange databases. Eventlogs does not contain any errors. 

Any Idea about why it always fails on the same mailboxes? Anything specific we could check for the mailboxes? 

[GertjanA]

Hello Marc,

These kind of issues are really hard to fix. As you say it happens to only 5 to 10 mailboxes, being the same every time, what do they have in common? Are they large? Do they have many items? Many folders? Have you tried disabling them from archiving, zap the mailboxes, enable them for archiving, sync them again? Maybe the hidden message is corrupted somehow.

Regards,

GJ

[Marcde]

Hi Gertjan,

thanks for replying. I am currently comparing some of the dtraces I captured yesterday but for now I did not find anything in common. Different databases, different ous for the user object, small as well as huge mailboxes. I have to correct my initial statement as some of the mailboxes are changing per occurences and some are always listed. However did a zap for one mailbox yesterday and waiting for the situation to occur again which usually takes some days after restarting the task.

I'll update when finding anything useful. 

Regards,

Marc

[GertjanA]

Hi Marc,

You might want to implement the registry keys as descibed in this article.

GJ 

[Marcde]

Hi Gertjan,

thanks - the technote is well known but we would like to get rid of the root cause in the first place. Seeing this as a last resort. 

Regards

Marc

[Marcde · Accepted solution]

We kind of sorted this out by working around the loadbalancer. Even though it seemed to not work at the beginning it's working now since a few weeks without any issue. 

Marc

[GertjanA]

Hi Marc,

I assume you used the hostsfile to point directly to the exchange server(s), or the CAS?

A brief explanation might assist others facing the same issue.

Thanks, good to hear it is solved

[Marcde]

Hi Gertjan, 

please excuse the late reply. Yes that is exactly what we did.

We pointed it to one of the multiroll servers (via hosts file) which is not the best solution as we need to change it when the one that we used is unavailable or under maintenance.

One more thing to add: We are facing a similar issue in another environment where this solution is not working.I'll update this post when we do find another / additional solution

Regards

Marc