Exchange Rules
Exchange Rules
This content is no longer actively maintained. It is provided as is, for anyone who may still be using these technologies, with no warranties or claims of accuracy with regard to the most recent product version or service release. This topic provides information about using Exchange Rules to develop messaging applications.
Introduction
Microsoft® Exchange Server uses rules on mailboxes and other folders to automatically execute actions on objects in the folders. You can use rules to develop applications that carry out predefined or custom actions, even at times when the application is not running. Rules can be performed on the Exchange store (server-side) or on Microsoft Outlook® (client-side, deferred action rules).
Caveats
Functional Criteria
| Criteria | Exchange Rules |
|---|---|
| Application Domain | Exchange rules are typically used to specify user-defined actions that are to be performed on messages that arrive in folders of the user's mailbox. In addition, it is possible to use a set of predefined rules on Public Folders. |
| Major Objects | Exchange rules use two top-level objects: the Rules collection, and an object for an individual Rule. Alternatively, the IExchangeModifyTable can be used to work with folder rules. |
| Data access model | Exchange rules present data to applications as a set of hierarchical objects with methods and properties. |
| Threading Models | Rules are defined by applications that can be multi-threaded. The resulting rules run within Exchange (server-side rules) or within Outlook (client-side rules). |
| Application Architectures | Applications that programmatically control Exchange rules are typically e-mail processing client applications such as Outlook. In addition, applications that use mailboxes to manage messages in workflow processes can use Exchange server-side rules to perform parts of the workflow processing. |
| Remote Usage | The Exchange rules COM components use MAPI to communicate with the Exchange server and MAPI uses Remote Procedure Calls (RPC) to communicate with the Exchange server. Typically RPC is intentionally blocked from passing through Internet firewalls. However, Exchange 2003 does support RPC over HTTP, which can be configured to allow clients to remotely access an Exchange store. |
| Transactions | The COM objects for rules do not support transactions. |
| Management Capabilities | The Rules features have no special built-in management capabilities. The rules components can be used to manage server-side rules of users who have defined them, if the managing user has permissions to access the mailboxes and public folders. |
| Availability | The Exchange rules technology shipped in Exchange 5.5. Although the component does not ship with later versions of Exchange, rules are supported in all versions of Exchange. Future versions after Exchange 2003 might not include, or enable use of, this technology. |
Development Criteria
| Criteria | Exchange Rules |
|---|---|
| Languages and Tools | Applications that define and modify Exchange rules can be implemented by using any COM/Automation-compatible language, as well as non-COM languages such as C/C++. |
| Managed Implementation | Exchange rules COM objects are unmanaged components. Use of Exchange rules is supported under the COM Interoperability layer of Visual Studio .NET and the .NET Framework. |
| Scriptable | Exchange rules can be programmatically accessed by using scripts. |
| Test/Debug Tools | No special debugging tools are needed to debug applications that use Exchange rules. Client-side rules require Outlook for proper testing. |
| Expert Availability | Although it may be difficult to find developers who have direct experience using Exchange rules, most developers should be able to use the technology without problem. |
| Available Information | Information about using Exchange rules is available in the Exchange 5.5 SDK. To download the Exchange Server 5.5 SDK, see Microsoft Exchange Server .gif "Online link") on MSDN. |
| Developer/Deployment Licensing | No special licenses are required to deploy an application that uses WMI to access Exchange. Refer to your Exchange and MSDN subscription licensing agreements to determine whether additional licenses are required for the Exchange servers on which your application defines rules. |
Security Criteria
| Criteria | Exchange Rules |
|---|---|
| Design-Time Permissions | The developer must have permissions to access the desired folders and data in the Exchange store. |
| Setup Permissions | Setting up applications that use Exchange Rules typically requires the user to be a local administrator, or to have rights to install software. |
| Run-Time Permissions | No special permissions are required to deploy applications that use Exchange rules. |
| Built-in Security Features | None. |
| Security Monitoring Features | None. |
Deployment Criteria
| Criteria | Exchange Rules |
|---|---|
| Server Platform Requirements | The Exchange servers where user-defined rules are stored must be properly configured to allow access by MAPI clients. |
| Client Platform Requirements | The client application installer should verify that the proper version of MAPI is available on the computer, and that it is properly configured via the MAPISVC.INF file. |
| Deployment Methods | Applications that use MAPI can be deployed to client computers by using standard software distribution technologies. The installer should verify that the correct version of MAPI is available, and that it is configured properly. |
| Deployment Notes |
Send us your feedback about the Microsoft Exchange Server 2003 SDK.
This topic last updated: June 2006
Build: June 2007 (2007.618.1)
© 2003-2006 Microsoft Corporation. All rights reserved. Terms of use.