Introduction

Microsoft made a radical departure from the Exchange 5.5 architecture when they designed Exchange 2000. The first obvious difference to most experienced Exchange administrators was the removal of the Exchange-specific directory service in favor of Active Directory, which is provided by the underlying Windows operating system. Microsoft also switched the native transport from X.400 to SMTP. To implement this change, they followed the pattern of using components already provided by the operating system.

Windows 2000 and 2003 include Internet Information Services (IIS), a modular framework that provides support for many Internet protocols including HTTP, NNTP, and SMTP. Exchange makes use of the IIS framework by extending the SMTP service with additional capabilities not present in the base IIS installation. Many advanced aspects of the Exchange system are controlled through the various IIS management mechanisms such as the IIS Management MMC plug-in and the IIS metabase. It is important to understand how the reuse of the IIS architecture affects the design and function of Exchange.

In Exchange 5.5, the SMTP implementation was provided by the Internet Mail Service, an add-on component that performed all the necessary translations between the internal Exchange message transport (based on the X.400 protocol) and SMTP. This translation was imperfect, given the differences between the two protocols. Each IMS instance functioned as a separate connector; they did not share common information between them. In Exchange 2000, the Active Directory schema permits the storage of both SMTP and X.400 attributes, so all components of Exchange now understand both X.400 and SMTP. No translation is necessary within the organization.

Exchange 2000 and Exchange Server 2003 build upon the virtual server model provided by the IIS SMTP service. Each physical server has at least one SMTP virtual server instance which provides the core capabilities for SMTP transport. By itself, the SMTP virtual server is a limited Extended SMTP implementation that provides the majority of the functionality required by both intra-organization and external SMTP sessions. On multiple-homed servers, SMTP virtual server instances can be bound to listen only to specific interfaces, providing the ability to partition traffic by network.

Exchange SMTP virtual servers have another benefit: they expose an interface for custom functionality. Developers can create custom message-handling code and register it as an event sink with one or more virtual servers; these event sinks will be activated by Exchange and have access to incoming or outgoing messages. This is the same mechanism used to supply the extended Exchange SMTP functionality; Microsoft-provided event sinks extend and, in some cases, replace the underlying IIS SMTP code. Custom event sinks can be used for many purposes; one common one is to append a specific disclaimer on every outgoing message. Since each collection of registered event sinks is unique to a specified virtual server, strategic creation of additional SMTP virtual server instances gives you control over application of your event sinks in ways that might be extremely difficult or even impossible with your code.

Exchange 2000 still contains a native X.400 Message Transfer Agent (MTA) component, which handles any X.400 connections, as well as native RPC connections to Exchange 5.5 sites. The MTA is not used for normal message traffic between Exchange 2000 and Exchange Server 2003 servers; it is only used for messages that traverse X.400 connectors, are sent to Exchange 5.5 servers in the administrative group, or are sent over non-SMTP connectors such as the Novell Groupwise and Lotus Notes connectors. Messages are not directly moved between the SMTP transport and MTA; they are first tagged with the appropriate message properties and handed to the Exchange information store, which then determines whether to deliver the message to a local recipient or pass it to the appropriate transport. To provide efficient traffic control on busy systems, each Exchange transport component, as well as the Exchange store, creates multiple queues. These queues are used by the categorizer to transfer messages between components of the Exchange system.

By default, each SMTP virtual server creates a combination of static system queues as well as destination-dependent transient queues known as link queues. Each system and link queue is located in a separate directory. Queue directories are initially located underneath the <ExchangeRoot>\Mailroot\<VirtualServer>\Queue directory; <ExchangeRoot> is the directory Exchange was installed into, normally C:\Program Files\Exchsrvr, while <VirtualServer> is the directory specific to the SMTP virtual server instance; the default SMTP virtual server is usually vsi 1. There are a few specific notable SMTP system queues that vary between Exchange 2000 and Exchange Server 2003. The Exchange Advanced Queuing Engine component is responsible for maintaining message flow between the various system and link queues. It also provides detailed status information for each queue, allowing you to monitor and track the flow of messages through the SMTP system by using the Exchange System Manager. These queues are detailed further in Recipes Recipe 7.12 through Recipe 7.15.

Although the X.400 and foreign message system connectors use the MTA transport, there are two connectors that use the SMTP transport: the SMTP connector and the Routing Group Connector (RGC). The SMTP connector provides advanced SMTP functionality such as precise control over the SMTP namespace, SMTP authentication, and both client and server support for SMTP message retrieval using the ATRN, ETRN, and TURN methods. The RGC is used to connect the various routing groups within the Exchange organization and provide a seamless, low-maintenance method of controlling message traffic where required, such as over low-bandwidth links between routing groups or where security concerns dictate. SMTP connectors must be associated with specific SMTP virtual server instances and may override their configuration, while RGCs are associated with every SMTP virtual server in the routing group that has been specified as a bridgehead server for the connector. You can find more information about routing groups in Recipes Recipe 7.7 through Recipe 7.10 and about the RGC and SMTP connectors in Recipes Recipe 7.17 through Recipe 7.19.

Microsoft provides additional detailed technical reference material for the Exchange transport and routing architecture:

• Microsoft has provided the contents of Chapter 8, "Information Flow and Routing," of the Microsoft Press book Introducing Microsoft® Exchange 2000, available from the Microsoft TechNet web site at http://www.microsoft.com/technet/prodtechnol/exchange/2000/deploy/exinfflo.mspx.

• The Exchange Server 2003 Technical Reference Guide provides a thorough look at the design of the entire Exchange Server 2003 system. In particular, Chapter 5 ("Message Routing Architecture"), Chapter 6 ("SMTP Transport Architecture"), and Chapter 7 ("X.400 Transport Architecture") discuss the core message routing and transport components, but the entire guide is recommended reading. Although geared for Exchange Server 2003, much of this information still applies to Exchange 2000. This guide is available from the Microsoft TechNet web site at http://www.microsoft.com/technet/prodtechnol/Exchange/guides/E2k3TechRef/4c8062cb-f07d-463b-a297-00614095ca24.mspx.