Export (0) Print
Expand All
This topic has not yet been rated - Rate this topic

Planning for Internal and Third-Party Applications

Topic Last Modified: 2009-12-09

Microsoft Exchange Server 2010 introduces many changes to the set of Application Programming Interfaces (APIs) that are available for application development. Upgrading your Exchange servers to Exchange 2010 can affect both internal applications and third-party applications that may use the Exchange APIs over the network or on your Exchange server. Use the sections in this topic to review potential effects on your internal or third-party applications that interact with Exchange 2010.

Ee861107.important(en-us,EXCHG.140).gifImportant:
We recommend that you contact third-party software vendors to confirm that the products you use are supported for use with Exchange 2010.

Use this topic as a guide to help you investigate whether your Exchange Server applications will be affected by an upgrade to Exchange 2010.

Exchange 2010 supports fewer APIs than previous versions of Exchange Server support. For a list of Exchange 2010 APIs, see Development Technologies for Exchange 2010 on MSDN.

Earlier versions of Exchange Server contain APIs that have been removed from Exchange 2010. For a list of APIs that are available in earlier versions of Exchange, see the following topics on MSDN:

The following table identifies the development technologies that are available for use with Exchange 2010.

Development Technology Exchange 2003 Exchange 2007 Exchange 2010

Exchange Web Services

X

X

Exchange Web Services Managed API (available as a separate download.)

X

X

Messaging Application Programming Interface (MAPI)

X

X

X

Outlook Object Model (OOM) (available as a separate download.)

X

X

X

Outlook web application

X

X

X

Outlook web application customization

X

X

Transport Agents

X

X

The following table lists the development technologies that are not available in Exchange 2010, and the product versions that they are available in.

Development Technology Exchange 2003 Exchange 2007

Active Directory Services Interface (ADSI)

X

X

Collaboration Data Objects for Windows 2000 (CDOSYS)

X

X

CDOSYS SMTP/NNTP Event Sinks

X

X

Collaboration Data Objects for Exchange (CDOEX)

X

X

CDOEXM

X

CDOWF

X

Exchange Backup and Restore API

X

X

Exchange Writer for the Windows Volume Shadow Copy Service

X

X

Exchange OLE DB Provider

X

X

Exchange Store Event Sinks

X

X

Incremental Change Synchronization (ICS)

X

X

Lightweight Directory Access Protocol (LDAP)

X

X

SMTP Event Sinks

X

X

Web Forms

X

X

WebDAV

X

X

WebDAV Notifications

X

X

Windows Management Instrumentation (WMI)

X

For information about migration your applications to Exchange 2010 technologies, see Migrating from Exchange 2000, Exchange 2003, and Exchange 2007 APIs on MSDN.

Exchange Web Services does not allow delegation of mailbox access across versions. If either the principal's or the delegate's mailbox is on an Exchange server that is running a different version of Exchange, delegate access attempts will not succeed.

Cross-site proxying to a site that has an external URL set for an Exchange server that is running the Client Access server role is only allowed for the delegate access scenario where the source and destination mailboxes are in different Active Directory sites or when accessing public folders. The preferred method is to use Autodiscover to get the correct Client Access server URL to directly access a mailbox instead of using the cross-site Client Access server to Client Access server proxy feature. For more information about Client Access server proxying, see Understanding Proxying and Redirection.

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft. All rights reserved.