CMAPISession::GetExchangeServerDnFromSession() error on synchronization run

[Christian_Fiedl]

Hi,

After several weeks of normal operation our system has problems on synchronizing.

Our Setup:
1 Enterprise Vault Server 6.0 SP1
4 Exchange Servers 2003

Problem arises after enabling about 300 mailboxes (about 100 a day).


Here is what happens:
Syn run starts (scheduled at 1 am)

A few seconds later Event 2776 shows up (An exception occurred in routine CMAPISession::GetExchangeServerDnFromSession())

One second later Event 3310 shows up (problem accessing network service or ressource, sleep 10 minutes)

After that the Archive task keeps retrying every ten minutes without success.

There are some entries in the exchange servers' a6 queue.

Restarting the archive tasks seems to help temporarily, sometimes restarting fails, because of a timeout. Starting affected tasks manually works.

Rebooting server also fixes the problem for some time.

Searching the knowledge base I found an issue that might be related (Document ID 278530)

Thanks for any hints in advance!

Regards
Christian

[TonySterling]

Are you stopping the tasks nightly?

[Christian_Fiedl]

No, we do not stop the tasks nightly. I just restarted the tasks for troubleshooting.

We use a site schedule for archiving. All sync tasks start at the same time for all the servers. Do you think the server lacks of some ressources?

Friday night Enterprise Vault is set to read only for a cold backup (using a script to stop some services, set some registry keys and start services again. This script is provided by Symantec).

After backup a second script puts EV into R/W mode. Since last weekend is over and I rebooted the server yesterday evening, it should be in a clean state now (except that I restarted the tasks today in the morning).

[Micah_Wyenn_2]

Whelp,
Without a dtrace (which you should post), it feels like a mapi error. I would recommend resetting the password for the VSA on the directory properties, as well as check the AD account to ensure that everything looks good there.

When that turns out to be a lark, your next step is to check the exchange permissions (both delegation and security settings) on the exchange server mail stores.

micah

[Christian_Fiedl]

Hello again,

checked permissions, passwords etc. Seem to be ok.

I changed Profile Expiration for abandoned profiles from 3 to 2 days and restarted tasks yesterday. Today no errors showed up after nightly archive run.

Seems to be ok for the moment. Will continue observation...

Thanks for your replies.

Regards
/chf

[Micah_Wyenn_2]

Weiiird,

I usually set that key to 2 as part of my routine for installs, but I never woulda guessed why that would fix the problem. 'course, it might be just masking the problem for 2 more days. Post back if that really does fix it for good.

I wonder if there's some sorta profile limit or something...wait a sec, what version of mapi files are ya running, dll and inf? Toss me file sizes too. I'm curious 'bout something.

micah

[Christian_Fiedl]

I don't know if this is the final fix. In previous best practices I read that restarting archiving tasks is recommended every night - I only set EV to readonly as part of the fullbackup. Maybe I set up a regular task for that. What would you recommend?

Here is what I found on server's C: drive:

MSMAPI.DLL: 1.414.344 bytes, version 11.0.8002

mapisvc.inf: exists 2 times:
c:\windows\system32: 3962 bytes
c:\program files\common files\system\MSMAPI\1033: 17860

Have to add that this file was changed as part of a hotfix regarding attachments without file extensions.

MAPI32.dll exists 3 times (+ an evbak version)
c:\windows\system32: 1.0.2536.0, 115200 bytes
c:\program files\exchsrvr\bin, 6.5.6944.0, 634880
c:\program files\common files\system\MSMAPI\1033, 1.0.2536.0, 137816
c:\windows\system32\mapi32_evbak.dll, 6.5.6944.0, 634880

Regards,
/chf

[Michael_Bilsbor]

Hi,

Yes, if you do not restart your task controller (V6) or all agents(v5) then you will encounter issue.

Fact is EV uses MAPI and suffers from memory leaks. Only by stopping the service will leak memory be freed.

I cannot say that the issue you are encountering is due to this exact problem but certainly it's an essential thing you need to be doing.

[Glenn_Martin]

This is good to see, I now don't feel so lonely anymore; I have an ongoing case to resolve these issues and progress is slow but I realise there's no easy fix yet.

However, in order to clean things up before and after the synch I've decided to restart the Task Controller before the synch's (to clear any MAPI issues) and then another restart after the synch's are finished. Ok, it's early days for me but so far I've seen a reduction of the 3310's . The only sure way to fix these is at least an Archive Task restrart otherwise they will scroll away all day without fixing themselves..

Ok, this isn't a fix but I'm reckoning it's not a bad way to keep things clean and running optimally and hopefully reduce the number of times our users complain that their restores or manual archives aren't working properly.

I was actually starting to think using MOM to spot the errors and then bounce the Task Controller, it would be good if I could just restart the relevent Task but of course there's no programatic way of doing this....if only there was a COM interface to EV to do such things we could script away.

I'll feedback on my success or otherwise with the strategy.

[Christian_Fiedl]

Will try the same.
Established to "at" jobs on the EV server to restart Task Controller Service before and after sync runs.
Let's see if this works better....

Regards Christian

[Glenn_Martin]

Well I have to say we're seeing a lot less errors durring our business day now, it's not completely clean but it way much better. For me, this shows that we have an issue durring the synch process so I'd say until the cause is clear, it's got to be a good practice to isolate the sych and restart before and after. I'm continuing to work with support on this and hopefully we'll get to the root cause.

Glenn

[Christian_Fiedl]

Same here....

Some "usual suspects" with regard to corrupt messages who create an eventlog entry every day.

Some weird exceptions from time to time (might be related to corrupt messages or not).

But at least the MSMQs are empty in the morning (except a5, but thats ok). Well there is one message pending and caused some errors, but hopefully it can be processed sucessfully tonight).

Plz keep the forum informed about your progress. Maybe we can further share experience.

/chf

[Michael_Bilsbor]

Hi,

You can stop and restart particular tasks using evservices.exe (or perhaps that's evservice.exe)

[Michael_Bilsbor]

By the way if you are going to discuss this please mention your Outlook 2003 service pack level. It's possible the issue could be related to a particular service pack of Outlook 2003 for all we know....