"A fatal error (0x80040111) occurred" event ID 11 is logged when you use the MsExchange Event Services (Events.exe) in Exchange Server 5.5 or in Exchange 2000 Server

When you use the MsExchange Event Services (Events.exe) in a Microsoft Exchange Server 5.5 or a Microsoft Exchange 2000 Server environment, you may receive the following error message in the application event log when a client action spawns the activation of a script:

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

The 0x80040111 MAPI error translates to the MAPI_E_LOGON_FAILED error value. The scripts work correctly when you are using Exchange Server 5.5.

Depending on the size of your environment, you may notice that some or all scripts are not running. In a large environment, it may appear that the scripts are running successfully because of the inability to pinpoint the failing script.

This issue may occur if any one of the following conditions are true:

• At least one script was last modified by someone who shares the same alias, the same surname, or the same display name as someone else in the global address list.
• For an Exchange 2000 Server-based computer, the Exchange Event Service logs on as the local computer account instead of a service account.
• If you join an Exchange 2000 Server-based computer to the site, and then perform either of the following actions:
  • Move the mailbox that created the event scripts that are bound to a folder.
  • Move an existing Exchange Server 5.5 script to an Exchange 2000 Server-based computer.

Step1: Determine if there is a duplicate mailbox alias (Mixed or Pure Exchange environments)

Warning Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall your operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk.

1. Determine which mailbox has a duplicate alias by clicking on the EventConfig_servername folder for the server that is receiving the errors, then see who has Owner permissions. Do this because only the owners can modify the scripts.
2. Look for duplicate names by sending a new message to the alias, and then perform a check name procedure. If more than one mailbox is returned, check the surnames to see if there are duplicates.
3. To check for ambiguity for each of those aliases:
   • Type their alias in the To line of the client and perform a Check Name.
     -Or-
   • Type =alias on the To line, then press ALT+K.
     -Or-
   • Perform a directory export of the global address list and sort on the Alias column to see if any of the owners of the EventConfig_servername folder shows multiple listings.
4. Set diagnostic logging to Maximum (5) for the Event Service. This can only be done in the registry at:
   HKEY_Local_Machine/System/CurrentControlSet/Services/MSExchangeES/Parameters

NOTE If no duplicate mailbox aliases were discovered go to Step2.

After the multiple aliases have been determined, you must decide whether you want to choose a different (unique) mailbox to edit the scripts or remove the other mailboxes from the global address list.

If the scripts are installed in mailbox folders, the next part is even more detailed if you do not have a list of which mailboxes have scripts associated with them or there are many that do. This is because even with Event Service logging turned up to Maximum (5) in the registry, the Event ID 16385 (which occurs just before the Event ID 11) says that the folder being processed is Inbox. Every mailbox has an Inbox folder. So you cannot know which mailbox has been altered by the "rogue" EventConfig owner.

1. Post or send a message to the above mailboxes in a segmented fashion to determine when the Event ID 11 occurs. Twenty percent intervals during a quiet time in the environment are suggested.
2. When you find the mailbox, simply go into the script and save it while you are logged on as a unique mailbox alias.

If the scripts are installed in public folders:

1. Set Event Service logging to Maximum (5) in the registry.
2. Post or send messages to the public folders in the same fashion as described with mailboxes above, and monitor the application log.
3. Event ID 16385 tells you which folder it is processing and, in case there are multiple agents in the folder, Event ID 32773 tells you the agent that it's calling.
4. Log on to a unique mailbox that has Owner permissions on the EventConfig_servername and the public folder, then open the script, and save it.

Step2: Resolve known issues with permissions (Mixed or Pure Exchange environments)

1. Open the Active Directory Users and Computers snap-in, right-click the domain user account under which Event Service runs, and then click Properties.
2. On the Member Of tab, add the domain account user to the built-in Administrators group if Event Service runs on a member server. Alternatively, add the user to the Domain Administrators group if Event Service runs on a domain controller.
3. Add the user to the Exchange Domain Servers group in the server's domain so that the user has full access to all Exchange 2000 resources. Alternatively, give the user full access to selected Exchange 2000 resources:
   1. Right-click the public store or the private store where the event scripts are installed, and then click Properties.
   2. On the Security tab, click Full Control Permissions.
   3. Repeat steps A and B for each public store or private store to which you want to give the user full access.
4. Grant Owner permissions to any public folders that contain an event script:
   1. Right-click a folder that contains an event script, and then clicks Properties.
   2. On the Permissions tab, click Client Permissions, and then click the domain administrator account.
   3. Under Roles, click Owner.
   4. Repeat steps A through C for each public folder that contains an event script.
   
   NOTE You cannot grant Owner permissions on a root folder, such as the default Public Folder node.
5. Click Start, point to Programs, click Administrative Tools, and then click Services.
6. Right-click Microsoft Exchange Event Service and then click Properties.
7. Click the Log On tab, type the user name of the account used by Event Service in the Logon box, type the user password in the Password box, and then click OK to configure Event Service for automatic startup.
8. Under Services, right-click Event Service, and then click Start.
   NOTE In a mixed environment, you can use an Exchange Server 5.5 service account to start the event service.

NOTE Step1 and/or Step2 should resolve the event error in a pure Exchange 5.5 organization. If Event ID 11 is still being logged and you are in a mixed Exchange environment, go to Step3.

Step3 (Mixed Exchange 2000 and Exchange 5.5 environment only)

Add the MSExchange Event system service account on the Exchange 2000 Server-based computer to the folder client-permissions list as owner.
NOTE The additions of the same Exchange Server 5.5 service account to the Exchange 2000 Server event service does not resolve this issue.

An Event ID 15 is logged with the same MAPI error code (80040111) if the execution of the script has been scheduled to run. Make sure the mailboxes that have Owner permissions on the EventConfig_servername folder are not hidden because the Event Service algorithm needs to resolve the name before it executes. It is a good idea to name the Event Service Accounts something that will be unique to the global address list and always log on as this person when you want to modify the scripts.
The EventSink caches the information about the last person who modified the script. However, if there is more than one user in the global address list with the same alias as the person that last modified a folder's Agent or Script, the Collaboration Data Objects (CDO) routine cannot determine which alias is the correct one, so it stops responding and logs the 80040111(MAPI_E_LOGON_FAILURE) error. This error creates the impression that the account that caused the script to run doesn't have the necessary permissions on the folder, which is not true. In fact, it is the CDO routine that fails to log on to run the script from within the Event Service.
For more information about how to use Exchange Event Service with Exchange 2000, click the following article number to view the article in the Microsoft Knowledge Base: