Part 1 : Developer Roadmap – Development Technologies for Exchange Server 2010

This two part article is targeted for the developer audience, if you’re the developer who want to create a develop custom application for Exchange Server 2010 or already has custom application designed for previous versions of Exchange Server 2010.

Some Exchange programming technologies that are available in versions of Exchange earlier than Microsoft Exchange Server 2010 are obsolete and have been replaced with other technologies. Per MSDN article, the programming technologies and APIs stated below have either been removed from Exchange 2010 or earlier versions of Exchange, are no longer supported for use with the current version of Exchange, or are no longer the recommended API to use to access Exchange.

• Active Directory Services Interface still exists, but we do not recommend that you access Exchange data in Active Directory Domain Services (AD DS) by using ADSI.

Recommendation: We recommend that you use Exchange PowerShell commands to administer Exchange configuration data.

• Collaboration Data Objects for Exchange (CDOEX) is not included in Exchange 2010.

Recommendation: We recommend that you migrate your applications that use CDOEX to Exchange Web Services.

• Collaboration Data Objects for Exchange Management (CDOEXM) is not included in Exchange 2007 or Exchange 2010.

Recommendation: We recommend that you migrate your applications that use CDOEXM to use Exchange PowerShell commands.

• Collaboration Data Objects for Exchange Workflow (CDOWF) is not included in Exchange 2007 or Exchange 2010.

Recommendation: We recommend that you migrate your applications that use CDOWF to use Windows Workflow Foundation Services.

• Collaboration Data Objects for Windows 2000 (CDOSYS) is included in current versions of Windows. The functionality in CDOSYS is now available in the Microsoft .NET Framework.
• Collaboration Data Objects for Windows (CDOSYS) SMTP/NNTP Event Sinks are included in current versions of Windows.

Recommendation: Notification-based applications that work with Exchange 2010 should use transport agents.

• Collaboration Data Objects (CDO) version 1.2.1 is available for download for applications that continue to require it. CDO 1.2.1 is a de-emphasized API, and support is only available under an Extended Support agreement.

Recommendation: We recommend that you migrate any CDO 1.2.1 applications to use Exchange Web Services.

• Exchange Incremental Change Synchronization (ICS) is a MAPI-based interface, and is still supported against Exchange 2010.

Recommendation: To ensure continued future compatibility, we recommend that you consider migrating your ICS applications to use Exchange Web Services notifications.

• Exchange OLE Database Provider (ExOLEDB) is not included in Exchange 2007 or Exchange 2010.

Recommendation: We recommend that you migrate applications that use ExOLEDB to use Exchange Web Services.

• Exchange Rules DLL is part of the sample code that shipped with the Exchange 5.5 and Exchange 2000 SDKs.

Recommendation: We recommend that you migrate applications that use the Exchange Rules DLL to use either MAPI or Exchange Web Services notifications.

• Exchange Store Event Sinks are not available in Exchange 2010.

Recommendation: Where possible, we recommend that applications that use Exchange Store Event sinks be migrated to use either transport agents or Exchange Web Services notifications.

• Exchange Streaming Backup and Restore API is not included in Exchange 2010.

Recommendation: We recommend that you migrate backup and restore applications that use streaming backup to use the Windows Volume Shadow Copy Service (VSS).

• Exchange WebDAV is not included in Exchange 2010.

Recommendation: We recommend that you migrate applications that use Exchange WebDAV to use the Exchange Web Services.

• Exchange WebDAV Notifications are not included in Exchange 2010.

Recommendation: We recommend that you migrate applications that use Exchange WebDAV notifications to use Exchange Web Services notifications.

• Exchange Web Forms is not included in Exchange 2007 or Exchange 2010.

Recommendation: We recommend that you migrate applications that use Exchange Web Forms to use either Windows SharePoint Services, or Active Server Pages.

• Lightweight Directory Access Protocol (LDAP) still exists, but accessing Exchange data in AD DS by using LDAP is not recommended.

