BPS email delivery times

[Turk54]

I have a question to the all knowing, all-seeing, seer, sage, sooth sayers of the forum..... My company just recently had installed BPS to enable my BB to work with our exchange server. Whereas everything seems to work (I receive my email, calendar, contacts, tasks sync with no problems), some times my emails arrive very late. Usually I see my emails arriving within a minute or two of seeing them arrive in my Outlook mailbox, but at times this can be as long as 30 minutes. Does the group have any ideas as to where to begin to figure out why this might be occurring? Thanks in advance for your help.

[GlenB]

if you click on the server in BPS it should show you the status, including any "Pending" messages. If messages are pending, then either the BES is struggling to send data to RIM over your internet connection, or RIM dont have a current connection to the device.

Assuming this isnt the problem, then it may be a communication issue between your BES and Exchange....

BES and BPS use MAPI to connect to Exchange. Exchange provides a "new mail notification service by sending a UDP packet to each registered client. Being UDP, its fire and forget, so if the packet doesnt arrive (i.e. collision on the network etc), then the client (BPS in your case) isnt notified. After 15-30 minutes of no notification from the Exchange server, BES will then go and proactively look for new mail by initiating a mailbox rescan.

[Turk54]

Thanks for the reply, GlenB. I have a couple of questions:
1. What is the normal timeframe for a message to arrive on teh handheld after it arrives in the Outlook mailbox? I currently see 1-3 minutes, and was curious if this is within normal range.
2. I have seen some posts in other forums that if the UDP latency exceeds 35ms then BES/BPS will do a rescan for new messages after a 15-30 minute timeout period. Is there a way to check in the logs to see if BES/BPS is being forced to do rescans?
3. Also in some posts, it mentions potential response problems with mismatches of MAPI32 and CDO versions on the BES/BPS server and the exchange server? Is this something we should look into as well?

Thanks in advance for your answers....

[GlenB]

Hi Turk

I will try and answer as best I can...

1. My experience is that message delivery is pretty much immediate - often I am alerted on the BB before the message is even visible in Outlook. That said, there are lots of things that can cause general slowness of delivery. Your BES compresses each message and slices it into 2K chunks. Only the first 2K is sent initially, over your internet connection to RIM. This suggests a couple of potential bottlenecks...how much under load is the Exchange, BES and your internet connection. Once RIM have the message, it has to go over leased lines to the mobile carrier network, through that network to the base station, then over the air to the device. The most likely issues to arise here are delays due to poor radio signal.

2. I think the 35ms figure comes from the max LAN latency expected between Exchange and BES, but I dont believe the BES actively monitors this latency in any way, the mailbox rescans happen because the BES hasnt heard anything from that mailbox in N minutes. The default log location is c:\program files\research in motion\blackberry enterprise server\logs. Sub directories are in the format of YYYYMMDD. Look at the current days directory. The relevant log file has _MAGT_ in the filename. Its syslog format so effectively plain text and you will be able to see any mailbox rescans being logged.

3. Mismatched versions of MAPI/CDO are common and can cause obscure problems, you should always try to keep the versions on the BES in step with the version installed on the Exchange server.

[Turk54]

Thanks for your response to my problem. I have some more information that might help pinpoint the cause of my problems. I use rules to move some emails to subfolders in my Inbox. I have selected all of these subfolders to be synchronised with my BB handheld, and have verified this with the folder redirection option in Desktop Manager. It appears that if an email arrives and is forwarded to one of the Inbox subfolders by rules, that it doesn't automatically get sent out to the BB handheld, but does occur when some sort of time out function occurs and BES/BPS performs a rescan of exchange for missed messages. However, if I am on my PC and open/read the email that is redirected to a subfolder, then the process of changing the status from unread to read causes the email to be sent to the BB handheld immediately and it appears on the device. Got any clues as to why this may be occurring? I suspect that there is also something else amiss, because I have on very rare ocaisions seen regular Inbox email that should go out to the handheld be delayed as well. Does BES/BPS log the number of missed messages that it finds during its rescans for missed messages? Thanks to everyone for your assistance.

[GlenB]

> if an email arrives and is forwarded to one of the Inbox subfolders by rules, that it doesn't automatically get sent out to the BB handheld

I would say that this is pretty much to be expected due to the limitations of MAPI

> if I am on my PC and open/read the email that is redirected to a subfolder, then the process of changing the status from unread to read causes the email to be sent to the BB handheld immediately

This surprises me but for it to happen, the Exchange server must send a new mail notification to BES via MAPI

> I suspect that there is also something else amiss, because I have on very rare ocaisions seen regular Inbox email that should go out to the handheld be delayed as well

I suspect that IF this is happening, it is an unrelated issue, we would need more details to be sure

> Does BES/BPS log the number of missed messages that it finds during its rescans for missed messages?

My understanding is that BES adds a BES REFID to each message in the mailbox as it comes in. In then uses the REFID and its own internal queue to determine how to deal with the message. REF IDs can be displayed on the BB - open a message, hold ALT down and type VIEW. REF IDs can be viewed in the log files too.