I am sure that at some point your users have come to you and complained that they can’t send email. You can take a look at the logs and also at a particular user’s setting to see if there if anything different about their profile.

Sometimes they will try to send an email but get back a message similar to the following: This message could not be sent. Try sending the message again later, or contact your network administrator. The Microsoft Exchange server is currently busy. If this message is still displayed in 30 minutes, contact your Exchange server administrator. Error is
[0x80040111-0x80040111-0x000520].

There are other situations when you may get the error code 0×80040111 such as:

• PRB: Error “ClassFactory Cannot Supply Requested Class” (80040111 …  (279129).
• Attempting to install Microsoft Windows Live OneCare.
• If you have two instances of Microsoft SQL Server 2000 on the same computer, and SQL Mail is configured with separate mail profiles on each instance.
• Move Mailbox operation is unsuccessful.
• Logons to the Microsoft Exchange server computer fail and you get “The information store could not be opened” error message.
• If the MSSQLServer Service startup account is set to the local system account and xp_startmail fails.
• Exchange 2000 Management Pack MAPI Logon Check Reports Logon Failures.

Sometimes you receive fatal error messages when you use the MsExchange Event Services (Events.exe) in Exchange Server 5.5 or in Exchange 2000 Server to process messages. This can happen when a client action spawns activation of a script and they get the following error message:

A fatal error (0×80040111) occurred in an IExchangeEventSink while processing message [Subject = "xxx"]

This is a MAPI error which translates to the MAPI_E_LOGON_FAILED error value.

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:
  o Move the mailbox that created the event scripts that are bound to a folder.
  o Move an existing Exchange Server 5.5 script to an Exchange 2000 Server-based computer.

You should first determine if there is a duplicate mailbox alias (Mixed or Pure Exchange environments). You can do this by following the steps listed below. (Remember to always backup your Registry.)

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:
   o Type their alias in the To line of the client and perform a Check Name.
   -Or-
   o Type =alias on the To line, then press ALT+K.
   -Or-
   o 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

If no duplicate mailbox aliases were discovered then you should resolve known issues with permissions (Mixed or Pure Exchange environments).

If duplicate mailbox aliases were discovered then you have to 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.
3. If the scripts are installed in public folders:

• Set Event Service logging to Maximum (5) in the registry.
• Post or send messages to the public folders in the same fashion as described with mailboxes above, and monitor the application log.
• 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.
• 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.