Chapter 02: Microsoft Exchange Architecture

Overview

An architecture is the structure of something. When applied to a software product, an architecture is a description of the software components of the product, what they are, what they do, and how they relate to each other. In Exchange, examples of these components are the Information Store service that manages the databases of messages on a server and the System Attendant service that performs routine maintenance on a server. Part of what software components do is create and manage objects (i.e., resources) such as servers, mailboxes, public folders, and address books. How those objects are structured or organized is also part of software architecture.

There are many practical benefits to understanding the architecture of Microsoft Exchange. Such knowledge will aid a person in designing, installing, administering, and troubleshooting an Exchange system. For example, understanding component functionality will assist you in deciding what optional components, if any, to choose during an installation. Troubleshooting can frequently benefit from a good understanding of architecture; just understanding some error messages requires such knowledge. This chapter provides you with a good conceptual background of the topics covered in the remainder of the book.

In this chapter, we will address the following issues:

• The Windows Server 2003 Active Directory and its integration with Exchange Server 2003

• Information storage on an Exchange server

• Message flow in the Exchange environment

Active Directory in Windows Server 2003

To understand Active Directory, it is first necessary to understand what a directory is. Put simply, a directory contains a hierarchy that stores information about objects in a system.

A directory service is the service that manages the directory and makes it available to users on the network. Active Directory stores information about objects on a Windows Server 2003 network and makes this information easy for administrators and users to find and use. Active Directory uses a structured data store as the basis for a hierarchical organization of directory information.

You can use Active Directory to design a directory structure tailored to your organization’s administrative needs. For example, you can scale Active Directory from a single computer to a single network or to many networks. Active Directory can include every object, server, and domain in a network.

What makes Active Directory so powerful, and so scalable, is that it separates the logical structure of the Windows Server 2003 domain hierarchy from the physical structure of the network itself.

Logical Components

In Exchange 5.5 Server and prior versions, resources were organized separately in Windows and Exchange. Now, the organization you set up in Windows Server 2003 and the organization you set up in Exchange Server 2003 are the same. (The same goes for Windows 2000 and Exchange 2000 as well.) In fact, the Active Directory Users and Computers tool (whose use is covered in Chapter 5, “Creating and Managing Exchange Recipients”) is now used to configure and manage Windows users and Exchange-related user features, such as mailbox storage and protocol use. This requires a shift in thinking from previous versions of Exchange, where the duties of Windows and Exchange administrators were more clearly separated. Now, it is often advantageous to have one user administrator manage all aspects of user configuration. In Active Directory, the domain hierarchy is organized using a number of constructs to make administration simpler and more logical. These logical constructs, which are described in the following subsections, allow you to define and group resources so that they can be located and administered by name rather than by physical location.

Objects

An object is the basic unit in Active Directory. It is a distinct named set of attributes that represents something concrete, such as a user, printer, computer, or application. Attributes are the characteristics of the object; for example, a computer is an object, and its attributes include its name and location, among other things. A user is also an object. In Exchange, a user’s attributes include the user’s first name, last name, and e-mail address. User attributes also include Exchange-related features, such as whether the object can receive e-mail, the formatting of e-mail it receives, and the location where it can receive e-mail.

Organizational Units

An organizational unit (OU) is a container in which you can place objects such as user accounts, groups, computers, printers, applications, file shares, and other organizational units. You can use organizational units to hold groups of objects, such as users and printers, and you can assign specific permissions to them. An organizational unit cannot contain objects from other domains and is the smallest unit to which you can assign or delegate administrative authority. Organizational units are provided strictly for administrative purposes and convenience. They are transparent to the end user, but can be extremely useful to an administrator when segmenting users and computers within an organization.

You can use organizational units to create containers within a domain that represent the hierarchical, logical structures within your organization. This enables you to manage how accounts and resources are configured and used.

Organizational units can also be used to create departmental or geographical boundaries. In addition, they can be used to delegate administrative authority over particular tasks to particular users. For instance, you can create an OU for all your printers and then assign full control over the printers to your printer administrator.

Domains

A domain is a group of computers and other resources that are part of a network and share a common directory database. A domain is organized in levels and is administered as a unit with common rules and procedures. All objects and organizational units exist within a domain.

