Note: If all the users on the BlackBerry Enterprise Server are unable to send email messages with this error and the all the users are not in a protected group, refer to the Permit BlackBerry device users to send email messages in a Microsoft Exchange environment section in the BlackBerry Enterprise Server for Microsoft Exchange Installation Guide to set up the default Send As permission for the BlackBerry service account. Once the default Send As permission has been set as directed in the installation guide, wait 30 minutes to allow the Security Descriptor Propagator task to run and then refer to the Confirming if the Send As Permission is present on a user account and Clearing the Exchange permission cache in the Additional Information section of this KB to confirm and restore sending functionality.
When a BlackBerry smartphone user tries to send an email message, a red X appears beside the email message in the message list on the BlackBerry smartphone, indicating that it cannot be sent. The Message Status field displays one of the following error messages:
This issue will only affect some BlackBerry smartphone users, typically the Windows administrators or other users with elevated permissions, such as Print Operators. If all users are affected, refer to the note at the top of these section to set the Send As permission for all users before proceeding with this KB.
The BlackBerry Messaging Agent (MAGT) log file displays the following:
When a BlackBerry smartphone user tries to send an email message, a red X appears beside the email message in the message list on the BlackBerry smartphone, indicating that it cannot be sent. The Message Status field displays one of the following error messages:
- Unlisted message error.
- Desktop email program unable to submit message.
Note: The Message Status field appears above the To field in the email message.This will likely occur shortly after applying either of the Microsoft hotfixes listed in the Cause section or other Microsoft hotfixes to update the DST settings on the Microsoft Exchange Server.
This issue will only affect some BlackBerry smartphone users, typically the Windows administrators or other users with elevated permissions, such as Print Operators. If all users are affected, refer to the note at the top of these section to set the Send As permission for all users before proceeding with this KB.
The BlackBerry Messaging Agent (MAGT) log file displays the following:
BlackBerry Enterprise Server 4.0 to 5.0
[40700] (12/13 15:38:10):{0xFF0} {<user_name>@<domain>} Receiving packet from device, size=111, TransactionId=-2099843783, Tag=147, content type=CMIME, cmd=0x3
[30112] (12/13 15:38:10):{0xFF0} {<user_name>@<domain>} Receiving message from device, RefId=1607656887, Tag=147, TransactionId=-2099843783
[20265] (12/13 15:38:10):{0xFF0} {<user_name>@<domain>} MAPIMailbox::Send(ppMAPIMessage) - SubmitMessage (0x80070005) failed
[20265] (12/13 15:38:10):{0xFF0} {<user_name>@<domain>} MAPIMailbox::Send(ppMAPIMessage) - SubmitMessage (0x80070005) failed
[20000] (12/13 15:38:10):{0xFF0} {<user_name>@<domain>} Send() failed: SUCCESS, Tag=147
[40277] (12/13 15:38:10):{0xFF0} {<user_name>@<domain>} Sending message error to device for message 1607656887
[40583] (12/13 15:38:10):{0xFF0} {<user_name>@<domain>} Sending packet to device, Size=46, Tag=222, TransactionId=-1012978472
BlackBerry Enterprise Server 2.1 to 3.6
[40700] (12/13 15:38:10):{0x7FC} {<user_name>@<domain>} Receiving packet from device, size=161, TransactionId=-1966367802, Tag=-1091853399, content type=CMIME, cmd=0x3
[30112] (12/13 15:38:10):{0x7FC} {<user_name>@<domain>} Receiving message from device, RefId=1473556709, Tag=-1091853399, TransactionId=-1966367802
[20265] (12/13 15:38:10):{0x7FC} {<user_name>@<domain>} *** MAPI *** MAPIMailbox::Send(ppMAPIMessage) - SubmitMessage (0x80070005) failed.
[20000] (12/13 15:38:10):{0x7FC} {<user_name>@<domain>} Send() failed: ERR_SUBMIT_MAIL, Tag=-1091853399
[40277] (12/13 15:38:10):{0x7FC} {<user_name>@<domain>} Sending message error to device for message 1473556709
[40583] (12/13 15:38:10):{0x7FC} {<user_name>@<domain>} Sending message to device, Size=85, Tag=6420, TransactionId=-1001413813
- BlackBerry® Enterprise Server 2.1 to 5.0 SP2 for Microsoft® Exchange
- BlackBerry smartphones
- SDR75493
- SDR82260
Cause
The default permissions for user accounts in protected groups has been changed to remove the Send As permission and the Allow Inheritable Permissions from the accounts, by hotfix 895949 and 926666 for Microsoft Exchange, as described in the Microsoft support.microsoft.com website. These hotfixes are for Microsoft Exchange Server 2003 SP1 or SP2, or Microsoft Exchange Server 2000 SP3.
The removal of the Send As permission occurs when the Security Descriptor Propagator Update task runs, at about 20 to 30 minute intervals. Users most commonly affected are Domain administrators, but any user in a protected group will be affected by this.
For a list of protected groups, and more information about the Security Descriptor Propagator Update task and AdminSDHolder, search the Microsoft TechNet web site for the "AdminSDHolder, Protected Groups and SDPROP" article in the September 2009 edition of the TechNet online magazine.
Note: While the default permission change was initially identified in Microsoft hotfixes 895949 and 926666, there might be other hotfixes that could also update the default permissions and result in the same issue, and newer versions of Microsoft Exchange versions that include the new permissions for protected groups by default.
The removal of the Send As permission occurs when the Security Descriptor Propagator Update task runs, at about 20 to 30 minute intervals. Users most commonly affected are Domain administrators, but any user in a protected group will be affected by this.
For a list of protected groups, and more information about the Security Descriptor Propagator Update task and AdminSDHolder, search the Microsoft TechNet web site for the "AdminSDHolder, Protected Groups and SDPROP" article in the September 2009 edition of the TechNet online magazine.
Note: While the default permission change was initially identified in Microsoft hotfixes 895949 and 926666, there might be other hotfixes that could also update the default permissions and result in the same issue, and newer versions of Microsoft Exchange versions that include the new permissions for protected groups by default.
Resolution
The recommended resolution for this issue is to remove the affected user from any protected groups.
For a user who needs an account in a Windows® protected group, it is recommended to provide a second account for the user. One of the accounts will not be in any protected groups, and would be used for day to day general use and email with the BlackBerry smartphone. The second account will be the administration account and can be added to any needed protected groups.
Important: This resolution does not require any changes to the Microsoft® Active Directory® permissions and is the Research In Motion and Microsoft recommended resolution.
Once the user has been removed from any protected groups, the following must be completed to restore the Send As permission for each user that was removed from a protected group.
1. Confirm the user has been removed the all protected groups, included any which may have been due to inheritance from other groups.
2. Open Active Directory Users and Computer.
3. From the menu select View > Advanced Features.
4. Navigate to the user that was removed from the protected group.
5. Right-click the user and select Properties.
6. Select the Security tab.
7. Click the Advanced button.
8. Enable the inherited permissions for the user
- On Windows Server® 2003, check the box:
All inheritable permissions from the parent to propagate to this object… - On Windows Server 2008 check the box:
Include inheritable permission from this object’s parent
9. Click Apply.
10. Confirm the Send As permission now appears in the Permission entries: list with the name of the BlackBerry Enterprise Server service account.
11. Click OK.
12. Click OK.
13. Complete steps 4 to 12 for any other users removed from a protected group.
14. Follow the steps for Clearing the cached permissions in the Other information section of this KB.
Note: Confirm in 30 minutes that the inherited permissions check box is still checked. If in 30 minutes the check box is unchecked, it means the user is still being flagged by the Microsoft Active Directory Security Descriptor Propagator as being in a protected group either directly or by inheriting it from another group. This must be corrected first and then the steps repeated.
Workaround
If it is not practical to remove the user from the protected group, there are two workarounds that can be done to force the Send As permission onto user accounts in protected groups. Both these workarounds modify Microsoft's recommended Microsoft Active Directory permissions for user accounts in protected groups. Only one workaround needs to be completed.
Important: These workarounds are not recommended by Microsoft or by Research In Motion.Note : If at any point in the future the BlackBerry service account is changed to a different service account, the workaround that was implemented will need to be run again to apply it to the new service account.
Workaround 1 – Modify the ACL using the DSACLS command line tool.
This workaround will use the Microsoft tool DSACLS to force the Send As permission onto all protected groups by changing the AdminSDHolder object. Additional information about this work around can be found in Microsoft on the support.microsoft.com website.
Complete the following steps to apply this work around.
1. Logon to a domain controller for the network.2. Ensure that the DSACLS utility is installed on the computer you will be running applying the work around on.3. Open the Notepad.exe application.4. Copy and paste the following commands into Notepad.dsacls "cn=adminsdholder,cn=system,dc=domain,dc=local" /G "\SELF:CA;Send As"
dsacls "cn=adminsdholder,cn=system,dc=domain,dc=local" /G "\SELF:CA;Receive As"
dsacls "cn=adminsdholder,cn=system,dc=domain,dc=local" /G "\SELF:CA;Change Password"
dsacls "cn=adminsdholder,cn=system,dc=domain,dc=local" /G "\SELF:RPWP;Personal Information"
dsacls "cn=adminsdholder,cn=system,dc=domain,dc=local" /G "\SELF:RPWP;Phone and Mail Options"
dsacls "cn=adminsdholder,cn=system,dc=domain,dc=local" /G "\SELF:RPWP;Web Information"
dsacls "cn=adminsdholder,cn=system,dc=domain,dc=local" /G "\BESAdmin:CA;Send As"5. Replace the following text in Notepad.
The new text would be dc=eastern,dc=mycompany,dc=localTo locate the name of the domain, find the domain node in the Active Directory Users and Computer tree list.6. Save the file as SendAsFix.bat and exit Notepad.7. Open a command window and navigate to the directory the SendAsFix.bat file is in.8. Run the batch file by typing SendAsFix.bat at the command line and pressing ENTER.9. Once the command has completed, scroll up though the command window and ensure “This command completed successfully” is there for each line that was executed and there were no errors.10. At this point the admin template has been changed to include the Send As permission for protected groups, but it is not yet applied to the protected user accounts.11. Wait 30 minutes for the Microsoft Active Directory to update the protected user accounts with the new Send As permission.12. Confirm the Send As permission has been applied to the user account following the steps for Confirming if the Send As permission is present on a user account in the Additional Information section of this KB article.13. Clear the Microsoft Exchange permission cache by following the steps for Clearing the cached permissions in the Additional Information section of this KB article.
Workaround 2 – Modify the AdminSDHolder object
This workaround will change the AdminSDHolder object in Active Directory Users and Computers to force the Send As permission onto user accounts in protected groups.
Complete the following steps to apply this workaround.
1. Open Active Directory Users and Computers.2. From the menu select View > Advanced Features and ensure it is turned on.3. Expand the domain in Active Directory Users and Computers.4. Expand the System folder.5. Right-click AdminSDHolder and select Properties.6. Select the Security tab.7. Click the Advanced button.8. Click the Add button.9. Enter the service account name, BESAdmin is the default.10. Click OK.11. On the Permission Entry for AdminSDHolder dialog box, in the Apply to drop down box select User Objects for if using Exchange 2003 or Descendant User objects if using Exchange 2007 or 2010.12. In the Permissions list, find Send as and check the box Allow.13. Click OK to close the dialog box.14. Click OK to close advanced dialog box.15. Click OK to close user properties dialog box.16. At this point the admin template has been changed to include the Send As permission for protected groups, but it is not yet applied to the protected user accounts.17. Wait 30 minutes for the Microsoft Active Directory to update the protected user accounts with the new Send As permission.18. Confirm the Send As permission has been applied to the user account following the steps for Confirming if the Send As permission is present on a user account in the Additional Information section of this KB article.19. Clear the Microsoft Exchange permission cache by following the steps for Clearing the cached permissions in the Additional Information section of this KB article.
Additional Information
Confirming if the Send As permission is present on a user accountThe following steps can be completed to confirm if the Send As permission has been applied to a user's account. Depending on how the Send As permission has been applied, the indications will vary slightly.
1. Open Active Directory Users and Computers.
2. From the menu select View > Advanced Features and ensure it is turned on
3. Navigate to the user account that needs the Send As permission checked.
4. Right-click the user account and select Properties.
5. Select the Security tab.
6. Click the Advanced button.
7. In the Permission entries list, look for an entry with the name of BlackBerry server service account, BESAdmin by default in the Name column.
8. When found, confirm the permission from the Permission column based on the screen shots.
9. If the permission cannot be found, then the Send As permission is not applied on the user's account.
Clearing the Microsoft Exchange permission cache.Screen Shot of the Send As permission applied by the instructions in the install guide
The Send As permission is stored in Microsoft Active Directory and read by the Microsoft Exchange Server when the user attempts to send an email from the BlackBerry smartphone. Once the permission has been read by the Microsoft Exchange Server, the Microsoft Exchange Server will now cache the Send As permission (either Allow or Deny) for 2 hours, which if a Deny Send As permission for the user is in the Microsoft Exchange permission cache, it will still prevent the user from sending email from their BlackBerry smartphone.
If it has been confirmed that the Send As permission is applied to the user’s account in Active Directory Users and Computers and they still cannot send email from their BlackBerry smartphone, then the Microsoft Exchange permission cache must be cleared before they can send email again.
There are 2 methods that can be used to clear the Microsoft Exchange permissions cache, only one method needs to be done to clear the Microsoft Exchange permission cache.
Method 1
Do not send any email from the user’s BlackBerry smartphone for 2 hours. This will cause the cached permission to expire. After 2 hours, when the user tries to send email, the Microsoft Exchange Server will not have a cached permission and will need to read the current Send As permission value from Microsoft Active Directory.
- The 2 hour timer for the Microsoft Exchange permission cache starts at the time that last email send was attempted.
- If the user attempts to send an email before the 2 hours is up and the Send As permission is still present in the Microsoft Exchange permission cache, the 2 hour timer will be reset and will begin again from time of the most recent email send attempt.
Restart the Microsoft Exchange System Attendant and Microsoft Exchange Information Store. Restarting these services purges the Microsoft Exchange permission cache and Microsoft Exchange will read the current Send As permission from Microsoft Active Directory when the next the user sends an email.
Important Note : Restarting the Microsoft Exchange System Attendant and Microsoft Exchange Information Store is not recommended by Research In Motion. If the services do not restart correctly or any errors are encountered as a result of this restart, it is outside the scope of support.
For Free Email Tech Support Contact Us: 1-800-935-0537
ReplyDeletehttp://computertechsupport.us/