An event ID 11 error message is logged in Exchange 2000 or in Exchange Server 5.5: "A fatal error (0x8004011d) occurred"

In a mixed Microsoft Exchange 2000 Server and Microsoft Exchange Server 5.5 environment, the following event ID message may logged in the Application log by the Microsoft Exchange Event service on the Exchange Server 5.5 computer:

Event ID: 11
Source: MSExchangeES
Type: Error
Category: General
Description:
A fatal error (0x8004011d) occurred in an IExchangeEventSink while processing message [Subject = "xxx"].

This event occurs after an Exchange 2000 user modifies an event script on an Exchange Server 5.5 public folder. If an Exchange Server 5.5 user modifies the same script, the script functions correctly.

The event ID 11 message and an event ID 1023 message that resembles the following message may be logged in a pure Exchange Server 5.5 environment soon after the Event service starts:

Event ID: 1023
Source: MSExchangeIS Private
Type: Failure Audit
Category: Logons
Description:
Domain\ServiceAccount was validated as /o=ORG/ou=Site/cn=Configuration/cn=Servers/cn=ServerName/cn=Microsoft System Attendant but was unable to log on to /o=ORG/ou=Site/cn=Recipients/cn=UserName.

It may take approximately one minute for the event ID 11 message to be logged in the Application event log. In some scenarios, the event 1023 message or the event ID 11 message does not appear at all. See the "More Information" section for information about scenarios in which these messages are not logged.

When the Event service is triggered to run an event script in a mixed Microsoft Exchange 2000 Server and Microsoft Exchange Server 5.5 environment, the Event service tries to impersonate the user who most recently modified that event script. When an Exchange 2000 user has been the most recent to modify the script, the Event service tries to log on as that user. However, because the Exchange Server 5.5 service account does not have access rights to the Exchange 2000 user's mailbox, the log on attempt is denied. The script cannot run, and the event ID 11 message that is described in the "Summary" section is logged. In Exchange Server 5.5, the service account has inherited permissions to every mailbox. Therefore, when an Exchange Server 5.5 user is the last user to modify the event script, the Event service has the correct permissions with which to log on in that user's context. However, in Exchange 2000, there is no service account that has permissions to all mailboxes.

In a pure Exchange 5.5 environment, you can ignore these event messages. These events are generated when you delete a mailbox or a public folder without first removing a published Event Script from the mailbox or the public folder. For example, if you publish a script to the Inbox of a mailbox, and then you delete the mailbox without first removing the published script, Exchange continues to try to monitor the Inbox of this non-existent mailbox. Every time that you start the Event service, Exchange searches the Inbox of the non-existent mailbox. This causes the event ID 11 and 1023 messages to be logged.

A mixed Exchange 2000 and Exchange Server 5.5 environment

To resolve this behavior in a mixed Exchange 2000 and Exchange Server 5.5 environment, grant the Exchange Server 5.5 service account rights to the user who is modifying the scripts. When you do this, the Event service can log on as the Exchange 2000 user to run the script.

A pure Exchange Server 5.5 environment

To resolve this issue in a pure Exchange Server 5.5 environment, use either of the following methods:

• Remove and reinstall the Exchange Event service.
• Use the Mdbvu32 program from the Exchange Server 5.5 CD-ROM to access the Event Config folder for the server on which the Event Service is installed. Then, remove the published scripts and the references to the non-existent folders in which the scripts were originally published from the Event Config folder.

Mdbvu32.exe is located in the Server\Support\Utils\I386 folder on the Exchange Server 5.5 CD. You can run the tool directly from the CD. Or you can copy the following files to a specific folder, and then run Mdbvu32 from that folder:To prevent the events from occurring, you must delete two types of messages from the Event Config folder. One message contains the name of the folder in which the script was published. The other message contains the name that was given to the agent that is running the script in this folder.

To delete the information in the Event Config folder, follow these steps.

Note You can run the Mdbvu32.exe program from any Microsoft Windows NT-based computer as long as the Microsoft Outlook client is installed.

1. Log on to the Windows NT server by using the Exchange Service account.
2. Create an Outlook profile that logs on to a mailbox that resides on the Exchange Server computer on which the Event service is installed.
3. In the Exchange Server Administrator program, double-click Folders, double-click System Folders, and then double-click Events Root .
4. Click EventConfig_Servername, and then click Properties on the File menu. In this step, Servername is the name of the server on which the event service resides).
5. On the General tab, click Client Permissions.
6. Assign the mailbox for which you selected Owner permissions to the folder.
7. Double-click the Mdbvu32.exe program, and then click OK when you are prompted.
8. Click the appropriate Outlook profile to use, and then click OK.
9. From the MDB Viewer Test Application window, click MDB\Open Message Store.
10. Click Public Folders, and then click Open .
11. Click MDB\Open Root Folder, and click OK to the three error messages that appear.
12. Double-click NON_IPM_SUBTREE under Child Folders.
13. Double-click Events Root under Child Folders.
14. Click OK to the two error messages that appear.
15. Double-click EventConfig_ServerName under Child Folders.
16. Under Messages in Folder, the display names of the agents and scripts appear. Also, the folders in which these scripts were published appear. For example, a script was published to the Inbox of a mailbox. And, the agent or script is named "MB AGENT." In this example, the following text appears under Messages in Folder:
    \Inbox
    MB AGENT
    If the script was published to a public folder, the name of the public folder appears instead of "\Inbox".
    
    If a script was published to the Inbox of more than one mailbox, multiple instances of "\Inbox" appear. Also, if more than one agent or script has the same name, you see more than one instance of the agent name in the list. To find out which entries belong to the non-existent mailbox, you must double-click each entry to determine the mailbox to which it belongs.
17. Double-click the public folder name or the name of the mailbox folder such as "\Inbox" in the list.
18. Under Message Properties, look for a hexadecimal value of "0x3FF8." This value lists the display name of the mailbox that is being referenced.
    
    If the display name matches the display name of the deleted mailbox, click Close.
19. Make sure that the entry that you want to delete is still selected. Then, click lpFld-> DeleteMessages() in the Call Function list, click Call Function, and then click OK.
    
    The "\Inbox" entry is removed from the list. Follow this step to delete all the agent or script entries that reference the deleted mailbox or public folder.
20. To exit Mdbvu32, click Close until the MDB Viewer Test Application window is displayed. Close this window, click OK when you are prompted, and then click OK to the very next prompt.

The value 8004011d from the Description box of the event ID 11 message maps to the MAPI error MAPI_E_FAILONEPROVIDER. This error code indicates that the provider could not log on. However, this is not a fatal error. In this scenario, the credentials are not correct, and the user is not prompted with a dialog box because this error runs in the context of a service instead of interactively.

The event ID 1023 message is logged only when a script has been published to a mailbox that is then deleted. This event message is logged because the System Attendant tries to log on to the private information store of the deleted mailbox.

If a public folder has been deleted before the script is removed, the Event ID 11 message may occur only one time. Or, it may not occur at all. Or, only the following event is logged in the Application log: