Our Exchange Servers (2003) are managed by a 3rd party company. During weekends sometimes they restart one of the Exchange Server / Active Directory / Global Catalog Server without notifying us. When users start complaining about sending messages from their devices we realize that there is MAPI communication problem. Restart of the BES (5.x) Services always fixes the issue.

Is there a way for us look at the MAGT log files and find out these issues proactively? Any other ideas on how we can better handle this (other than getting the 3rd party company to notify us).

Thanks,
Keith

Why not set as a part of the procedures in place that whenever they restart a mailbox server or domain controller the BES gets restarted?

Your question of "Is there a way for us look at the MAGT log files and find out these issues proactively?" is a bit impossible.

You want to find out proactively but you're going to look through the log files ... isn't that an oxymoron?

I guess I would look at the ALRT and CTRL log files around the times that they do these restarts to see if you see the same events showing up. You could then configure some form of alerting to send a notification based on these events.

You might try using the BlackBerry Monitoring Service or you might look to some other monitoring product that can do real time analysis of your environment (hint: look at the sponsors on this site for a starting point).

__________________
http://blog.port3101.org/hdawg/

The views expressed by me on Port3101 and its affiliated sites are my own and do not necessarily reflect the views of my employer.

Thanks for the info.

Proactively - before the users start calling. During weekends it is a couple of hours before they call. Maintenance on the Ex Servers is normally during of hours. Early morning review of he log files can help us most of the times.

I am not an expert on reading these log files. I have tried to look for MAPI errors but there is so much of info it is hard to look for something consistent. Any idea what I should look for in ALRT and CTRL log files.

I have seen the following the MAGT log files: (many of them)

MAPIMailbox::RefIDtoEntryID - Could not find RefId
RefIDtoEntryID - FindRow (nnnn) failed

Not sure if this is b/c MAPI comm problem.

Thanks,
Keith

Keith -

If you want, zip up a day of log files from a day they did maintenance and I'll point out some entries to you that would indicate a MAPI problem (email it to hdawg@port3101.org).

That said, if you're going to do an early morning review of log files ... why not just restart the BES and deal with the 2 minutes of downtime instead of spending the time looking at the logs.

I understand the desire to understand what is going on and to justify a reboot (and to not reboot if not needed) but from a process perspective I think you may end up putting in more effort than needed here.

__________________
http://blog.port3101.org/hdawg/

The views expressed by me on Port3101 and its affiliated sites are my own and do not necessarily reflect the views of my employer.

Keith -

As I said in our offline discussion, something from the ALRT log such as:

[30000] (05/09 00:00:59.114):{0x84C} [Alarm::ActivateAlarm] Queuing alarm: <N/A> | BlackBerry Messaging Agent MYBES Agent 4 (Application Event Log on MYBES) | 05/09/2010 00:00:57 (AFFF4EBA) -> User Jones, Mark not started
[30000] (05/09 00:00:59.114):{0x844} Alarm::ThreadProc: Received an alarm message
[30000] (05/09 00:00:59.114):{0x84C} [Alarm::ActivateAlarm] Queuing alarm: <N/A> | BlackBerry Messaging Agent MYBES Agent 4 (Application Event Log on MYBES) | 05/09/2010 00:00:57 (AFFF4EBA) -> User Anderson, Mary not started
[30000] (05/09 00:00:59.114):{0x844} Alarm::ThreadProc: Received an alarm message
[30000] (05/09 00:00:59.114):{0x84C} [Alarm::ActivateAlarm] Queuing alarm: <N/A> | BlackBerry Messaging Agent MYBES Agent 4 (Application Event Log on MYBES) | 05/09/2010 00:00:57 (AFFF4EBA) -> User Toms, Lily not started
[30000] (05/09 00:00:59.114):{0x844} Alarm::ThreadProc: Received an alarm message
[30000] (05/09 00:00:59.114):{0x84C} [Alarm::ActivateAlarm] Queuing alarm: <N/A> | BlackBerry Messaging Agent MYBES Agent 4 (Application Event Log on MYBES) | 05/09/2010 00:00:57 (AFFF4EBA) -> User Mull, Mark not started
[30000] (05/09 00:00:59.114):{0x844} Alarm::ThreadProc: Received an alarm message
[30000] (05/09 00:00:59.114):{0x84C} [Alarm::ActivateAlarm] Queuing alarm: <N/A> | BlackBerry Messaging Agent MYBES Agent 4 (Application Event Log on MYBES) | 05/09/2010 00:00:57 (6FFFC39F) -> 4 user(s) failed to initialize

... would be good indicators of a problem. Given that we see these events at the immediate start of the log we can assume the problem started indeed during the previous day. To see the first events we'd need to look through those logs. All of these events will also show up in your Windows Application Event Log ... you could setup triggers / alerts for if you ever see "user(s) failed to initialize" to send a notification ... its a good start at least.

__________________
http://blog.port3101.org/hdawg/

The views expressed by me on Port3101 and its affiliated sites are my own and do not necessarily reflect the views of my employer.

Better to have BES Monitoring and have SMS alert configured.