You create a domain by installing the first domain controller inside it. A domain controller is simply a Windows Server 2003 computer that has Active Directory enabled on it. Once a server has been installed, you can use the Active Directory Wizard to install Active Directory. In order to install Active Directory on the first server on a network, that server must have access to a server running DNS (Domain Name Service). If it does not, you’ll be given the chance to install and configure DNS during Active Directory installation.

Domain Trees

A domain tree is a hierarchical arrangement of one or more Windows Active Directory domains that share a common namespace. Domain Name Service (DNS) domain names represent the tree structure. The first domain in a tree is called the root domain. For example, a company named Widgets (that has the Internet domain name widgets.com) might use the root domain widgets.com in its primary domain tree. Additional domains in the tree under the root domain are called child domains. For example, the domain hsv.widgets.com would be a child domain of the widgets.com domain. Figure 2.1 shows an example of a domain tree.

Figure 2.1: A domain tree is a hierarchical grouping of one or more domains.

Domains establish trust relationships with one another that allow objects in a trusted domain to access resources in a trusting domain. Windows Server 2003 and Active Directory support transitive, two-way trusts between domains. When a child domain is created, a trust relationship is automatically configured between that child domain and the parent domain. This trust is two-way, meaning that resource access requests can flow from either domain to the other. The trust is also transitive, meaning that any domains trusted by one domain are automatically trusted by the other domain. For example, in Figure 2.1, consider the three domains named widgets.com, hsv.widgets.com, and sales.hsv.widgets.com. When hsv.widgets.com was created as a child domain of widgets.com, a two-way trust was formed between the two. When sales.hsv.widgets.com was created as a child of hsv.widgets.com, another trust was formed between those two domains. Though no explicit trust relationship was ever defined directly between the sales.hsv.widgets.com and widgets.com domains, the two domains trust each other anyway because of the transitive nature of trust relationships.

Domain Forests

A domain forest is a group of one or more domain trees that do not form a contiguous namespace but may share a common schema and global catalog. There is always at least one forest on the network, and it is created when the first Active Directory–enabled computer (domain controller) on a network is installed. This first domain in a forest is called the forest root domain and is special because it is really the basis for naming the entire forest. It cannot be removed from the forest without removing the entire forest itself. Finally, no other domain can ever be created above the forest root domain in the forest domain hierarchy. Figure 2.2 shows an example of a domain forest with multiple domain trees.

Figure 2.2: A domain forest consists of one or more domain trees.

A forest is the outermost boundary of Active Directory; the directory cannot be larger than the forest. You can create multiple forests and then create trust relationships between specific domains in those forests; this would let you grant access to resources and accounts that are outside a particular forest. However, an Exchange organization cannot span multiple forests.

Physical Components

The physical side of Active Directory is primarily represented by domain controllers and sites. These enable organizations to optimize replication traffic across their networks and to assist client workstations in finding the closest domain controller to validate logon credentials.

Domain Controllers

Every domain must have at least one domain controller, a computer running Windows Server 2003 that validates user network access and manages Active Directory. To create a domain controller, all you have to do is install Active Directory on a Windows Server 2003 computer. During this process, you have the option of creating a new domain or joining an existing domain. If you create a new domain, you also have the option of creating or joining an existing domain tree or forest. A domain controller stores a complete copy of all Active Directory information for that domain, manages changes to that information, and replicates those changes to other domain controllers in the same domain. Schema and infrastructure configuration information is replicated between all domain controllers in a forest.

Note

In previous versions of Windows, a distinction was drawn between primary and backup domain controllers. In Windows Server 2003 and Windows 2000 Server, all domain controllers are considered peers, and each holds a complete copy of Active Directory.

Global Catalog

In a single-domain environment, users can rely on Active Directory for the domain to provide all of the necessary information about the resources on the network. In a multi-domain environment, however, users often need to access resources outside of their domain—resources that may be more difficult to find. For this, a global catalog is used to hold information about all objects in a forest. The global catalog enables users and applications to find objects in an Active Directory domain tree if the user or application knows one or more attributes of the target object.

Through the replication process, Active Directory automatically generates the contents of the global catalog from the domain controllers in the directory. The global catalog holds a partial replica of Active Directory. Even though every object is listed in the global catalog, only a limited set of attributes for those objects is replicated in it. The attributes listed for each object in the global catalog are defined in the schema. A base set of attributes is replicated to the global catalog, but you can specify additional attributes to meet the needs of your organization.