Recommendation: We recommend that you use Exchange PowerShell commands to administer Exchange configuration data.

• Windows Management Instrumentation (WMI) Providers are not included in Exchange 2007 or Exchange 2010.

Recommendation: We recommend that you migrate applications that used WMI to use the Exchange PowerShell commands.

Happy Programming!!

CDONTS, CDOSYS, System.Web.Mail & System.Net.Mail

Microsoft Windows Server 2003 does not install Collaboration Data Objects (CDO) for NTS (CDONTS). Therefore, applications that use CDONTS do not function on a Windows Server 2003-based computer.

Windows Server 2003 provides improved alternatives to CDONTS. To make applications that use CDONTS function on a Windows Server 2003-based computer, update existing CDONTS applications to use one of the following technologies:

• CDO for Windows 2000
  CDO for Windows 2000 provides a broader functionality set than CDONTS. This functionality includes the ability to send messages through a remote Simple Mail Transfer Protocol (SMTP) server. You can use CDO for Windows 2000 (CDOSYS) in applications that are not Microsoft .NET Framework-based.
  
  For example, Microsoft Visual Basic 6.0 and Microsoft ASP are not based in the .NET Framework. You can also use CDOSYS in .NET Framework applications.
  
• System.Web.Mail
  The System.Web.Mail namespace provides a managed wrapper for CDOSYS. The System.Web.Mail namespace is only available in .NET Framework applications.
• System.Net.Mail
  When we talk about .Net framework, we can use the System.Net.Mail namespace. It provides way to send electronic mail to a Simple Mail Transfer Protocol (SMTP) server for delivery.

FYI: System.Net.Mail Vs System.Web.Mail

In .NET 1.1, only the System.Web.Mail was available. This implementation needs to be done in quite different way. For example, attachment could only be added from files, not from Streams. So, this can be still used under .Net Framework 1.0 and 1.1, but going forward it’s “deprecated” or “Obsolete”; so it’s recommended that to make use of System.Net.Mail.

The .NET 2.0 implementation is System.Net.Mail and is much more flexible and has a richer feature set.

Test and troubleshooting tools for various Exchange technologies

I tried to compose the test and troubleshooting tools for various exchange technologies. This initial list upto Exchange Server 2003. 

 

