[that_girl]

I've searched the forum, but the answer to my question has not come up. I found many questions and answers about a reverse problem - messages not reconciling on the Handheld. This one pertains to messages not reconciling in Outlook.

We are using BES 4.0.6.12 (planning to update to 4.1 in a few months). We have one user who travels a lot, and he is often sitting on planes for several hours or more each trip. He likes to use this time to "clean up" his Outlook mailbox using his Blackberry: filing messages in subfolders, reading messages, and deleting old messages. His Outlook mailbox is one of our largest (we don't use PSTs and don't have a retention policy - being a law firm, they like to keep it all), with hundreds of subfolders. Now, while he is on these airplanes, he is not connected to the T-Mobile EDGE network - wireless is off. When he finally turns Wireless On and returns to the office, he finds that nothing has changed in Outlook. No messages have been filed, none have been deleted, and none have been marked as Read.

We replaced his Blackberry - from a 6230 to an 8700g in December. I don't think the problem is the Blackberry because someone else has since told me that when he is outside of wireless data range, if he deletes messages on his Blackberry, they never get deleted from Outlook, but when he is in wireless data range everything is fine. The two users are on different wireless networks (Verizon vs. T-Mobile).

My theory is that after several hours being disconnected, the BES has no idea how to handle messages that have been deleted on the disconnected Blackberry, so it does nothing. Anyone else have some thoughts before I try calling T-Mobile and begging to speak to RIM?

Thanks!

[Zro]

Here's the thing...as soon as a deletion or message modification occurrs, the handheld queues up an OTAFM (over the air folder management) command to be sent back to the BES. In this OTAFM command is a RefID that corresponds to the message...once the handheld is in wireless coverage, it should then send back all these pent up OTAFM's to the BES for processing. The BES should act apon the message based on it's RefID just as if the handheld were in coverage the whole time.

The two questions I would have is if the handheld is configured for delete on mailbox and handheld, and if this reconcile process happens if the user is constantly in wireless coverage? You mentioned that the one person worked when in coverage, but not the other.

Next you can potentially look at the Folders and Folder ID's databases...they may have gotten messed up and can be cleared with Desktop manager's backup and restore tool (the advanced button) then refreshed by turning off wireless reconcile, saving the change and waiting 30 seconds, then turning it back on. This will reload the entire folder structure of the mailbox.

Next, it's possible that the Desktop [CMIME] service book is a bit messed on the handheld. Delete it from the handheld (Options > Advanced Options > Service book) then resend service books from the BES.

You can also have a look in the MAGT log to see if you see any MFH or OTAFM lines for this user within 20 minutes after him turning the handheld back on (or have the user do a Reconcile Now right after turning it on so you can see exactly when the reconcile process happens)?

Zro

[that_girl]

Email reconciles just fine for both users when they are within wireless coverage, with minimal delays. All of our handhelds are set to prompt the users to choose where they want to delete the messages, and yes, "Delete on Handheld and Mailbox" is what is being chosen. The problem seems to be that the one guy is deleting and filing more than 50 messages when Wireless is turned Off for several hours or more (he uses the time that he is on a flight to do this). There must be some kind of bottleneck that occurs, because when he turns Wireless On, nothing happens in Outlook, even when he chooses Reconcile Now or plugs the handheld into the computer, runs Desktop Manager and Reconciles messages that way. We'll try your suggestions, thanks!