[wunderbar]

I have one user who is now reporting email issues. excuse me while I go and pull the BES server out of the rack and throw it out a window.

At least it's only one....I guess.....

[pknaz]

I've been fighting message delay issues on BES for about three years now. We have approximately 6,300 BES users and about 17,000 exchange mailboxes and on a typical day in the past would find that 10-15 minute message delays were not abnormal.

I hope that my experiences and pain can be of help to some of you.

For us, the problem turned out to be over provisioned disks. Increased IOPS on BES users is not the same issue in 2010 as it was in 2003, but it is still a very valid performance metric that needs to be considered. In Exchange 2010 “I/O Database Reads Average Latency” must be below 20ms, and RPC Average Latency must be no higher than 35ms average, and no higher than 50ms spikes. For our environment, as long as our disks are performing within these numbers messages flow to handheld devices in less than 60 seconds, confirmed using BoxTone.

Never under estimate the importance of disk IO.

[DSHThomsons]

Hi Guys,
We had the same problem and it was the default throttoling policy - I know a couple of posts have talked about this but that was the fix for us.

[wistowg]

My env't is 5.0.2 MR5, mixed Exchange (2003, SP2 and 2010, Sp1, RU3). 2200 BB users across 4 HA BESs running on Win2K8 VMs each having 2 x dual-core CPUs and 8GB RAM.

I think I have been pointed towards the solution to this. Whilst the throttling policy changes are important they don't fully resolve - at least not for me. In my env't the problem was all down to the way BES handles Messaging Agents.

RIM have configured it such that a single Messaging Agent handles all BES to Exch2010 traffic for the first 500 users. This always struck me as a very large number of users for a single Messaging Agent and it turns out to be the case because each Messaging Agent can only handle a maximum of 100 threads. So once you go above 100 Exch2010 users, or once you have sufficient hung threads you're going to see latency and possible red Xs when users try to send.

Giveaway entry in the MAGT logs was multiple instances of "Failed to reach user's mailbox"


Fix is a registry hack and it has worked 100% in my env't. This changes Agent allocation such that after making this change users will be divided evenly amongst the number of agents specified in the values below:


Take HA BES out of Automatic failover mode.

Make change on the live Primary BES first then implement on the standby afterwards. The standby will actually spawn the same number of agents as the primary as it gets the AgentID from the SQL database. The reason you must make the change on the registry is in the event that both servers are shutdown and the Standby comes up first, triggers a failover and everyone is back on 1 agent. This will only work on a server with more than 10 users.

Stop Controller, Dispatcher & Router BlackBerry services in this sequence.

At HKEY_LOCAL_MACHINE\SOFTWARE\Research In Motion\BlackBerry Enterprise Server\Dispatcher create a DWORD registry value called AgentOptimizeAlgorithm (capitalisation is critical) and give it a value of 1.

At HKEY_LOCAL_MACHINE\SOFTWARE\Research In Motion\BlackBerry Enterprise Server\Agents create a DWORD registry value called NumAgents (capitalisation is critical). 5 is the default number of agents, recommendation is to increase to a value of 10.

At HKEY_LOCAL_MACHINE\SOFTWARE\Research In Motion\BlackBerry Enterprise Server\Agents create a DWORD registry value called NumAgentsFullServer (capitalisation is critical). 5 is the default number of agents, recommendation is to increase to a value of 10.

Start Router, Dispatcher & Controller BlackBerry services in this sequence.

Repeat on Standby BESs.

Put back into Automatic HA failover state.

[microBES]

We have a mixed Exchange 2007/2010 environment; if you have a CAS array, make sure to put a HOSTS file entry on each BES pointing to just ONE of the CAS boxes in your array and also make sure that the mailbox for the BES account defined in your BES MAPI profile has been migrated to 2010 because you will have issues if it is on a 2007 Exchange server. In addition, make sure you have the latest MAPI/CDO installed (currently 6.5.8211.0) and you have Exchange 2010 patched to the latest Rollup (4) as well as the latest MR for BES 5.0.2 or 5.0.3. Microsoft also recommends this reg change on your BES boxes:

"we have managed to reduce the mail delays by implementing the below (we were seeing delays of up to 30 mins, they are now seeing delays of <5 mins);


try the following reg key to limit the number of users per session. By default it is 50 and 25 should be a good number to test with. You will neeed to restart the agents and this can be done by restarting the BlackBerry Dispatcher service. I will recommend to stop the Controller, restart the dispatcher, and then start the controller service. This way we are in the clear and this key should get picked up at that point.

HKLM\SOFTWARE\Research In Motion\BlackBerry Enterprise Server\Agents\

DWORD Type
MaxMailboxesPerSession

*Enter 25 as a decimal value, not hex*

Note: BES has a limit of 2000 users per server, so if the key is set to 25 users per session you can have a maximum of 40 sessions."

Hope that helps; it did for us.