Here is a common issue we see regularly with the Exchange Management Pack ...
You have just applied Security updates for your Exchange server. The update installation went fine. The next morning, your MOM Administrator sees Mail Flow Sender alerts every 15 minutes with the following Description:
The script aborted its execution due to the following error:
0x800405ED(-2147219987) Unexpected error code received from 'EMPMS.MailFlowSender', description: [Collaboration Data Objects - [E_ACCESSDENIED(80070005)]]
This event was generated by the script: "Exchange 2003 - Mail flow sender"
When you go back to check, you will note that you probably applied KB912442 MS06-029: Vulnerability in Microsoft Exchange Server could allow script injection when Exchange Server runs Outlook Web Access.
This Security update mentions article KB912918 Users cannot send e-mail messages from a mobile device or from a shared mailbox in Exchange 2000 Server and in Exchange Server 2003 . However, no mention is made in these articles of the Exchange Management Pack for MOM, so it may easily be missed by an SMS or network administrator applying the updates. Some additional information about this is also mentioned in KB 895949, although once again, the Exchange Management Pack is not discussed.
KB912442 changes the behavior of the "Send As" feature in Microsoft Exchange Server 2003. Prior to this change, any user with the “Full Mailbox Access” permission for a mailbox also had the ability to “Send As” the mailbox owner.
Before this update, granting the Full Mailbox Access permission implicitly granted permission to send as the mailbox owner. This meant that another account that has the Full Mailbox Access permission could send e-mail messages that appeared as if they were sent by the mailbox owner. Many Microsoft Exchange customers have requested that Send As permission be separated from the Full Mailbox Access permission for the following two reasons:
To deter e-mail spoofing.
To make sure that e-mail messages that are sent by a delegate can always be clearly distinguished from e-mail messages that are sent by the actual mailbox owner.
All new versions of the Exchange Information Store will now explicitly require the Send As permission in order to send e-mail messages as the mailbox owner. However, the following lists the three exceptions to this requirement:
The mailbox owner account does not require explicit Send As permission for its own mailbox.
The Associated External Account for a mailbox does not require explicit Send As permission.
A delegate account that also has the Full Mailbox Access permission does not require explicit Send As permission.
All other accounts that are granted partial or full access to a mailbox must now be explicitly granted the Send As permission for the mailbox owner account in order to send mail as the mailbox owner. This includes application service accounts that perform functions such as sending e-mail messages for mobile device users. This behavior occurs because the Send As permission is an Active Directory permission that applies to the Active Directory objects for which it is set. Granting the Send As permission on an Exchange database object gives you permission to the Send As permission the database itself. However, it does not give you permission to the users with Send As permissions who have mailboxes in the database. Note Granting the Receive As permission on an Exchange database is the functional equivalent of granting the Full Mailbox Access permission to all mailboxes that are in the database. This differs from the behavior of the Send As permission.In the Send As permission, the permission applies only to the database object itself. It does not to the mailboxes in the database. In the Receive As permission, the permission is apparently inherited by all mailboxes that are in the database. To better understand the difference between the two permissions, think of all the mailboxes in a database as if they were folders in a single mailbox (the "database" mailbox). If you have full access to the database, you have permission to access all the contents in the database. This includes all the mailboxes. The Send As permission, applies to the identity of an Active Directory user object, not to mailbox contents stored in a database. When e-mail messages are sent, they are not sent from a particular mailbox or database, but from a user. The user may be the mailbox owner or any other account that has the Send As permission. To resolve the issue for the Exchange Management Pack follow these steps:
Start the Active Directory Users and Computers management console.
On the View menu, make sure that the Advanced Features option is selected. If this option is not selected, the Security page will not be visible for User account objects.
Open the properties of the Test Mailbox for your Exchange server. If you have more than 1 Exchange server, you will need to follow these steps for each Exchange server. Please note that the Mail Flow Sender Script only sends mail from the mailbox of the Test Account on the First Mailbox Store, even if you have selected “Per Store Monitoring” in the Configuration Wizard. The other Test Accounts are used to test MAPI logon among other things, but are not used for the Mail Flow Scripts. You only need to apply these steps to the mailbox on the First Mailbox Store.
Click the Security tab.
Look for the Mailbox Access Account.
In the Permissions box, click Allow for the “Send As” permission for the appropriate account.
Note that it may take fifteen minutes for the Exchange Information Store to update its permissions cache and make the new permission effective.
An updated version of the Configuration Wizard that will add the “Send As” permission is planned, but has not been released yet. A date for the release of an updated Configuration Wizard has not yet been set.
PingBack from http://www.keyongtech.com/1355564-mailbox-access-account-impersonation-problem
I have tried the "Send As Permission" option on the MOM mailbox, but this does not seem to make any difference.
Do you have any other idea?