Note

By default, there is only one global catalog in the entire forest, and that is the first domain controller installed in the first domain of the first tree. All others must be configured manually. We recommend adding a second global catalog for backup and load balancing. Furthermore, each domain should have at least one global catalog to provide for more efficient Active Directory searches and network logons.

Windows Server 2003 Sites

A Windows Server 2003 site is a group of computers that exist on one or more IP subnets. Computers within a site must be connected by a fast, reliable network connection. Using Windows sites helps maximize network efficiency and provide fault tolerance. Windows sites also help clients find the closest domain controller to validate logon credentials.

In versions of Exchange Server prior to Exchange 2000 Server, the concept of a site was used to identify a group of Exchange servers that shared a permanent, high-bandwidth connection and also represented an administrative boundary in Exchange. The concept of Windows sites is unrelated to the use of sites in earlier versions of Exchange. Exchange Server 2003 (and Exchange 2000 Server) has replaced the concept of Exchange sites with routing groups and administrative groups. Routing groups are used to define groups of Exchange servers that share a reliable (but not necessarily high-bandwidth) connection. Administrative groups are used to define administrative boundaries within an Exchange environment.

Note

Exchange Server 2003 makes extensive use of Active Directory information on global catalog servers. For efficient communication, Exchange Server 2003 requires direct access to a global catalog server in your LAN.

Sites are created using the Active Directory Sites and Services tool. No direct relationship exists between Windows domains and sites, so a single domain can span multiple sites and a single site can span multiple domains.

Schema

A schema represents the structure of a database system—the tables and fields in that database and how the tables and fields are related to one another. The Active Directory information is also represented by a schema. All objects that can be stored in Active Directory are defined in the schema.

Installing Active Directory on the first domain controller in a network creates a schema that contains definitions of commonly used objects and attributes. The schema also defines objects and attributes that Active Directory uses internally. When Exchange Server 2003 is installed, Exchange setup extends the schema to support information that Exchange needs. Updates to the schema require replication of the schema across the forest and also to all domain controllers in the forest. For more information about how Exchange updates the schema, see Chapter 3, “Installing Microsoft Exchange Server 2003.”

Active Directory and Exchange Server 2003

In versions of Exchange Server prior to Exchange 2000 Server, Exchange maintained a directory of its own through a service known as the Directory Service. On each Exchange server, the Directory Service maintained a copy of the directory in a database file on the Exchange server and took care of replicating changes in the directory to other Exchange servers. In Exchange Server 2003, the Directory Service has been removed altogether. Exchange is now totally reliant on Active Directory to provide its directory services.

This new reliance caused a shift in the way that the Exchange directory is maintained. This first section examines the effects that boundaries of a forest place on Exchange. It then looks at the interaction of DNS in an Exchange organization. Finally, it looks at the differences in directory replication now that Exchange itself no longer handles the directory information or uses the Active Directory Connector to exchange data with previous versions of Exchange Server.

Forests

By default, the global catalog shows only objects within a single Windows Server 2003 forest, so an Exchange organization must be within the boundaries of a forest. This is different from earlier versions of Windows NT and Exchange 5.5. In previous versions, an Exchange organization could span domains that did not trust one another because Exchange 5.5 did not rely so much on the underlying security structure of Windows NT. With Active Directory and Exchange Server 2003, the security structure is integrated, which means that a single Exchange organization cannot span multiple forests, but can span multiple domains within a single forest.

Domain Name Service (DNS)

In previous versions of Windows NT, the Windows Internet Name Service (WINS) was the primary provider of name resolution within an organization because it provided dynamic publishing and full names to network address mapping. DNS was really only required for organizations that needed Internet connectivity, though it was usually a recommended practice to use DNS with earlier versions of Exchange Server as well. Windows Server 2003 relies almost exclusively on DNS because it provides maximum interoperability with Internet technologies. In order for Exchange Server 2003 to function, a DNS service must be running in your organization. Outlook Web Access, SMTP connectivity, and Internet connectivity all rely on DNS.

Active Directory is often called a namespace, which is similar to the directory service in earlier versions of Exchange and means any bounded area in which a given name can be resolved. The DNS name creates a namespace for a tree or forest, such as widgets.com. All child domains of widgets.com, such as sales.widgets.com, share the root namespace. In Exchange Server 2003, Active Directory forms a namespace in which the name of an object in the directory can be resolved to the object. All domains that have a common root domain form a contiguous namespace. This means that the domain name of a child domain is the child domain name appended to the name of the parent domain.

