This topic provides information about using Exchange Store Event Sinks to develop messaging applications.
Introduction
Exchange store events are used to build procedures that react to events in the Exchange store. There are three types of Exchange store events: synchronous events, asynchronous events, and system events.
Caveats
To use script-based event sinks, the Script Host Sink COM component must be registered on the Exchange server. Doing this allows script-based event registrations on any folder by any user who already has write permission on the folder.
Functional Criteria
| Criteria | Exchange Store Event Sinks |
|---|
| Application Domain | Exchange store events are used to respond to occurrences within the Exchange store. These typically include timers, notifications, automatic categorization, workflow applications, item validation, and Exchange store maintenance. |
| Major Objects | Applications that use Exchange store events register those events to be fired when specified events occur on the folder or item in the Exchange store. The API interfaces 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. |
| Application Architectures | Exchange store events are typically used in combination with other technologies, because Exchange store events work entirely inside the Exchange store. Information is usally presented to an application user by using a Windows client or ASP application. |
| Remote Usage | Exchange store events can only be run on the Exchange server that manages the store where the events are registered. In addition, the event sink can only access information within the Exchange store that they are registered in; cross-store access is not possible. |
| Transactions | None. Note, however, that 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 events do not by themselves generate Windows Event Log entries. The underlying ExOLEDB provider generates performance counters for each event sink. The code that executes in response to an Exchange store event code can also generate Windows Event Log events and information for Windows Performance Counters. |
| Availability | Currently shipping with Exchange 2000 Server and Exchange Server 2003. No changes are planned at this time. Future versions after Exchange 2003 might not include, or provide access to, this technology. |
Development Criteria
| Criteria | Exchange Store Event Sinks |
|---|
| Languages and Tools | Exchange Store Events can be implemented by using any COM/Automation-compatible language, as well as non-COM languages such as C/C++. |
| 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 with COM interoperability. |
| Scriptable | Event sinks can be created as scripts that use Windows Scripting Host by registering the Script Host Sink for the event and supplying the script code to process the event. |
| Test/Debug Tools | No special debugging tools are needed to debug applications that use Exchange store event sinks. |
| Expert Availability | Developers who have significant previous experience with Exchange store events are uncommon. |
| Available Information | Exchange store events are discussed in some Microsoft and third-party Exchange development books. They are also described in the Exchange Server 2003 SDK and in the Exchange 2000 Server SDK. Use the documentation appropriate to the version of Exchange you are developing for. To access the Exchange Server 2003 and Exchange 2000 Server SDKs, see Microsoft Exchange Server  on MSDN. |
| Developer/Deployment Licensing | Refer to your Exchange and MSDN subscription licensing agreements to determine whether additional licenses are required for the computers on which your Exchange store events applications are developed and deployed. |
Security Criteria
| Criteria | Exchange Store Event Sinks |
|---|
| Design-Time Permissions | Event registrations can be added to Exchange store items and folders by the owner of the folder. 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 in which they have write permission. Caution should be used when granting anyone permissions to register components on the Exchange server. |
| Setup Permissions | Setting up applications that use Exchange store event sinks must be performed by a user having sufficient permission to register the event sinks on the folder. Additional permissions may be needed to register the COM component, and create a COM+ application on the Exchange server. |
| Run-Time Permissions | Running applications that use Exchange store events requires permissions to write into the folders where the events are run. |
| Built-in Security Features | Exchange store event sinks run under the security context of the user account set for the COM+ application. COM+ role-based security can be used to control access and specify the security context of the event sink process. |
| Security Monitoring Features | None. |
Deployment Criteria
| Criteria | Exchange Store Event Sinks |
|---|
| Server Platform Requirements | Exchange store events can only be run on a computer on which Exchange is running. |
| Client Platform Requirements | Not applicable; Exchange store events are not a client-side technology. |
| Deployment Methods | Registering an event sink in 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. Exchange Explorer, WebDAV, and ADO can be used 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 event sinks. |
| Deployment Notes | Exchange store events that can be misused, or that can cause problems if installed incorrectly, should implement the ICreateRegistration interface, and programmatically prevent the event sink from being improperly registered. Cross-store access from within an event sink is not possible. Once registered and wrapped as COM+ applications, any user who knows the name of the event sink can register it in a folder to which they have write permissions. |
