ExOLEDB Evaluation Criteria
Topic Last Modified: 2008-09-02
This topic provides information about using Exchange OLE DB Provider (ExOLEDB) to develop messaging applications.
Through the Exchange OLE DB provider (ExOLEDB), programmers can access the Exchange store by using OLE DB and Microsoft ActiveX Data Objects (ADO). ExOLEDB can be used on the local Exchange server to access Exchange store items.
Caveats
The ExOLEDB provider can only be used on a computer where Exchange is running, and only to access stores located on that computer. ExOLEDB cannot be used on Exchange front-end servers. To access remote public stores and mailbox stores, use the WebDAV protocol, MAPI, or CDO 1.2.1.
Functional Criteria
| Criteria | Exchange OLE DB Provider (ExOLEDB) |
|---|---|
Application Domain |
Applications that use ExOLEDB typically access information from the Exchange store by using SQL queries. ExOLEDB can be used to retrieve and manipulate all types of data in the Exchange store that the user has permission to access. ExOLEDB also provides full-text search capability with items in the Exchange store. |
Major Objects |
ExOLEDB is not typically used as an object model, but as an OLE Database Provider, with ActiveX Data Objects (ADO). ExOLEDB exposes an OLE DB version 2.5 object model that allows direct access without the overhead of ADO. |
Data access model |
ExOLEDB provides a purely database-style model. |
Threading Models |
Applications that use ExOLEDB do not directly access it, and so threading restrictions are determined by the application and ADO (or WebDAV). |
Application Architectures |
Because the ExOLEDB provider must be run on the Exchange server, and can only access data that is located on that server, applications that use ExOLEDB must also run on the Exchange server. These are typically ASP applications that require access to information stored in the Exchange store. |
Remote Usage |
ExOLEDB cannot be used remotely. |
Transactions |
Transactions are not directly supported by ExOLEDB. |
Management Capabilities |
ExOLEDB provides performance counters that can be used to analyze application performance and health, as well as to measure the response time of the Exchange server. |
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 OLE DB Provider (ExOLEDB) |
|---|---|
Languages and Tools |
ADO can be used with any COM/Automation-compatible language, as well as with non-COM languages such as C/C++. |
Managed Implementation |
ExOLEDB is an unmanaged component. Use of the ExOLEDB provider is supported under the COM Interoperability layer of Visual Studio .NET and the .NET Framework. ExOLEDB can only be run on a computer on which Exchange has been installed. |
Scriptable |
ExOLEDB is scriptable by using ADO. |
Test/Debug Tools |
No special debugging tools are needed to debug applications that use ExOLEDB. |
Expert Availability |
It is relatively easy to find experts who know ADO and SQL well. It may be a bit more difficult to find people who are already familiar with the particulars of the full-text search query language. |
Available Information |
ExOLEDB is discussed in some Microsoft and third-party Exchange development books. It is also described in the Exchange Server 2003 SDK and in the Exchange 2000 Server SDK. Use the documentation appropriate to the version of Exchange for which you are developing. To access the Exchange Server 2003 and the Exchange 2000 Server SDKs, see the Exchange Server Developer Center. |
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 ExOLEDB applications are developed and deployed. |
Security Criteria
| Criteria | Exchange OLE DB Provider (ExOLEDB) |
|---|---|
Design-Time Permissions |
Depending on the development environment and configuration being used, developers might need Exchange administrative permissions for the servers with which they are working. Use caution when granting anyone unrestricted access to user mailboxes and Exchange system configuration settings. |
Setup Permissions |
Applications that use ExOLEDB must be run on the Exchange server on which the data is stored, and the user installing the application must have permissions on that Exchange server. Use caution when granting anyone permission to install software on a production Exchange server. Those permissions should be reviewed after the application is installed and tested. |
Run-Time Permissions |
Because applications that use ExOLEDB reside on the Exchange server where the data is stored, the user running the application must have sufficient permission to access the data. |
Built-in Security Features |
ExOLEDB uses the underlying Microsoft Windows 2000 (or Windows Server 2003) security features. |
Security Monitoring Features |
None. |
Deployment Criteria
| Criteria | Exchange OLE DB Provider (ExOLEDB) |
|---|---|
Server Platform Requirements |
ExOLEDB can only be run on a computer on which Exchange is running, and can only access databases and storage groups that are actually managed by that Exchange server. ExOLEDB can not be used on front-end Exchange servers. |
Client Platform Requirements |
Not applicable; ExOLEDB is not a client-side technology. |
Deployment Methods |
If the client or application being installed needs access to ExOLEDB, the installer should verify that the computer is running Exchange, and that the server has storage groups/databases managed by it. |
Deployment Notes |
None. |