In Windows Server 2003 domains using DNS, a domain name such as hsv.widgets.com does not affect the e-mail addresses for Exchange users created in that domain. Although a user’s logon name might be user@hsv.widgets.com, you control how e-mail addresses are generated using recipient policies in System Manager and Active Directory Users and Computers.

Directory Replication

In versions of Exchange Server prior to Exchange 2000 Server, the directory was a part of Exchange, and replication of that directory was handled by Exchange Server. When attributes of directory objects changed, the entire object was replicated throughout the organization.

Now, all directory functions have been passed to Active Directory, which replicates at the attribute level instead of the object level. This means that if a change is made to an attribute, only that attribute (and not the entire object) is replicated to other domain controllers in the domain, resulting in less network traffic and more efficient use of server resources.

Information Storage

In Exchange Server 2003, a service named the Information Store is responsible for data storage and management. It supports access by MAPI clients and by numerous Internet protocols via Internet Information Server. It also supports access through application programming interfaces (APIs) such as Collaboration Data Objects (CDO), ActiveX Data Objects (ADO), and the Active Directory Services Interface (ADSI). What all of this means is that the Exchange Information Store has become much more than a place where messages and data are stored. It has become a single repository in which an entire network of users and applications can store and manage information of just about any type. Since it holds all types of data and provides such varied access methods, Microsoft describes the Information Store in Server 2003 as the Web Store.

With this new version of Exchange, the support and management of protocols have been passed from the Exchange software itself to Internet Information Server. Separating the protocols from the storage system and providing other features, such as an Installable File System, front-end/back-end servers, and clustering support, have allowed Exchange Server 2003 to become much more robust and scalable than previous versions of Exchange.

Web Storage System

The Exchange Server 2003 Web Store combines features of the Web, the file system, and Exchange Server 2003 into a single, unified system for storing and accessing information. The Web Store serves as the sole repository for managing diverse types of information within a single infrastructure. In addition, almost every resource in the Web Store is now addressable through a solitary Uniform Resource Identifier (URI) location, commonly referred to a Uniform Resource Locator (URL).

Public Folders

Public folders provide centralized storage of just about any type of data that is meant to be accessed by multiple users in an organization. The primary use of public folders is to serve as a sort of discussion forum, allowing users to post and reply to messages in a setting where conversations are threaded by subject. However, public folders can also be used for much more, including the storage of Microsoft Office documents, administrative messages generated by Exchange Server, and even as the basis for advanced workflow applications.

Like other databases in Exchange, a public folder is actually composed of two database files— a rich-text file and a streaming content file. The addition of the streaming content file means that websites can actually be hosted from within a public folder. The HTML, Active Server Pages (ASP), or ASP.NET files reside in the streaming file of the public folder store and are accessible from any web browser using simple URLs. Also, because Exchange stores the websites, pages in the sites can make use of Exchange-specific functionality such as calendars and messaging.

Also like other databases, Exchange Server 2003 supports the storage of multiple public folder stores on a single Exchange server. In addition, Exchange Server 2003 supports multiple public folder trees in an organization.

Internet Information Services

One of the great strengths of Exchange Server 2003 lies in the way it supports standard Internet protocols for message transfer. In previous versions of Exchange, the Exchange Server software itself provided and managed the Internet protocols. Now, the responsibility of managing protocol support has been passed entirely to Internet Information Services (IIS), a built-in component of Windows Server 2003. All Exchange Server 2003 protocols are hosted within the IIS process. When Exchange Server 2003 is installed, it enhances the SMTP service built into IIS with a more robust version capable of handling the demanding Exchange routing environment.

Exchange Server 2003 subsystems, such as protocols and storage, can now be placed on separate servers to improve scalability. For this to work, a fast, reliable method of exchanging information between IIS and the Exchange storage system, the Web Store, is needed. This need is met by a component named the Exchange Interprocess Communication Layer (ExIPC). ExIPC is basically a high-performance queue that allows IIS and the Web Store to exchange data. Figure 2.3 illustrates the basic Exchange architecture.

Figure 2.3: Exchange Server 2003 architecture

