Migrating from Exchange 2007 Legacy APIs
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.
Topic Last Modified: 2008-08-12
By Michael Mainer, Programming Writer
Microsoft Exchange Server 2007 introduces the following new technologies:
- Exchange Web Services (EWS) to function as the primary API for interacting with the Exchange mailbox database
- Transport agents for processing Simple Mail Transfer Protocol (SMTP) messages
- The Exchange Management Shell for managing computers that are running Exchange 2007
If you are currently using WebDAV, Collaboration Data Objects for Exchange 2000 Server (CDOEX), event sinks, or Exchange OLE DB (ExOLEDB) for your applications, we strongly encourage you to migrate your applications to EWS, transport agents, and the Exchange Management Shell. These technologies are based on the Microsoft .NET Framework, and they represent the future of Microsoft Exchange programmability.
This article compares legacy API functionality included in Exchange 2007 against new Exchange 2007 technologies. Use this information to develop a migration strategy for your Exchange Server applications so that you can take advantage of the latest innovations that Exchange 2007 has to offer. In addition, you can use the Exchange 2007 Legacy API Property Mapping spreadsheet to help you with your migration planning.
Exchange Web Services vs. WebDAV
WebDAV and Exchange Web Services both offer you a way to remotely access the Exchange Server database. Exchange Web Services uses the WSDL, SOAP, and HTTP open standards; WebDAV is an extension of the HTTP standard. Both WebDAV and EWS use XML payloads to communicate with the Exchange server. However, Exchange Web Services provides strongly typed objects and Microsoft Office Outlook–compatible business logic, and WebDAV does not.
The following table provides a comparison of the functionality that is available in WebDAV versus Exchange Web Services.
Comparison between WebDAV and Exchange Web Services
| Functionality | WebDAV | Exchange Web Services |
|---|---|---|
Folder Access |
Yes |
Yes |
Item Access |
Yes |
Yes |
Yes |
Yes |
|
Contacts |
Yes |
Yes |
Attendee free/busy information |
Yes (WebDAV has limited free/busy support with the use of public folders but does not support the suggested meeting time feature.) |
Yes |
MIME content stream |
Yes |
Yes |
Ambiguous name resolution |
Yes |
Yes |
Delegate access |
Yes |
Yes |
Search |
Yes |
Yes |
Notifications |
Yes |
Yes |
Synchronization |
Yes |
Yes |
Search folders |
Yes |
Yes |
Access to MAPI properties |
Yes |
Yes |
Transaction locks |
Yes |
No |
Folder Associated Items (FAI) |
Yes |
No (EWS in future versions of Microsoft Exchange will expose FAI.) |
Extensible schema |
Yes |
No |
Complex calendaring (such as meeting handling) |
No |
Yes |
Delegate management |
No |
Yes |
Distribution list (DL) expansion |
No |
Yes |
Managed Folder support |
No |
Yes |
Server-to-server impersonation |
No |
Yes |
Change keys |
No |
Yes |
WebDAV is basically a data access layer. The Outlook-compatible business logic, remote accessibility, and strongly typed objects that Exchange Web Services provides make EWS the best option to replace WebDAV for Exchange Server client development.
Exchange Web Services vs. CDOEX
Exchange Web Services and CDOEX provide similar functionality. However, Exchange Web Services allows for more flexibility in where the client application can reside. EWS clients can reside on any computer that has HTTP access to an Exchange server that has the Client Access server role installed. CDOEX clients must reside on an Exchange server that has the Mailbox server role installed.
The following table provides a comparison of the functionality that is available in CDOEX versus Exchange Web Services.
Comparison between CDOEX and Exchange Web Services
| Functionality | CDOEX | Exchange Web Services |
|---|---|---|
Folder access |
Yes |
Yes |
Item access |
Yes |
Yes |
Yes |
Yes |
|
Complex calendaring (such as meeting handling) |
Yes |
Yes |
Contacts |
Yes |
Yes |
Attendee free/busy information |
Yes |
Yes |
MIME content stream |
Yes |
Yes |
Ambiguous name resolution |
Yes |
Yes |
Delegate access |
Yes |
Yes |
Search |
Yes |
Yes |
Access to MAPI properties |
Yes |
Yes |
iCalendar support |
Yes |
Yes |
Post to NNTP newsgroups |
Yes |
No |
Active Directory directory service object references |
Yes |
No |
MHTML body |
Yes |
No (You can use transport agents in Exchange 2007 to create this.) |
Access to vCard stream |
Yes |
No |
Working with tasks |
No |
Yes (EWS does not expose task request functionality.) |
Synchronization |
No |
Yes |
Notifications |
No |
Yes |
Folder permissions |
No |
Yes |
Delegate management |
No |
Yes |
Task items |
No |
Yes |
Search folder creation |
No |
Yes |
Managed Folder support |
No |
Yes |
Free/busy support |
No |
Yes |
Server-to-server impersonation |
No |
Yes |
CDOEX provides Outlook-compatible business logic. CDOEX also uses ExOLEDB for Exchange database access. However, the greater client flexibility and the fact that CDOEX will not be available in future versions of Microsoft Exchange make EWS the best choice for CDOEX-based Exchange applications.
Exchange Web Services/Transport Agents vs. ExOLEDB/Store Event Sinks
ExOLEDB can be used to access the mailbox database on a local Exchange server. ExOLEDB is an OLE Database provider that is used by the COM components CDOEX and Exchange store event sinks. CDOEX uses ExOLEDB to search the Exchange database. COM components use ExOLEDB to register Exchange store event sinks to monitor store events. ExOLEDB calls the COM component when a subscribed store event occurs. ExOLEDB cannot be used on front end servers.
Exchange Web Services and transport agents in Exchange 2007 replace ExOLEDB and Exchange store event sinks. In Exchange 2007, store event sink functionality is partly provided by routing agents, which are a type of transport agent, and partly covered by EWS notifications. EWS notifications expose events that occur on individual mailboxes. EWS does not provide a simple store-wide notification subscription. To provide subscription coverage similar to store-wide event sinks, you must subscribe to EWS notifications on all mailboxes by using either delegate access or Exchange impersonation.
A direct match does not exist between store-wide store event sinks and new functionality offered by EWS and routing agents. Fortunately, routing agents can act on all mail that flows through them. Therefore routing agents can provide similar functionality to store event sinks although it is from a different point in the architecture. EWS and transport agents simplify programming against store events because they are based on the .NET Framework.
The following table provides a comparison of the functionality that is available in ExOLEDB versus Exchange Web Services/transport agents.
Comparison between ExOLEDB and Exchange Web Services/transport agents
| Functionality | ExOLEDB (store event sinks and CDOEX) | Exchange Web Services/transport agents |
|---|---|---|
Mailbox event notifications |
Yes |
Yes (EWS) |
Search |
Yes |
Yes |
Item/folder retrieval |
Yes |
Yes |
Item/folder manipulation |
Yes |
Yes |
Store-wide event subscription notifications |
Yes |
Yes (EWS can provide store-wide subscription notifications by using delegate access or Exchange impersonation to subscribe to events in all mailboxes in a store database. Transport agents can be registered for an organization.) |
Get all properties as defined in the store schema |
Yes |
No |
Transactions |
Yes |
No (Poorly designed transactions can affect server performance; therefore transaction support was not continued. EWS uses change keys to ensure that actions are taken on the most recent version of an item.) |
Access MIME content |
No |
Yes (routing agents) |
Synchronization |
No |
Yes (EWS) |
DL expansion |
No |
Yes (EWS) |
Search folder creation |
No |
Yes (EWS) |
Outlook-compatible business logic |
No |
Yes (EWS) |
Managed Folder support |
No |
Yes (EWS) |
Free/busy support |
No |
Yes (EWS) |
Server-to-server impersonation |
No |
Yes (EWS) |
Remote clients |
No |
Yes (EWS) |
Store event sinks require administrator approval to run on the Mailbox server. They also expose both synchronous and asynchronous events. Store event sinks can run either in-process or out-of-process. Incorrectly implemented store event sinks can drastically affect Exchange mailbox database performance and reliability.
EWS notifications avoid some of the shortcomings of store event sinks. EWS notification clients can run on the server or on a remote computer. The administrator does not have to register the client. EWS event notifications occur asynchronously, run out-of-process, and cannot lock resources.
Transport Agents vs. SMTP Event Sinks
Transport agents, in addition to EWS notifications, replace much of the functionality that is provided by Exchange store event sinks and SMTP event sinks. Two types of transport agents are available: routing agents and SMTP receive agents. SMTP receive agents provide a subset of SMTP event sink functionality.
The following table compares the functionality that is available in the two types of transport agents and SMTP event sinks.
Routing agent and SMTP receive agent functionality versus SMTP event sink functionality
| Functionality | Routing agents | SMTP receive agents | SMTP Event Sinks |
|---|---|---|---|
Getting server information. |
Yes |
Yes |
Yes |
Determining whether the address book contains a given address. |
Yes |
Yes |
Yes |
Finding address book entries for SMTP addresses or recipients. |
Yes |
Yes |
Yes |
Determining whether a given recipient belongs to a particular group. |
Yes |
Yes |
Yes |
Determining whether two given addresses refer to same Recipient. |
Yes |
Yes |
Yes |
Finding Microsoft.Exchange.Data.Transport.SmtpServer.AcceptedDomains for the current server. |
Yes |
Yes |
Yes |
Submitting a new e-mail message. |
Yes |
Yes |
Yes |
Adding restrictions in the IPPermission list. |
Yes |
Yes |
Yes |
Accessing P1 sender/recipients. |
Yes |
Yes |
Yes |
Accessing MIME messages. |
Yes |
No |
No |
Deferring messages. |
Yes |
No |
No |
Deleting messages. |
Yes |
No |
No |
Forking messages. |
Yes |
No |
No |
Expanding recipients. |
Yes |
No |
No |
Applying routing override to certain recipients. |
Yes |
No |
No |
Accessing MIME message after Microsoft.Exchange.Data.Mime.MimeDocument.EndOfHeaders. |
No |
Yes |
Yes |
Checking SMTP connection status. |
No |
Yes |
Yes |
Rejecting commands. |
No |
Yes |
Yes |
Rejecting messages. |
No |
Yes |
Yes |
New SMTP Verbs. |
Not applicable. |
No |
Yes |
Migrating from CDOEXM and WMI
CDO for Exchange Management (CDOEXM) and Windows Management Instrumentation (WMI) are not available in Exchange 2007. Use the Exchange Management Shell to programmatically manage Exchange 2007.
Exchange 2007 Legacy API Property Mapping
The Exchange 2007 Legacy API Property Mapping spreadsheet contains preliminary information about the mapping of WebDAV/CDOEX properties to EWS properties. This information can be useful for planning your migration to Exchange Web Services.
The following table describes the content of each worksheet in the Exchange 2007 Legacy API Property Mapping spreadsheet.
Exchange 2007 legacy API mapping spreadsheet
| Worksheet | Description |
|---|---|
CDOEX Overview |
Describes the CDEOX COM classes and interfaces. |
CDOEX Interfaces |
Describes the CDOEX interfaces and the corresponding EWS properties. |
Store Schema |
Describes store schema properties and the corresponding EWS properties. |
DAV Schema |
Describes the DAV schema. |
DAV Methods |
Describes the Exchange WebDAV methods and the corresponding EWS methods. |
DAV XML Elements |
Describes Exchange WebDAV XML elements and corresponding EWS support. |
DAV Headers |
Describes the Exchange WebDAV headers. |
Moving Forward
You should now have a better understanding of the Exchange 2007 technologies that are intended to replace WebDAV, CDOEX, event sinks, ExOLEDB, CDOEXM, and WMI functionality. The functional gaps between the legacy APIs and the new Exchange 2007 technologies will narrow while the API functionality will continue to expand in future versions of Microsoft Exchange. Exchange Web Services, transport agents, and the Exchange Management Shell will provide a better programmability experience because they are built on the .NET Framework.
For more information about the programmability features that are currently planned for the next version of Microsoft Exchange, see the Exchange Developer Roadmap blog post.
Note
Information about functionality that will be available in future versions of Microsoft Exchange is preliminary and subject to change.
Look for future articles that provide detailed information about common migration scenarios that help illustrate the process of moving to the new Exchange 2007 technologies.