Topic Last Modified: 2005-05-23
In Exchange Server 2003, all Internet-based client access protocols run as part of IIS. When you install Exchange Server 2003, it extends, rather than replaces, the SMTP and NNTP protocol stacks in IIS, using additional command verbs and advanced routing components. The Exchange Server 2003 Internet protocol stacks are as follows:
- POP3 POP3 is the most basic message retrieval protocol. POP3 can access only the user's Inbox folder. Exchange 2003 supports POP3 for access by POP3 clients.
- IMAP4 IMAP4 is used to access mailbox information. IMAP4 is more advanced than POP3, because it supports basic online capabilities and access to folders in addition to the Inbox. In addition to providing limited access to user mailboxes, the Exchange 2003 implementation of IMAP4 provides the following:
Access to public folders
Delegate access to another user's mailbox
Anonymous access to specific IMAP account names
- Access to public folders
- SMTP SMTP is the primary messaging protocol for Exchange Server 2003. SMTP is used to move messages between servers in the same routing group and is the preferred protocol for moving messages between routing groups. The enhancements made by Exchange Server 2003 to the IIS SMTP stack include:
Commands that support fault-tolerant routing
An advanced queuing engine
An enhanced message categorization agent
- Commands that support fault-tolerant routing
- NNTP The Exchange Server 2003 implementation of NNTP adds the following functionality to NNTP:
Content indexing provides search functionality to public folders
Full newsfeed acceptance, regardless of storage choice (file system or public folders) on the back end
MAPI or NNTP clients can read or post to newsgroups supported by the Microsoft Exchange Information Store service
- Content indexing provides search functionality to public folders
- WebDAV WebDAV is an extension to HTTP that provides a Web interface to the Microsoft Exchange Information Store service.
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.
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.
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.
|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.
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.