The Information Store (a process named store.exe) is the Exchange service that manages the Information Store on an Exchange server. One instance of store.exe runs for each storage group on a server. store.exe manages processes such as store replication; maintains the ESE databases; and provides protocol stubs, interfaces that allow the ExIPC to transfer data between the IIS (a process named inetinfo.exe) and the Information Store. As you can see in Figure 2.3, a protocol stub exists for each protocol handled by IIS. The queuing process used by ExIPC is asynchronous, meaning that Exchange is able to allocate memory immediately after one portion of a process finishes.

Installable File System

The Installable File System (IFS) permits normal network client redirectors, such as Exchange, to share folders and items. This is a means of exposing the Exchange Information Store to users and applications on the network. Because your local computer can assign, or map, a drive letter to these resources, standard applications such as Windows Explorer and the Office 2003 suite can access resources in the Exchange Store. A user could, for example, map a drive letter to their mailbox or open a public folder from within Microsoft Word. The primary benefit of the IFS is that it allows clients to access Exchange data with no special software other than standard operating system components.

Note

In Exchange 2000 Server, installation of the Exchange server created an M: drive that served as the portal into the Exchange Store for Windows applications. By default, the M: drive was shared using the share name BackOfficeStorage. This is no longer the case in clean or upgrade installations of Exchange Server 2003. This change was brought about to prevent file-level corruption through direct file access from virus scanning and backup/restoration operations. The Exchange Information Store can still be connected to at \BackOfficeStorage.

Front-End/Back-End Servers

Since Exchange Server 2003 separates its databases from the client access protocols (now managed by IIS), there is now a distinction between store management and protocol management. Exchange now allows administrators to configure front-end servers that handle client access and back-end servers that handle the databases themselves. The front-end server becomes the point of contact for all client applications.

MAPI clients must connect directly to a back-end server and cannot use a front-end server, but other types of clients (POP3, IMAP4, etc.) can. Clients that can connect to a front-end server do so using the following process:

1. The client connects to the front-end server and makes a request using a particular protocol.

2. The front-end server relays the request to the back-end server using the same protocol used by the client.

3. The back-end server returns the requested data.

4. The front-end server returns the data to the client.

This arrangement provides load balancing for servers and also creates a unified namespace for clients.

Clustering

An Exchange Server 2003 cluster consists of between two and eight connected computers referred to as nodes. These nodes share a common storage device, such as a RAID-5 array. Exchange Server 2003 can operate in either active/active clustering or active/passive clustering.

This provides a redundant hardware solution, since clients can connect to any node in the cluster rather than to just one computer. Clustering also provides fault tolerance. Should one node in the cluster fail, the Microsoft Clustering Service (MSCS) restarts or moves the services on the failed node to a functional node in the cluster. During scheduled maintenance of a node, an administrator can also manually move services to other nodes, thus reducing or eliminating any client downtime.

When active/active clustering is used, one instance of the clustered resource runs on each of the nodes in the cluster. Exchange Server 2003 supports active/active clustering using two nodes only. If one of the nodes fails, the instance of the clustered resource is transferred to the other node. Although it might seem that using active/active clustering is economical in that it allows you to always use your available servers, it has the disadvantage of not being nearly as reliable or scalable as active/passive clustering.

The preferred type of clustering is active/passive clustering, in which one or more nodes of the cluster is online providing service to clients and one or more nodes of the cluster is online and available to pick any resources from failed active servers. When one of the active nodes fails, the resources that were running on that node are failed over to the passive node. The passive node then changes its state to active and begins to service client requests. The downside to this clustering model is that the passive nodes may not be used for any other purpose during normal operations because they must remain absolutely available should a failover situation occur. In addition, all of the nodes must be configured identically to ensure that when failover occurs, no performance loss is experienced.

Note

The number of nodes in your cluster is dependent upon the operating system on which the Exchange Server 2003 computer is installed. Active/passive clustering in Exchange Server 2003 is limited to two nodes when Exchange is installed on Windows 2000 Advanced Server Service Pack 4 (or later), four nodes when Exchange is installed on Windows 2000 Datacenter Server Service Pack 4 (or later), and eight nodes when Exchange is installed on Windows Server 2003 Enterprise Edition or Windows Server 2003 Datacenter Server Edition.

Message Flow

