Exchange mailbox archive task generates huge volume of logs on Exchange 2007 Mailbox server role

[jlstar]

We are having issues on large volume logs created on Exchange 2007.  Within 24 hours, it generates 46 GB of logs when the mailstore size it is only 42GB.

The logs will slow down on being generated after I stop/start the EV services ... this only happens to one mailstore.

To rule out Exchange mailstore corruption, I've moved all mailboxes out of that particular store and created a brand new edb and the log issue is still there.

Has anyone experienced this in your environment?

Message Edited by jlstar on 12-15-2008 09:13 AM

[MichelZ]

Hi

This is more or less normal behaviour, I think.

When EV archives and then removes items from the logfile, Exchange has to log those actions.

In the first few days, when EV does initial archiving, this is an additional load on the Exchange Server.

But once EV has finished the initial archiving, and only has to do "normal" archiving, it won't generate so much logs.

Cheers

Michel

[jlstar]

Our Exchange mailbox archiving task has been running for over 2 years and the behaviour is totally weird for acting up on only one mailstore.  We have 26 mailstores and it only happens to one particular mail store.

Anyways, I created a case for this because we need it resolved.

thanks for the comments though.

[Brian_Spooner]

Do you do any journaling?

[ChrisWenzel]

We had this happen when the task came across corrupt items in a mailstore.

Do the logs make any reference to a specific mailbox or item the task is having an issue with?

[jlstar]

No, we don't use journaling.

I thought by recreating the exchange mail store(edb file) would taken care of mailstore corruption.  But it happened again.

Do you know which logs on ev server or exchange 2007 server to check to find out what mailbox that ev is updating on exchange's transaction logs?  I tried tracing it on using exchange message tracking tools but I could not find anything.

I am currently monitoring the msmq on a3 queue because our task are all scheduled work and it was not supposed to have anything on a3 ... but there were 3500 items on it .. I've zeroed out ... so I am just waiting it to fill up.

[Michael_Bilsbor]

Hi,

Are you sure you're not doing any Run Now requests as that's what put requests onto a3.

[jlstar]

Yes I am sure ... the huge volume of logs were generated on sundays when no one is working.
If it is corrupted item, I need to find it and remove it.  Just the fact that it is going to the wrong queue is already an issue.  I can't just let EV generates so much logs on Exchange because we use the new Exchange SCR replication, the amount of logs would choke our network link between the data center and the remote site.

I also can't be babysitting the a3 to ensure that it always zeroed out.

[James_Herbert]

Hi,

Did you every get to the bottom of this problem as I'm experiencing exactly the same issue at the moment with our Exchange logs filling up every Sunday?

You'd be a life saver if you did

Thanks
James

[SDA]

This happened recently at one of my customers.  A while back they changed the amount of text in their shortcuts.  Support had them put the restore shortcut registry key in place.  This causes vault to re-process every single shortcut which causes a huge volume of transaction logs.  And because of all the processing, it seemed to only be happening to a couple databases.  Issue was that it could never get through all the shortcuts in the one or two databases to move on to the rest.   http://seer.entsupport.symantec.com/docs/282855.htm

[Gonz]

 Very recently I had a customer with exactly this problem.

The root of the problem was that the customer was upset because the size of the shortcut was higher than the expected. He decided to remove the "Recipient Information from the shortcuts" from the mailbox policy and modified the registry key 

HKLM\Software\KVS\Enterprise Vault\Agents

RestoreShortcutBody 1

 On Sundays Exchange went down as a result of transaction logs ocuppying all the available space in disk. Customer forgot to put RestoreShortCutBody to 0 after recreating the shortcut and created a problem.

I think SDA is correct suggesting http://seer.entsupport.symantec.com/docs/282855.htm as the cause of the problem.

Please let us know if this resolves your issue.

Kind regards.

[James_Herbert]

Thanks for the comments.  We made the registry change last week and touch wood we didn't have a issue with Exchange log files this weekend.

Fingers crossed this is the long term fix for our issue

[Gonz]

Please do not forget next Monday to post if this resolved the problem and mark the solution.

Regards.