Failed exchange event sink - methods to troubleshoot

THIS CODE AND INFORMATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE.

Failed exchange event sink - methods to troubleshoot

I had a customer that reported failures with an event sink working on one machine but failing on another server. This article lists methods to help, remind anyone what steps to take to help find a solution quicker.

This customers event sink worked for many other clients but just failed for this one customer.

"The event sync don’t receive the event from the exchange.”

What they had was an application that can change outgoing emails to add things such as a disclaimer to the email.The application works using Exchange 2003 smtp event sinks and registering to recieve the OnSessionStart event.The application is installed and works for many different clients but for one of out clients we are unable to get the application to function. The event sink seems to be registered correctly but it is not recieving events from the exchange server.

The problems turned out to be a combination of missing dlls in the GAC, invalid dll registration, security and assembly versioning.

I've listed below methods we took to determine how to troubleshoot and resolve this.

-Security:One of the most common problems why an event sink will fail to fire will be around security.Event sinks in Exchange run out of process so they must have a Com wrapper configured that sets a specific identity for it to run under. To provide a security context so that your event sink can run out-of-process on Exchange you must wrap your event sink as a COM+ component application. This is done before registering an Event Sink.

On Windows 2003, to create a COM+ application for an event sink Click Start, point to All Programs, then Administrative Tools, and click Component Services.In Component Services, select COM+ Applications under Console Root\Component Services\Computers\My Computer.Right-click COM+ Applications, point to New, and click Application.Click Next, then click Create an empty application.Name the application, verify that Server application is selected, and then click Next.On the Set Application Identity page, click This User. Browse for an appropriate account, one that has the necessary permissions to perform the tasks in the event sink, and enter the password for this account. It is recommended that you not select the Interactive User option because the Exchange server will not normally have a user logged on interactively. Click Next, Next, and then Finish.Open the new application, and right-click Components in the tree view.Click New and then click Component.Click Next and then Import component(s) that are already registered.When the list displays, select your component, Click Next, click Finish, and click OK to close Component Services.Right-click on the application and select Properties.Select the Security tab. Uncheck the Enforce access check for this application box and select the Perform access checks only at the process level. radio button.Click OK.

If you use an administrator account as the identity for the sink don't expect that this will have rights to folder you registering the sink on. Make sure whatever account you use as the Com+ identity can access the folder in question and has rights to read and create items in this folder.If you are developing your sink on a Exchange server then you can debug your sink with the Visual Studio debugger, your sink does need to be at a level where it can actually fire though (eg no problems with the underlying assemblies you have used).

- take a look at the applicaiton event logs to determine what event ids you get back- Try increasing diagnostic logging on Logons on the Store your trying to register the sink on this can help you at least see if anything is trying to logon to the store when you event should fire.

-Missing DLLs in the GacThe Global Assembly Cache (GAC) is a central repository for storing shared assemblies. The GAC allows multiple versions of the same assembly to be installed and also prevents different assembly vendors from overwriting each other's assemblies. The file responsible for installing the assemblies manually is GACUTIL, with the GAC located at C:\WINDOWS\assembly.

Assemblies are of two types: application private and shared. The default is application private and only one application uses them. These are the assemblies that are in the application folder. Shared assemblies are meant to be used by more than one application. It has a globally unique name (called a "strong name") and it must be defined in the GAC. GACUTIL will list, install, and uninstall assemblies in the GAC