The flow of messages between components of an Exchange environment can be complicated. As an administrator, it would serve you well to learn how messages flow from one place (a sender) to another place (a recipient) in that environment. On a single Exchange server, component communication is relatively simple. As servers are added and grouped together into routing groups, this communication grows more complex. This section provides an introduction to the Exchange components involved in message flow and then examines the actual flow of messages in different situations.

Routing Architecture

Before we can look at the process of message flow in Exchange, it is first necessary to become familiar with some of the basic components that play a part in the routing of a message. Specifically, we will examine SMTP, the protocol used to transfer most messages in Exchange, routing groups that are used to define the routing topology of an organization, and connectors that are used to connect routing groups to one another and provide a way to transfer messages outside an Exchange organization altogether.

SMTP

SMTP is the native transport protocol in Exchange Server 2003 used to route messages within and between routing groups. In versions of Exchange Server prior to Exchange 2000 Server, a component named the Message Transfer Agent (MTA) used a protocol named X.400 to provide most routing functions. The MTA and X.400 still exist in Exchange Server 2003 but are now used only to provide communications with Exchange Server 5.5 and with foreign messaging systems using the X.400 protocol. SMTP has replaced X.400 over the past few years as the standard messaging protocol throughout the world, and so it has found acceptance in Exchange Server 2003 as the protocol of choice.

IIS handles SMTP and transfers information with Exchange via the ExIPC service that you learned about earlier in this chapter. The basic SMTP support in IIS is extended in a number of ways when Exchange Server 2003 is installed:

• A secondary store driver, drviis.dll, is added that provides message pickup and drop-off using ExIPC.

• An enhanced routing engine is installed that adds link-state information—nearly instant information about the state of links to other servers.

Additional command verbs are added that support the exchange of link-state information with other servers.

The adoption of SMTP provides a great advantage to Exchange Server 2003. In versions of Exchange Server prior to Exchange 2000 Server, servers were divided into Exchange sites that served as both routing and administrative boundaries. Within a site, communications between servers took place using remote procedure calls (RPCs), a method for invoking services on a remote computer. While RPCs are effective for message transport, they require full-time, relatively high-bandwidth connections between computers. This means that Exchange sites could really only span groups of computers that were connected by high-speed networking.

SMTP offers an advantage over RPCs: SMTP does not require a high-performance network connection. This and the elimination of Exchange sites in Exchange Server 2003 have led to much greater flexibility in the deployment of servers. Exchange Server 2003 supports routing groups, which are groups of servers connected by a permanent connection, and administrative groups, which group servers and components according to administrative needs. The result of all this is that administrative needs can now be balanced with topology requirements in the deployment of Exchange servers.

Routing Groups

A routing group is a collection of servers with full-time, reliable connectivity. Topologically, a routing group is similar to the Exchange site used in previous versions of Exchange Server but, unlike the site, it imposes no administrative restrictions. Within a routing group, all messages are transferred directly between servers using SMTP. If you have a single Exchange server or if all your Exchange servers are connected over full-time, reliable connections, there will probably not be much reason for you to create more than one routing group. In fact, unless you create a second routing group, the fact that a routing group even exists is not evident in the Exchange System Manager. When a second routing group is added, the Routing Groups container appears in System Manager, and servers are grouped according to the routing group to which they belong.

There are several reasons why you may choose to set up multiple routing groups in your organization, such as the following:

• Many Exchange servers do not have full-time, reliable, and direct SMTP connectivity to one another. This may be the case if your organization spans large geographic distances.

• You must control the path that messages travel between servers. You can create a routing group boundary to force computers in one group to use a single bridgehead server (BHS) to send messages to another group.

You can learn more about using routing groups in Chapter 8, “Building Administrative and Routing Groups.”

Connectors

Communications between servers in different routing groups and with foreign messaging systems outside the Exchange organization are established using connectors. You’ll learn more about configuring and managing connectors in Chapter 8, but a brief introduction is useful here.

• Routing Group Connector

• SMTP Connector

• X.400 Connector

Three types of connectors can be used to connect routing groups to one another.

Message Transport

All good messaging systems rely on a strong transport and routing engine to deliver messages, and Exchange Server 2003 is no different. A solid understanding of how messages are transferred between Exchange Server components is essential to managing a reliable organization and to troubleshooting any failure in message transfer.

