Exchange Server - Technologies - FAQ

  • Article

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).