Exchange store event sinks evaluation criteria

Application function

You can use Exchange store event sinks in your application to respond to occurrences within the Exchange store. These typically include timers, notifications, automatic categorization, workflow applications, item validation, and Exchange store maintenance.

Availability

Exchange store event sinks are available in Exchange Server 2003 and Exchange Server 2007. They are not available in versions of Exchange starting with Exchange 2010.

Application architectures

Exchange store event sinks are typically used in combination with other technologies, because Exchange store events work inside the Exchange store. Information from an Exchange store event sink is presented to an application user by means of a Windows client or ASP application.

Remote usage

You can only run Exchange store event sinks on the Exchange server that manages the store where the events are registered. In addition, the event sinks can only access information within the Exchange store that they are registered in; they cannot access information across stores.

Major objects

Applications that use Exchange store event sinks register those events to be fired when specified events occur on the folder or item in the Exchange store. The APIs defined for events specify the calling conventions used by the Exchange store when events are fired. The code that implements the events must present those interfaces.

Data access model

None.

Threading models

Event processes should not spawn any additional threads.

Transactions

The Exchange store events act as part of the transactions that occur as items are stored, modified, and deleted within the Exchange store.

Management capabilities

Exchange store event sinks do not generate Windows Event Log entries. The underlying Exchange OLE Database (ExOLEDB) provider generates performance counters for each event sink. The code that executes in response to an Exchange store event can also generate Windows Event Log events and information for Windows Performance Counters.

Languages and tools

You can use any COM/Automation-compatible language, as well as non-COM languages such as C/C++, to implement Exchange store event sinks.

Managed implementation

The Exchange store is not a managed application. However, it is possible to implement Exchange store event sinks in managed code and to use the underlying ExOLEDB provider with COM interoperability.

Scriptable

You can create event sinks as scripts that use Windows Scripting Host (WSH) by registering the Script Host Sink for the event and supplying the script code to process the event. For performance, reliability, and security reasons, we do not recommend that you use scripting languages to write Exchange store event sinks.

Test/debug tools

You do not need any specific debugging tools to debug applications that use Exchange store event sinks.

Expert availability

Developers who have significant experience with Exchange store event sinks are difficult to find.

Available information

Exchange store event sinks are described in some Microsoft and third-party Exchange development books. For more information about Exchange store event sinks, see the Exchange Server 2003 SDK.

Developer/deployment licensing

Refer to your Exchange and MSDN subscription licensing agreements to determine whether additional licenses are required for the computers that your Exchange store event sink applications are developed and deployed on.

Design-time permissions

Item and folder owners can add event registrations to Exchange store items and folders. If the event sink code is contained in a COM component, that component must be registered on the Exchange server and wrapped in a COM+ application. This requires domain or enterprise administrative privileges. To register script-based events, the Script Host Sink COM component must be registered on the Exchange server and wrapped in a COM+ application. Registering these COM components may require additional permissions on the Exchange server. Note that after the component is registered on the Exchange server, any user can register a script-based event sink on folders for which they have write permission. Be careful when you grant users permissions to register components on the Exchange server.

Setup permissions

A user must have sufficient permissions to register event sinks on the folder in order to set up applications that use Exchange store event sinks. Users might need additional permissions to register the COM component and create a COM+ application on the Exchange server.

Run-time permissions

Users must have permissions to write into the folders where the events are run in order to run applications that use Exchange store event sinks.

Built-in security features

Exchange store event sinks run under the security context of the user account set for the COM+ application. You can use COM+ role-based security to control access and specify the security context of the event sink process.

Security monitoring features

None.

Server platform requirements

You can only run Exchange store event sinks on Exchange 2003 or Exchange 2007 servers. You cannot use Exchange store event sinks with versions of Exchange starting with Exchange 2010.

Client platform requirements

Not applicable; Exchange store event sinks are not a client-side technology.

Deployment methods

Registering an event sink on a folder involves creating an event registration item in the folder, setting the appropriate properties on the item, and making the event sink code available on the server. You can use Exchange Explorer, WebDAV, and ADO to register event sinks. For script-based event sinks, the Script Host Sink COM component must be registered on the Exchange server. If the event sinks are contained in a COM component, that component must be registered on the Exchange server and configured as a COM+ application. The Exchange Explorer tool, and the eshmts.vbs and regevent.vbs scripts, are also available for use with Exchange store event sinks.

Deployment notes

For Exchange store event sinks that can be misused, or that can cause problems if installed incorrectly, we recommend that you implement the ICreateRegistration interface and programmatically prevent the event sink from being registered incorrectly. Cross-store access from within an event sink is not possible. After event sinks are registered and wrapped as COM+ applications, any user who knows the name of the event sink can register it in a folder for which they have write permissions.

July 16, 2012

Initial publication