[ocman]

What is the best way to troubleshoot a user that periodically shows up with several pending messages and his Device and signal are fine??

The past 3 times I have noticed this based off of a complaint I purged the users pending messages and that corrected the problem.

I would like to know what Logfile I can check that will tell me why messaged are not able to be delivered to this users device and just queue up.

Thanks!

[akdumga]

The mail agent log (MAGT) is likely the best place to start looking. You could simply perform a grep against the users email address that is having the issue.

I've seen clumping in the past where a few messages queue up on the BES then when you send a message from the handheld everything starts flowing again. It's like the handheld has full signal, however the wireless network has more or less lost its association with the handheld. This seems to be happening less frequently now than it used to, but I still see it occasionally.

If a user calls in with this I always have them send a test email message from the handheld, or a test PIN. You could also try sending that handheld a PIN, or an APB from the management console.

Clearing the pending list is probably coincidental though, as I don't think anything would get *stuck* pending.

[ocman]

I dont think it was coincendental. All 3 times I have done this the person immediately received a test message I have sent him after performing the purge.

The person also can send with no problems while this is happening and he always sends to test functionality.

[akdumga]

Hmm. Interesting. I would definitely check the agent logs (MAGT) then to see what things are being queued up before the handheld stops received. Ie, is it calendar appointments or emails? And perhaps narrow it down from there.

Just out of curiosity, what is the BES/Handheld software versions?

[ocman]

Bes 4.0 SP1 Handheld 4.0 T Mobile 7100t.

I can find stuff like this in the logs but have no idea what anything means really.

30401] (09/06 09:57:07):{0x1380} Message queue for *** total # pending=33, # sent to wireless network=5, queued events=29

[akdumga]

Hmm, that seems strange, but I think it might be explainable. The BES only sends a max of 5 messages to the BB NOC before stopping and waiting for an ACK to come back. I *think* that queued events is not just email, but it also includes other transactions, like ones between components. So perhaps the agent is waiting to send information to another component, but the other component is not answering, and the emails that are waiting to be delivered are not in the queue of 5, but further behind.

This would explain why purging the pending items restores functionality, because once again emails would be at the front of the line.

For this to happen one of the other components (like the sync server for example) would have to be offline or in a state where it wasn't acking packets properly. I would recommend cranking up the logging on your sync service and it policy service and see if they are reporting any errors around the time that you notice this happening.

[mahoward]

This often happens to us. When you clear pending, you are actually cancelling the 5 messages that are out for delivery on the wireless network and sending 5 more. Most of the time these new 5 messages find the device OK, and then everything gets delivered.

Seems that T-Mobile (or other carrier?) can't find the device with the outstanding 5 messages, so when you cancel them it tries again and does find it.

I have found that waiting up to 4 hours for the retry to happen will fix this problem as well.

[jibi]

hmm, that may explain some things happening here. which devices are these happening on - only 7290 and 7100? i have contacted Cingular, T-Mobile and RIM on this same issue. T-Mobile and Cingular both stated the network was not at fault. RIM claimed it was the handheld that was the issue, and ruled out the BES. others from TMO and RIM both stated that it was the handheld code on the 7290.

the odd thing, and perhaps not so odd now, the user can send emails and send/receive PIN messages during this period, but cannot receive emails or policy.

[ocman]

Its only 7100's for me and only T-Mobile.

[akdumga]

Originally Posted by jibi

the odd thing, and perhaps not so odd now, the user can send emails and send/receive PIN messages during this period, but cannot receive emails or policy.

I think this fits the theory that the BES is queuing other component-to-component data. Since the handheld can still send/receive PIN it's connection with the wireless carrier is ok, and the BES is able to process inbound messages from the user, so the user isn't *stuck* on the BES. That's why clearing the queue fixes the issue, because the mailbox rescan picks up all the new emails and sends them out.

[mahoward]

I believe in an upcoming release (4.1?) you can configure the retry time from 4 hours to 1 hour, which would help this issue but it seems like that is simply a bandaid. The problem is that messages which are out on the wireless network cannot find the device even though there is an uppercase GPRS.

This would often happen to our users who turned their device off at night or lived in an out of coverage area for T-Mobile. Their messages would be "lost" on the wireless network and they would have to wait 4 hours for the BES to resend them at which point they would come through.

Clear pending, waiting 4 hours, or restarting the BES server will all push these through.

I have seen this on T-Mobile with all kinds of devices, 6230, 7230, 7100.

[jibi]

bingo, thanks.

[ocman]

Wow, great response there. It sounds both plausible and believable. I forwarded this on to my management since we have several out of towners that live in non T-Mobile coverage areas.

Some are changing to Verizon devices as we speak. There is talk of a Verizon 7130 in the near future and Im feeling like this will be a hot item for our management.