Technology	Tools for test and troubleshooting tools
Active Directory Services Interfaces (ADSI)	All standard test and debugging tools, as well as other Microsoft and third-party test and debugging tools, can be used.
Collaboration Data Objects for Windows 2000 (CDOSYS)	No special debugging tools are needed to debug applications that use CDOSYS.
CDOSYS SMTP/NNTP Event Sinks	No special debugging tools are needed to debug applications that use CDOSYS. For particularly difficult protocol-interaction issues, a network monitoring utility may prove helpful, but is typically not required.
Collaboration Data Objects for Exchange 2000 Server (CDOEX)	No special debugging tools are needed to debug applications that use CDOEX.
Collaboration Data Objects for Exchange Management (CDOEXM)	No special debugging tools are needed to debug applications that use CDOEXM.
Collaboration Data Objects for Exchange Workflow (CDOWF)	No special debugging tools are needed to debug applications that use CDOWF. Custom applications might be created to analyze the process audit logs created during process execution. If you are using the Workflow Designer for Exchange 2000 Server, enable Just-In-Time (JIT) script debugging. JIT starts the Microsoft Script Debugger when the error occurs. The debugger starts on the server, so you need to have access to the server.
Exchange OLE DB Provider (ExOLEDB)	No special debugging tools are needed to debug applications that use ExOLEDB.
Exchange Store Event Sinks	No special debugging tools are needed to debug applications that use Exchange store event sinks.
Exchange Web Forms	No special debugging tools are needed to debug applications that use Exchange Web forms. Note, however, that because the forms execute on the computer running Microsoft Exchange Server 2003, debugging may require the developer have access to the Exchange server. Always use caution when allowing anyone direct access to the Exchange server.
HTTP/Web Distributed Authoring and Versioning (WebDAV)	No special debugging tools are required to debug applications that use WebDAV. For particularly difficult protocol-interaction issues, a network monitoring tool may prove helpful. The NETMON.EXE tool can be very useful in debugging WebDAV protocol interactions. Because WebDAV queries are sometimes sensitive to minor syntactical differences, a WebDAV query tool can also be helpful.
WebDAV Notifications	No special debugging tools are needed to debug applications that use WebDAV Notifications. For particularly difficult protocol-interaction issues, a network monitoring tool may prove helpful, but is typically not required.
Incremental Change Synchronization (ICS)	No special debugging tools are needed to debug applications that use ICS.
Lightweight Directory Access Protocol (LDAP)	No special debugging tools are needed to debug applications that use LDAP. For particularly difficult protocol-interaction issues, a network monitoring tool may prove helpful, but is typically not required.
Messaging Application Programming Interface (MAPI)	No special debugging tools are needed to debug applications that use MAPI.
Outlook Object Model (OOM)	No special debugging tools are needed to use OOM.
Outlook Web Access	No tools are available for debugging calls to Microsoft Outlook® Web Access, because the internal architecture is not available for debugging, and the URL calls required to access Outlook Web Access programmatically are not documented or supported.
Exchange Rules	No special debugging tools are needed to debug applications that use Exchange rules. Client-side rules require Outlook for proper testing.
SMTP Event Sinks	No special debugging tools are needed to debug applications that use SMTP event sinks. For particularly difficult protocol-interaction issues, a network monitoring tool may prove helpful, but is typically not required.
Windows Management Instrumentation providers for Exchange (WMI)	No special tools are required to debug applications that use WMI.
Exchange Backup & Restore API	No special tools are required to debug applications that use the Exchange Backup and Restore API.
Exchange writer for the Windows Volume Shadow Copy Service	No special tools are required to debug applications that use the Windows Volume Shadow Copy Service.

KB : Where to get the CDO libraries for all the versions?

As you know that the Collaboration Data Objects (all versions) Libraries are used to implement Messaging and Collaboration functionality into a custom application.

Please find this article contains information on where these libraries can be found. http://support.microsoft.com/kb/171440

MAPI : Do you know why MAPI is not suitable for HTML messages?

Do you know why MAPI is not suitable for HTML messages?

 

MAPI 1.0 was written before HTML mail was developed and does not reliably support the creation of HTML-formatted messages. As you know, MAPI 1.0 is the version supported by all versions of Microsoft Exchange through version 5.5 (and all Service Packs). This includes the following subordinate technologies:

•Simple MAPI
•Extended MAPI
•OLE Messaging
•Active Messaging (Collaboration Data Objects (CDO) 1.1)
•CDO versions 1.2 and 1.21
•MAPI controls (Msmapi32.ocx)

Extended Messaging Application Programming Interface (MAPI) should not be used to generate HTML-formatted messages.

What is needed?

If messages are needed in HTML format, such as for sending text formatted in other languages, alternative technologies that provide more reliable support for HTML messages are recommended:

•CDONTS
•CDO for Windows 2000 (CDOSYS)
•CDO for Exchange 2000 (CDOEX)
•Outlook Object Model of Microsoft Outlook 98 or later
•SMTP-capable ActiveX controls obtained from third-party vendors

In short, as an alternative, we should consider using the Microsoft Outlook Object Model, CDONTS, CDOSYS, CDOEX, or a third-party SMTP control.

Exchange Server – Technologies – FAQ

Exchange Server – Frequently Asked Questions 

When we do Exchange programming with client and server versions of the Exchange Server Providers, MAPI32, EMSMDB, EMSABP and MSPST32 almost or always causes confusion. In this article, we’ll discuss about the common terminologies: 

What is MAPI? 