For the most part, messages are submitted to an Exchange server using the SMTP protocol. These messages may come from a client within the Exchange system or from an outside system such as the Internet. Though messages may also be submitted to the Exchange server via direct submission from a client using IFS or via the MTA from a foreign system, we will concern ourselves here with the SMTP process.

Here’s the basic procedure that occurs when a client submits a message to the Exchange server (see Figure 2.5):

1. An SMTP client opens a connection on the SMTP Service.

2. The IIS process on the SMTP Service responds.

3. After negotiation, the SMTP process receives and processes the message.

4. The SMTP process hands the message to an advanced queuing engine, which places it into a Pre-Categorizer queue.

5. A Categorizer resolves the sender and recipient for the message, expanding any distribution lists as needed and resolving all recipients in the list. In previous versions of Exchange Server, this task was performed by the MTA.

6. Next, the advanced queuing engine passes the message to the routing engine, which parses the message against its Domain Mapping and Configuration table. The routing engine checks Active Directory and decides whether the message is destined for the local store or a remote server. If destined for a remote server, a Destination Message queue is created for the message as a temporary queue from which the SMTP service can read the message and pass it along.

   
   
   Figure 2.5: A client submits a message to an Exchange server using SMTP.

Once the message has been submitted, the routing engine decides where the message is supposed to go. In all, Exchange Server 2003 messages can get from a sender to a recipient in one of four contexts. A message can be sent as follows:

• From a sender to a recipient on the same server. This may be the case when two users have mailboxes on the same server and transfer messages between them, when a user posts a message to a public folder that exists on the same server, or when an Exchange Server component delivers a message to a local recipient.

• Between different servers in the same routing group.

• Between different routing groups.

• From a sender in the Exchange organization to a user on a foreign messaging system outside the Exchange organization.

On the Same Server

If the message is destined for the local store, it is placed in the Local Delivery queue, and the store.exe process reads the message out of the queue and writes it to the local database. Thereafter, the message is associated with the destination mailbox, and the user is notified that new mail has arrived. This is the simplest of the message transport contexts.

Between Servers in the Same Routing Group

Messages routed between servers in the same routing group use SMTP as their transport. The steps involved in routing a message between two servers in the same group are slightly more complicated than on a single server:

1. Since the message is not intended for local delivery, the message is passed to the routing engine.

2. Once in the routing engine, the message is parsed against the Domain Mapping and Configuration table and then placed in the outgoing SMTP queue for the destination server.

3. The sending server looks up the recipient’s home directory in Active Directory, conducts a DNS lookup for the MX record associated with the destination server on which the recipient’s mailbox is stored, and then creates a TCP connection to that server.

4. The message is transmitted to the destination server.

5. Once the destination server receives the message, it processes it in different ways depending on the destination of the message. If it determines that the message goes to a recipient in its local store, it follows the procedure discussed in the previous section. If it determines that the message goes to a different server or outside the organization, the above process is repeated to route the message to the correct server.

Between Routing Groups

Messages routed between servers in multiple groups incur the use of a bridgehead server at each end of the connector. The steps involved in routing messages between servers in different routing groups are as follows (see Figure 2.6, where the solid line represents the flow of messages and the dashed line represents queries):

1. Since the message is not intended for local delivery, the message is passed to the routing engine.

2. The routing group information is gathered from the configuration naming context of Active Directory.

3. The link-state information is consulted to determine the best routing path.

4. The message is passed to the bridgehead server.

5. The bridgehead server passes the message to the destination bridgehead server in the other routing group.

6. The receiving bridgehead server passes the message to the destination server in its group.

7. The message is brought into the destination server via the SMTP service and placed in the Local Delivery queue.

8. The message is taken out of the queue by the store.exe process and associated with the recipient’s inbox.

   
   Figure 2.6: Routing messages between routing groups

Outside the Exchange Organization

Message delivery outside of the Exchange organization is similar to delivery to another routing group in that a connector must be used to pass the message. Here are the steps involved in routing to another e-mail system:

1. Since the message is not intended for local delivery, the message is passed to the routing engine.

2. The routing group information is gathered from the configuration-naming context of Active Directory.

3. The link-state information is consulted to determine the best routing path. In this case, the path must end with the connector to the foreign system.

4. The routing server then either sends the message over the appropriate connector to the foreign system or, if the connector is in a different routing group, sends the message to that routing group.

5. The message is passed over the appropriate connector to the foreign system.