Unusual 'SendAs' issue with Blackberry

assign send as rights on all mailbox to blackbery admin
http://www.blackberry.com/btsc/search.do?cmd=displayKC&docType=kc&externalId=KB02276

The red x is usually a symptom of a problem with the permissions assigned to the BESadmin account and how it interacts with exchange. We would need to know which version of exchange and BES enterprise you are running. Also you could check to see if there are any issues being reported within the BES server logs relating to issues with the BESAdmin account. Last time I had this issue it turned out to be an issue with the send as and receive as permission and I resolved it by using a vbs script to assign the appropriate permissions, but this was on a 2003 exchange. I have attached a copy of the file which you could modify accordingly depending on the exchange environment.
sendas.vbs

muzafar, thanks I have followed this to the letter and still have the same result.

I am running Exchange 2003 Std. BES v.4.0.2.8 (I think!)

delmc, I also presume it is an unusual permissions issue, but cannot trace it at all. I will attempt a customised version of your vbs script shortly and get back with results and logs.
Thanks.

pbgormley,

The script was designed to correct issues with the besadmin account and the removal of exchange sendas permissions after sp2 was applied to exchange & sp2 applied to server 2003, these permissions have no timescale for removal and it appears to happen at random. The only other thing I can tink of at the moment is that the BESadmin account has became corrupt somehow within active directory. If the permssions script fails I would attempt to create a new BESadmin account and then go through the process of apply all relevant permissions again,you can also re-run the script against the new account as it will assign the permissions accordingly. Good luck

Thanks delmc,

Can you give me more instruction on how to run the sendas.vbs script? I assume no changes need made as it's an exchange 2003 environment?
My VB knowledge is limited at best!

FYI. I have already removed the BESAdmin account, uninstalled BES and SQL, created the new account (BESController) and reinstalled BES as the new account and the database with no success.
(ps. Is 'Domain Users' a protected group for BES?)

Thanks.

Have you ran a BBCheck against the new environment as well to ensure that all recommendations are met. You just run the sendas.vbs script on the exchange server, this will then replicate the permissions throughout active directory. Also make sure that the mapi.dll and cdo.dll match exactly what you have on the exchange server and ensure that you can access exchange from the BES server using the exchange system manager, make sure that all of the services are running using the new account details and also check with blackberry system manager that you can still communicate via port 3101. The BES admin account should always be in the following groups, domain users, administrators, exchange view only administrators and have the sendas & receive as permissions. I presume that the BES server is just a member server and you have applied the permissions for run as a service and log on locally corectly?

Thanks for the info.
I was unable to get BBCheck installed / running. :(
The dll files versions match ok, I am able to access Exchange system manager with no problem from the BES Server.
The services are all running using the new BES account.
From the Blackberry Server configuration tool, I am able to connect to 'srp.eu.blackberry.net' port 3101, successfully.
I have also tried to connect to port 3101 from outside back in, but it appears closed, is this because the bes service only initiates a port 3101 connection briefly? or do I need to look into my firewall a bit more? (Untangle)
The BES account is a member of the correct groups and appears to have the correct permissions.
The BES Server is a member server and the local policies have been amended correctly.

Sorry for the brick wall, but everything else is working so well, I can only assume it is something simple I am overlooking!

I neglected to add the result which appears in the BES_MAGT_01 log file after I try to send a mail from the handset, will I presume that if this is getting through, that the firewall is not the issue?:



[40000] (03/29 09:00:03):{0x1050} [BIPP] Received datagram, Tag=428
[40700] (03/29 09:00:03):{0x1078} {user@xxxxxx.org} Receiving packet from device, size=112, TransactionId=-623868912, Tag=428, content type=CMIME, cmd=0x3
[30112] (03/29 09:00:03):{0x1078} {user@xxxxxx.org} Receiving message from device, RefId=169491879, Tag=428, TransactionId=-623868912
[20265] (03/29 09:00:03):{0x1078} {user@xxxxxx.org} MAPIMailbox::Send(ppMAPIMessage) - SubmitMessage (0x80070005) failed.
[20265] (03/29 09:00:03):{0x1078} {user@xxxxxx.org} MAPIMailbox::Send(ppMAPIMessage) - SubmitMessage (0x80070005) failed.
[20000] (03/29 09:00:03):{0x1078} {user@xxxxxx.org} Send() failed: SUCCESS, Tag=428
[40277] (03/29 09:00:03):{0x1078} {user@xxxxxx.org} Sending message error to device for message 169491879
[40583] (03/29 09:00:03):{0x1078} {user@xxxxxx.org} Sending packet to device, Size=46, Tag=387, TransactionId=-846110946
[40279] (03/29 09:00:03):{0x1078} {user@xxxxxx.org} SubmitToRelaySendQ, Tag=387
[40279] (03/29 09:00:03):{0x1078} {user@xxxxxx.org} SubmitToRelaySendQ, Tag=428
[40000] (03/29 09:00:03):{0x1054} [BIPP] Send data, Tag=387
[40000] (03/29 09:00:03):{0x1054} [BIPP] Send status DATA_ACCEPTED, Tag=428
[40000] (03/29 09:00:03):{0x1050} [BIPP] Received status DELIVERED, Tag=387

I would therefore assume that the problem does lie with the account losing permissions somewhere within the exchange setup, did you run the VBS Script. Also RIM has a tool to assist with resetting BES sendas permissions, you could try that to see if it helps resolve the issue, link is as follows: http://www.blackberry.com/btsc/search.do?cmd=displayKC&docType=kc&externalId=KB12300&sliceId=SAL_Public&dialogID=9130481&stateId=0%200%205470776

OK,
I created a new test user account for which to assign our test blackberry device to and all is now working fully. The original user account is a member of other groups, none of which are 'protected groups', nor do they in turn belong to any protected group, so I cannot put my finger on where the issue lied. I will soon find out when I have to set this up in a production environment using other users accounts and handhelds.
I did perform a full wipe on the device and setup from scratch there as part of the process but I dont see how this could have been related.
I will make sure to check that the user only belongs to domain users and distribution groups initially and add from there to rule out.
Thanks for all your help for what was a frustrating issue and turning out to be a simple resolution. Points awarded for perseverance!

Glad to hear you got it sorted out, hopefully you won't come across the issues when you start with the real user accounts.