MAPI will generally mean MAPI32.dll, or the APIs contained. It’s an API, implemented largely in MAPI32.dll (Messaging Application Programming Interface, 32 bit build). By using this, developers implement a series of Providers. Providers come in three major types, Transport Providers, Message Store Providers, and Address Book Providers. Providers are DLLs that implement a specific pseudo COM API, such as IMessageStore, and the underlying required interfaces, such as IMAPIProp.

Then, what is a MAPI Application?
It means any application that uses the MAPI calls. MAPI applications work against sets of data sources grouped into Profiles. Profiles are created, saved, and deleted by the Profile Provider. The Profile Provider is implemented in MAPI32.dll in two forms:

• The temporary profile provider, which stores profile data in temp files.
  
• The normal profile provider, which stores profile data in the registry.

An empty profile gives a MAPI application no data access, so MAPI applications add Providers (also called Services) to the profile. A common thing for MAPI applications to do is add services for EMSMDB and EMSABP to a profile, granting the ability to access data from Exchange Server. Providers do all of the actual work in MAPI. When you submit a message, although the call might pass through MAPI32, it is EMSMDB (or your provider) that does the actual work for sending. When saving a message, it is not MAPI32 that saved the message; it’s the message store provider (usually EMSMDB for Exchange Server). When you resolve a recipient, it is not MAPI32 that searches for the user in the address book. It is the Address Book Provider, implementing the IAddrBook interface (probably EMSABP). 

What do you meant by CDO or Colloboration Data Objects?  Does CDONTS, CDOSRV, CDOSYS, CDOEX, EXCDO, or CDOEXM all are same jargons?

Collaboration Data Objects (CDO) refers to CDO.DLL, not CDONTS, CDOSRV, CDOSYS, CDOEX, EXCDO, or CDOEXM. CDO and Outlook are both MAPI applications, meaning that they use MAPI APIs to access their data and, therefore, the underlying providers. CDO and Outlook share a common set of Properties that, when taken together, define different classes of messages and different functionality. This works similar to the schema in a database; however, MAPI32 does not implement the storage. The Message Store Provider does. In the case of Exchange Server, this provider is EMSMDB, and Exchange Server is mostly agnostic about the semantics of the data that applications choose to store. Exchange Server 5.5 has almost no knowledge of individual named property meanings. Exchange 2000 Server and Exchange Server 2003 are considerably more aware of the significance of particular named properties on different message classes, in particular, calendar items. This logic is implemented in EXOLEDB and EXCDO. In general, it is up to users of a particular set of properties to agree on what those properties mean and how they are manipulated.

CDO implements an API to manipulate sets of properties together to accomplish tasks, such as scheduling a meeting. Outlook also implements APIs to manipulate sets of properties, and does presentation of that data to the end user. If CDO and Outlook don’t agree on what particular properties mean, or on the mechanisms used to control processing logic (for instance, when an appointment has been updated), potential for problems interoperating between Outlook and CDO exist. Although Outlook continues to be updated and expanded with every version, CDO.dll is more or less static at the same level of functionality it has possessed for years. Newer libraries for manipulating calendar data, such as CDOEX, are considerably more up to date.

What do you meant by EMSMDB or EMSMDB32 or Exchange Transport Provider? 

EMSMDB refers to the Exchange transport provider, EMSMDB32. One example of a provider is EMSMDB2, the “Electronic Messaging System Microsoft Data Base, 32 bit build” provider. EMSMDB implements both a transport and a message store and, as such, is a dual provider.
The transport is the ability to submit messages to Exchange Server; the message store is the ability to read (and possible write) messages to an Exchange store process.

What do you meant by EMSABP or EMSABP32 or Exchange Address Book provider? 

EMSABP refers to the Exchange address book provider, EMSABP32. The other common provider involved with Exchange Server is EMSABP, which is an Address Book Provider (Electronic Messaging System Address Book Provider, 32 bit build). EMSABP implements IAddrBook and allows access to the Exchange global address list through Name Service Provider Interface (NSPI).