Unable to send email messages because the Send As permission has been revoked

Article ID: KB04707

Type: Support Content

Last Modified: 11-15-2012

 

Product(s) Affected:

  • BlackBerry Enterprise Server for Microsoft Exchange
CollapseEnvironment
  • BlackBerry Enterprise Server 2.1 to 5.0 SP4 for Microsoft Exchange
  • Windows Server 2003
  • Windows Server 2008
CollapseOverview

Note: If all of the BlackBerry smartphone users on the BlackBerry Enterprise Server are unable to send email messages with this error, and all of these 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 and Configuration Guide to set up the default Send As permission for the BlackBerry service account. Once the default Send As permission is set as directed in the installation guide, wait 30 minutes to allow the Security Descriptor Propagator task to run and then refer to Confirming if the Send As Permission is present on a user account and Clearing the Microsoft Exchange permission cache in the Additional Information section of this article 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 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 BlackBerry smartphone users are affected, refer to the note at the top of this section to set the Send As permission for all BlackBerry smartphone 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

CollapseCause

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 Help and Support site. 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, refer to AdminSDHolder, Protected Groups, and SDProp article in the September 2009 edition of the TechNet online magazine, which can also be found on the Microsoft TechNet website by searching for AdminSDHolder, Protected Groups and SDPROP.

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 that include the new permissions for protected groups by default.

CollapseResolution

The recommended resolution for this issue is to remove the affected user from any protected groups.

For a BlackBerry smartphone user who needs an account in a Windows protected group, it is recommended to provide a second account for the BlackBerry smartphone 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 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 resolution recommended by Research In Motion and Microsoft.

Complete the following steps to remove the user from a Windows protected group:

  1. Open Active Directory Users and Computers.
  2. Navigate to the affected user.
  3. Right-click the user and select Properties.
  4. Select the Member of tab.
  5. Remove the user from the protected group or groups. See the Cause section for information on how to locate the current list of protected groups within the Microsoft support web site.

    Note: When looking at group memberships, keep in mind that it is possible for a user to be a member of a subgroup that is a member of a protected group. Example: User A is a member of Group A, and Group A is a member of a protected group.

  6. Click Apply.

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.

Confirm the user has been removed from all protected groups, including any which may have been due to inheritance from other groups.

  1. Open Active Directory Users and Computers.
  2. From the menu, select View > Advanced Features.
  3. Navigate to the user that was removed from the protected group(s).
  4. Right-click the user and select Properties.
  5. Select the Security tab.
  6. Click the Advanced button.
  7. Enable the inherited permissions for the user.
    • On Windows Server 2003, select the All inheritable permissions from the parent to propagate to this object check box
    • On Windows Server 2008, select the Include inheritable permission from this object’s parent check box
  8. Click Apply.
  9. Confirm the Send As permission now appears in the Permission entries: list with the name of the BlackBerry Enterprise Server service account.
  10. Click OK.
  11. Click OK.
  12. Complete steps 4 to 12 for any other users removed from a protected group.

    Note: The Workaround in Microsoft KB817433, which can be found by searching Microsoft Help and Support for Delegated permissions are not available and inheritance is automatically disabled, contains a Visual Basic script to re-enable inheritance for all Active Directory users simultaneously. This script can greatly speed up this process for large batches of users. Since members of protected groups will correctly have the Include inheritable permissions setting cleared the next time SDProp runs, only the Active Directory users who are no longer members of protected groups will be affected.

  13. Follow the steps for Clearing the Microsoft Exchange permission cache in the Additional information section of this article.

    Note: Confirm in 30 minutes that the Include inheritable permissions check box is still selected. If in 30 minutes the check box is cleared, 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.
CollapseWorkaround

If it is not practical to remove the user from the protected group, two workarounds can be done to force the Send As permission onto user accounts in protected groups. Both of these workarounds modify Microsoft's recommended Microsoft Active Directory permissions for user accounts in protected groups. Only one of the workarounds must 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 must be run again to apply it to the new service account.

Workaround 1 – Modify the ACL using the DSACLS command line tool

This workaround uses the Microsoft tool DSACLS to force the Send As permission onto all protected groups by changing the AdminSDHolder object. For additional information about this workaround refer to the Workaround in Microsoft KB907434, which can be found on the  Microsoft Help and Support  web site by searching for The Send As right is removed from a user object after you configure the Send As right in the Active Directory Users and Computers snap-in in Exchange Server.

