03-30-2011 03:34 PM
I have an interesting question for everyone that is having mail delays.
Are you using the Database Access Group features of exchange?
I've discovered that moving a user from a DAG enabled database, to a non DAG enabled database seems to resolve our issues for that user.
03-30-2011 04:12 PM
We are using the DAG funtionality. So far we are able to stay ahead of these delays by adding memory. We are up to 24GB of RAM per Mailbox Server to support 400 users of which 208 of them have BBs. At this rate I will need 96GB per Mailbox Server just to support 1000 people.
I hope that RIM and MSFT solve this issue quickly.
03-30-2011 04:16 PM
The tool i mentioned before, I was told this is why I need to run the tool (which ultimately might reduce the need for all that RAM):
A Microsoft Exchange Server 2010 bug has been identified which results in queries from MAPI clients taking a long time to complete against Exchange Server 2010, if they use/leverage named properties (like the BlackBerry Enterprise Server.) Microsoft changed the level that these named properties are at in Exchange Server 2010 and this causes more jet seeks when querying (and more disk iops) and in many cases, the queries take a very long time to complete. One of our most expensive queries that takes a long time is RELOAD FOLDERS.
by running the above command I talked about it should relieve a lot of this pressure. Since I have not heard anything back, I'm going to take a leap of faith and run this against an agent tonight to see if there are any results.
This command is also being toted to help alleviate a memory leak we are seeing in the messaging agents themselves... Stay tuned.
03-30-2011 07:44 PM
Fooled, we have also been provided with the ExMailboxScan tool by RIM (supposedly these MAPI property promotions will be restored with MR5 - this is how BES and E2K7 worked).
As yet, we have not implemented this tool as now have a freeze on any changes to our systems (due to the disastrous updates of late)
If you do implement this tool, please let us know how it goes as it may be a positive change or something to look forward to with MR5...
03-31-2011 12:06 PM
I ran the tool against a single agent last night. It took about 4 hours for 60 users... But our mailboxes are not typical, and one of those users took almost 3 hours himself. (7400 folders in outlook if that gives you an idea...)
So far there have been no complaints, and the memory usage has been below 100MB on the agent, while the minimum on the others is 300MB+
So far it has been a positive change, but will continue to monitor and update.
03-31-2011 12:12 PM
forgive me if i sound lost or slow...
but this tool is suppose to alleviate the pressure as u say w/ MB and delays to BB devices right?
for some who may not have bumped the RAM on Exchange boxes, i presume this will help in some way right?
how are u running it? only against users that seem to have issues based on logs?
i feel like i'm going in circles...
in the logs it seems msg are pending, but on the BAS, seems the msg to those users have been delivered.
yet our pending packets number continues to grow....
this is a nightmare.
03-31-2011 12:20 PM
Well without digging deep into your environment, I cannot give you a direct cause and resolution.
However: Adding RAM to the mailbox servers helps because you are loading more of exchange into memory, and less disk seeks are needed, speeding up how quickly exchange and BES are talking to eachother. The delays were happening due to a message queue depth not being robust enough in exchange to handle the requests from BES as well as clients.
Secondly: The issue is further compounded by the fact that in 2010 the named properties no longer have the same values, and therefore are not cached in exchange (always have been, not now)
Because of this, the BES uses (and always has) search folders in order to convert the short ID to the Long ID of the message in order to confirm 100% what the message was to deliver it to the right place etc.
With all of the changes, and of course adverse problems associated with 2 relatively new platforms, RIM has more or less changed the way to do this confirmation and delivery. This new tool (after MR4 is installed) helps greatly reduce the the disk calls, and therefore reduces the need for all the memory in exchange, and might just fix your issue.
03-31-2011 12:29 PM
Ok, understandable....think i get it now....
I'm gonna try to find some docs on this and MR4 etc as we do not have that installed yet, and see if this will help.
thanks a lot Fooled!
04-04-2011 10:03 AM
GREAT NEWS! Our problem is officially resolved. Been a week now, and haven't had a single delay on blackberry's. Even users with 14 gig mailboxes are receiving email efficiently.
As I've posted previously, we have tried every fix posted here except one. All the current updates, CDO, MR4, UR3, and Windows Server 2008 updates. Ran all the registry fixes and tried static agents, dynamic agents, and double agents (joke there, don't know if there is a double agent for BES). After having a ticket open with RIM support they determined our issue to be memory on the Mailbox Database server. We doubled our memory (we're virtual so it was easy) and the issue went away almost instantly after the BES reboot.
We had previously doubled the memory on our CASers, and added an additional CAS to bring us to 3. This diminished our problem, but did not resolve it. Adding another database to the environment allowed us to move high profile users to it to resolve the problem with them, but did not resolve the overall issue. When we reached too many users in that database, the issue returned.
Just and FYI, I followed the implementation guide for Exchange to the letter. I used the deployment tools and calculators whenever they were available. I did the exact same thing for our BES environment. Followed the deployment guide to a letter. I don't remember, and still cannot find, anything in either guide that gives updated hardware requirements for adding the BES. There is probably a document somewhere that addresses this, but I can't seem to find it. Something this important should be the first thing you find in a deployment guide. It should be in big bold obnoxious pink letters flashing yellow and black to get your attention. If we had had hardware servers, we would have had an additional expense for memory sticks. This is something that I needed to know prior to attempting to deploy my BES environment.
Just me venting a little. I'm sure there's an obscurely hidden document that goes over all this. All in all, doubling the RAM on our mailbox database server resolved our issues.