12-04-2010 03:43 AM
Hi. We use inplace database upgrade and move all users from BES 4.1.6 to 5.0.2. Another we move all mailbox from EX 2003 to EX 2010. After that lots of users (aproximatly 1700 all users we have) have problems with verry huge deley messages. Some users (about 200) have faild to start.
Any one have clue what is the problem? Connection with database? Connection with Exchange?
How can we improve message supply to handheld? In Outlook everything is ok. Message arived in place.
Our configuration is:
BES 5.0.2 + all services on one server (primary + standby)
database on cluster on another server
Exchange 2010 on cluster with one hub and 2 mailbox store
All servers is in one VLAN.
12-04-2010 11:16 AM
have you checked the mapi32.dll and cdo.dll version on the BES as well as on the Exchange? Mail delays after upgrading the exchange can often happen because the BES mapi and cdo versions have to match or exceed the versions found on the Exchange.
here are a few articles that may help you out:
KB10285 -recreating mapi profile
KB15779 -Install or Upgrade mapi/cdo
If the cdo and mapi versions are all correct and up to date and this does not help try placing a user on a static mailbox agent and test out messages, see if that solves the issue if so then the BES server is probably overloaded with pending messages and hung threads and a restart of the server may need to be done.
12-05-2010 07:02 AM
So We check cdo and mapi32.dll on first time. On BES/Exchange is the same. Maybe you right about pending messages and hung threads. We restart servers couple times. For some users We use statistic Mailbox Agents and messages flow is very good I thing the restart server couple times make very big overload of server (scan mailbox, recount pending messages). But We have some users "failed to start" and I think this is corresponding to access to exchange mailboxes for this users.
12-07-2010 05:59 PM
RIM has information that there is a fix coming from Microsoft for Exchange 2010 that addresses this issue.
You are correct that a static mail box is a work around. They had me create additional client processors on the BES, but that didn't help.
12-08-2010 10:22 AM - edited 12-08-2010 03:14 PM
I don't believe the fix from RIM will fix the delay issue. They are hoping the fix/buddy build they have that corrects the memory leak with the rpc client access service will resolve this. (I'm on the inside loop on this as this bug was reported first in my company's name.) In order to get this from Microsoft, RIM needs several counters to prove the memory leak.
They are aprox. 3-5 days out in getting it backported to SP1 and SP1 RU1.
However, we are experiencing the delays as well. We have been tracking this with microsoft outside of this other issue and what we've come to discover is that the notification handler on the cas servers is a queue. This queue "fills" and removes the oldest packet before it is delivered.
If you open a ticket with Microsoft on this, they can confirm by running "extra" on the CAS, configuring the notification handler and then uploading the trace to them. Unfortunately these traces from what I can see cannot be converted to a txt file without them (.etl files.)
In end, unfortunately this is a microsoft issues, not RIM at all as there is nothing RIM can do about Microsoft Exchange not delivering them the proper notifications.
One avenue I was going to look at, is since we are using outlook 2003 (mostly in cached mode but some in online mode) we made a registry change to effect the polling.
We are considering changing this back to the default and see if it helps with the flooding. Just a thought.
I'm rockin the BlackBerry DTEK60, Passport, Z30, Z10, Q10, BlackBerry Mini Stereo Speaker, 64 gig PlayBook,BT Headset HS-700
12-17-2010 03:58 PM
were the MBX servers running out of physical memory and using virtual memory?
BESAdmin's, please make a signature with your BES environment info.
BES 12 and BES 5.0.4 with Exchange 2010 and SQL 2012 Hyper V
12-21-2010 11:29 AM
No, according to Microsofts calculators for our environment the MBX servers only needed 12GB of memory. We doubled and went with 24. The way exchange works is it tries to take up to 95% of the maximum memory, and then releases it if and when other applications on the box need it.
The underlying issue is the notification queue size. Essentially the queues do not hold enough data, and since there is some (very little, but some) latency talking to the storage for database reads, the queues can never bee processed fast enough.
This work around works, basically because we are loading most of exchange and its dbs into memory, therefore the disk (FC connected in our case) does not get accessed nearly as much.
Hope this helps anyone else out there in this situation.
01-05-2011 10:25 AM
is there a doc avail about the static mailbox agents? which one should be used, etc?
when we were on 4.1.6, the BES admin at the time placed users on diff agents etc b/c they were having the issues of delayed msg's, which def cleared up that issue.
however there were diff agents that were used, is there a difference? 200? 203?
01-05-2011 10:34 AM
No difference in the # used. RIMs reccomendation however is not to exceed 8 or so agents combined with dynamic and static.
I cannot stress enough the workaround for this is to put a buttload of memory in your exchange servers...