Share via


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

E-mail

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

E-mail

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.