Complete the following steps to apply this workaround:

  1. Log in to a domain controller for the network.
  2. Ensure that the DSACLS utility is installed on the computer that the workaround would be applied 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:
    • On the last line, replace BESAdmin with the name of the BlackBerry server account if different than the default of BESAdmin
    • On all lines, replace dc=domain,dc=local with the name of the Windows domain

      For example, if the Windows domain is eastern.mycompany.local, the new text would be dc=eastern,dc=mycompany,dc=local.

      To locate the name of the domain, find the domain node in the Active Directory Users and Computer tree list.  The domain should read <lat.local> or similar.

  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 that This command completed successfully is there for each line that was executed and there are no errors.

    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.

  10. Wait 30 minutes for the Microsoft Active Directory to update the protected user accounts with the new Send As permission.
  11. 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 article.
  12. Clear the Microsoft Exchange permission cache by following the steps for Clearing the Microsoft Exchange permission cache in the Additional Information section of this article.

Workaround 2 – Modify the AdminSDHolder object

This workaround changes 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 that 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 Advanced.
  8. Click Add.
  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 list, select User Objects for if using Microsoft Exchange 2003 or Descendant User objects if using Microsoft Exchange 2007 or 2010.
  12. In the Permissions list, find Send as and select the Allow check box.
  13. Click OK to close the dialog box.
  14. Click OK to close the Advanced dialog box.
  15. Click OK to close the user properties dialog box.

    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.

  16. Wait 30 minutes for the Microsoft Active Directory to update the protected user accounts with the new Send As permission.
  17. 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 article.
  18. Clear the Microsoft Exchange permission cache by following the steps for Clearing the Microsoft Exchange permission cache in the Additional Information section of this article.
CollapseAdditional Information

Confirming if the Send As permission is present on a user account

The 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.
    Note: The following steps require that Advanced Features be enabled. The option can be found in the View menu.
  2. Navigate to the user account that needs the Send As permission checked.
  3. Right-click the user account and select Properties.
  4. Select the Security tab and click Advanced.
  5. In the Permission entries list, look for an entry with the name of the BlackBerry server service account, often referred to as BESAdmin, in the Name column.
  6. When found, confirm the permission from the Permission column. If the permission cannot be found, then the Send As permission is not applied on the user's account. One of the following three scenarios will indicate success:

    Scenario 1

    Name - the name of the BlackBerry Enterprise Server service account
    Permission - Send as
    Inherited From - the Organizational Unit the permission is being inherited from

    Scenario 2

    Name - the name of the BlackBerry Enterprise Server service account
    Permission - Special
    Inherited From - <not inherited>

    Scenario 3


    Name - the name of the BlackBerry Enterprise Server service account
    Permission - Send as
    Inherited From - <not inherited>

Note: It is possible for the Send as permission to show as being granted for a user, but still be unable to send because it has been revoked. See Internal notes for information on using ADSIEdit to confirm if user is member of protected group.

How to use LDIFDE to determine if user account is being listed as an Administrator

  1. Log into the domain controller using an account that has Domain Admin rights.
  2. Open up a Command prompt and run the following command:

    ldifde -f c:\output.txt -r
    mail=affecteduser@domain.com

    Note: Replace the affecteduser@domain.com with the email address of the person you need the attributes for.
  3. Open the text file specified above and search for adminCount: 1
  4. If this value exists, this indicates that the user account is flagged as being a member of a protected group, which can/will revoke the Send As permissions.

Clearing the Microsoft Exchange permission cache:

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 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 users from sending email from their smartphones.

If it has been confirmed that the Send As permission is applied to the user’s account in Active Directory Users and Computers and the user still cannot send email from the smartphone, then the Microsoft Exchange permission cache must be cleared before email messages can be sent 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 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.

Note: To ensure that no messages are sent from the device it is highly recommended to power the BlackBerry Smartphone off for two hours or at least disable the data services (the latter will allow to use it as a phone). To disable data services go to Options on the device, and select Mobile Networks. Set Data Services to Off.

Method 2

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 the next time 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.

This article contains information previously documented in KB20873, KB13813, and KB17651.

Disclaimer

By downloading, accessing or otherwise using the Knowledge Base documents you agree:

   (a) that the terms of use for the documents found at www.blackberry.com/legal/knowledgebase apply to your use or reference to these documents; and

   (b) not to copy, distribute, disclose or reproduce, in full or in part any of the documents without the express written consent of RIM.


Visit the BlackBerry Technical Solution Center at www.blackberry.com/btsc.