Except for MAPI, Exchange Server 2003 client access protocols are not part of the Microsoft Exchange Information Store service. Rather, they are hosted by IIS. Separating these protocols from the Microsoft Exchange Information Store service increases the reliability, flexibility, and scalability of Exchange Server 2003. However, the protocols must be able to transfer data rapidly between IIS and the Microsoft Exchange Information Store service. To make the rapid transfer of data easier, Exchange Server 2003 contains a queuing layer named the Exchange Interprocess Communication (ExIPC) layer, also referred to as EPOXY, because it is implemented in Epoxy.dll.

As illustrated in the following figure, ExIPC works in tandem with Exchange Installable File System (ExIFS) to move messages between IIS and Exchange Server 2003.

ExIPC offers high-performance interprocess communication functionality. Like lightweight remote procedure calls (LRPCs), ExIPC uses shared memory (32 kilobyte mapped memory sections), built on the Shared Memory Circular Queue (SMQ) model, to communicate between the INETINFO and STORE processes, and the DSAccess cache. This ensures that the cache is available to all processes that run DSAccess. ExIPC includes the Microsoft Exchange Information Store service and a protocol DLL that provides a binding facility (fast reliable communication between IIS and the Microsoft Exchange Information Store service), a shared memory heap, and a pair of queues based on shared memory.

Exchange Server 2003 storage and protocol architecture

ExIPC works in tandem with Exchange Installable File System (ExIFS) to move messages between IIS and Exchange. ExIFS provides access to the Microsoft Exchange Information Store service through Microsoft Win32 file system APIs. ExIFS makes the streaming file appear to IIS as many smaller files named virtual files. IIS obtains a handle to a virtual file and writes incoming data directly to the stream file through ExIFS. Similarly, outgoing messages are read directly from the stream file through ExIFS. A message becomes a list of pages (with the page numbers held in the .edb file) in the streaming file, and any needed properties are promoted from the .stm file to the .edb file.

ExIFS architecture

A message then becomes a list of pages (with the page numbers held in the .edb file) in the streaming file. Any required properties are promoted from the .stm file to the .edb file.

This figure illustrates file streaming between IIS and ExIFS. ExIFS represents streaming files to IIS as smaller virtual files. Data, such as checksum data and promotion of properties data, moves first from ExIFS to Extensible Storage Engine, and then to the Exchange information store. IIS and the Exchange information store also exchange information, such as the page numbers on which ExIFS placed a message, so that the page numbers are recorded and stored on the record representing the message in the Exchange information store.

When a message enters the system, IIS creates a new file in ExIFS. The data is written to the new file on reserved pages. ExIFS then returns the list of pages to the Exchange store. The Exchange information store processes the pages and stores them in a record representing the message. Extensible Storage Engine then commits the data on the reserved pages by logging the information to the storage group's transaction log files. At this point the pages change from a reserved state to a committed state.

Note:

If the storage group has circular logging turned on, Extensible Storage Engine does not write data that comes in through the streaming file data to the transaction log files. In this instance, streaming file data is first placed in the streaming file. The data is only required in the transaction logs for recovery and log roll forward after a restore. Because log roll forward can only occur when circular logging is turned off, the streaming file data is only useful in the transaction logs when circular logging is turned off.

When a message is retrieved from the system, the Exchange store process receives the list of pages referenced by the message. This list of pages is passed to IIS. IIS then opens a file in ExIFS using the list of pages. The message is quickly streamed out of the Exchange information store, without conversion.

ExIFS reflects Win32 file calls to the Exchange store. Therefore, you can use the Win32 filesystem API to access data in Exchange Server. For example, calls such as FindFileFirst can access a public folder for a list of messages. Additionally, you can map a drive to your own mailbox and use the conventional command line functions to access your Inbox. ExIFS displays the contents of an Exchange database as ordinary files.

ExIFS interaction with Microsoft Windows Explorer and the Exchange store

This figure illustrates that the interaction with the store achieved through ExWin32.dll. ExIFS.sys also supports all the file system-related functions that are exported from kernel32.dll, in addition to the interaction with the Exchange store achieved through ExWin32.dll.

The ExIPC binding facility enables the creation and connection of an arbitrary number of queues between two processes such as INETINFO and STORE. This binding facility includes Central Queue Manager for keeping track of the queues and processes with which a particular process communicates. This facility is used for unbinding and queue clean-up if a failure on the other process occurs.

Each protocol queue is circular and fixed in size. During interprocess communications, data is stored in the shared memory heap and referenced by a data handle. The data handle is enqueued and dequeued. The IIS or the Exchange store then references a part of shared memory from the handle.

Each protocol has an ExIPC interface in STORE.exe. For example, the ExIPC protocol stub for POP3 is expop.dll. This component passes parameters (for example, a pointer to a message or an action) from STORE.exe to the ExIPC interface (drviis.dll) in INETINFO.exe.