Now to be perfectly fair, I’m not going to blame all of my issues on BlackBerry or their Enterprise Server. I will however, consider their method of message relay and integration with our environment quite a hack and their support staff a challenge to work with, especially late at night.
That being said… here’s my problem and what I’ve found that fixes it – I hope it may help you.
Lead up:
We’re in the process of implementing an Exchange 2007 cluster to replace our aging Exchange 2003 SP2 server. The BES is version 4.1.14 and hasn’t been touched at all. The old environment is going to retire in place after we migrate all 16k mailboxes over to the new cluster.
We built the cluster, and had problems with our AD’s permissions. The environment has been in place since NT4 and upgraded multiple times. It’s also been maintained by people who’s skill levels range from fresh grad to seasoned engineer… so there are going to be interesting problems.
After rebuilding the Off Line Address book, we instantly began finding things not working – one of the was the failure for BlackBerry users to send email from their devices.
The MAPI account became horribly disconnected and wouldn’t re-establish its connection from the BES. After resolving the address book privlage issues with Microsoft, we tackled the BES issues.
BES support was mediocre but I really hate being told to reboot and try again… especially when wanted to show them the problem and log file entries. In the end, we ended up creating a brand new service account and went through giving it permissions to run the blackberry services, manage the MS SQL database, and local security rights required. MAPI connection still failed.
Regenerated the address book, forced a replication on all domain controllers, and the remembered that we have to give security rights to users for the BESAdmin to send as our BlackBerry users. A quick change in Users and Computers and we were back in business.
Now, that BESAdmin is connection and MAPI connection is working, we had a few stragling users that were STILL not able to send email from their phones. BlackBerry devices would send messages, but then they’d bounce back with an error:
Message Status: Desktop Email program unable to submit message.
From the BES server, you can see the messages failing with the following error in the MAGT logs:
[20472] (02/22 00:22:28.065):{0x12F8} {email@address.com} Send() failed: ERR_SUBMIT_MAIL, Tag=237923
[40277] (02/22 00:22:28.065):{0x12F8} {email@address.com} Sending message error to device for message 1638428126
[40583] (02/22 00:22:28.065):{0x12F8} {email@address.com} Sending packet to device, Size=43, Tag=627401, TransactionId=
[40279] (02/22 00:22:28.065):{0x12F8} {email@address.com} SubmitToRelaySendQ, Tag=627401
[40279] (02/22 00:22:28.065):{0x12F8} {email@address.com} SubmitToRelaySendQ, Tag=237923
The first thing recommended is to check this user’s account. The BESAdmin account should have security rights to send as this user.
Our problem: we used inherited permissions to assign the BESAdmin security rights to users. Some of our IT domain users were members of privileged groups (like domain admins or groups that were members of privileged groups) – this causes the account to lose its inherited permissions. No, really – it’s supposed to! It’s a documented feature.
So now that we found some security risks and squashed them, I’m able to re-enable the Inherit Privleges so that the BESAdmin account can send email as the affected user.
Unfortunately they say it can take a few minutes (to 2 hours) for these security permissions to be refreshed in Exchange – but I had almost instant results. Obviously your milage may vary.
In the end though, the way that BES hooks into the AD and Exchange environment is very much a hack which I’m not all that impressed with.