1.3 Comparing Exchange 2003 and Exchange 5.5

---

The Microsoft Exchange Server 5.5 architecture includes the components-shown in Figure 1.1.

Figure 1.1: Exchange 5.5 architecture. MTA, Message Transfer Agent

• MAPI clients. The most commonly deployed client is the Outlook client. It communicates with the Exchange Information Store and Exchange Directory Services using MAPI and RPC.

• Directory. The Exchange 5.5 Directory Service stores system-wide information about all e-mail users and Exchange objects, and it ensures that this information is replicated to other Exchange servers throughout the organization.

• Information Store. The Information Store is responsible for maintaining each user's private information store and the public information store.

• Message Transfer Agent. The Exchange 5.5 Message Transfer Agent is based on the X.400 standard and is responsible for transferring messaging information from one server to another.

• Connectors. Connectors are available to facilitate the exchange of messages between two Exchange Routing Groups and between the Exchange environment and foreign environments, such as Microsoft Mail, cc:Mail, and Lotus Notes.

• System Attendant. The System Attendant monitors the other components.

• Admin. The Exchange Admin program is the administrator's primary tool for managing the Exchange environment. Most additions and changes to user mailboxes and messaging system components are made using this program.

The Exchange 2003 architectural diagram as shown in Figure 1.2 is more complicated than the Exchange 5.5 architecture. Even those components that are retained from Exchange 5.5 were significantly changed.

Figure 1.2: Exchange 2003 architecture. MTA, Message Transfer Agent

IIS acts as the protocol server for Exchange, managing the socket connections to the client. Internet protocols, such as SMTP, IMAP, and POP, are hosted within the IIS environment rather than being part of Exchange. Each service is implemented as a virtual server, and each IIS instance can host multiple copies of the same protocol or multiple different protocols.

Exchange can use the IIS Front End/Back End (FE/BE) architecture to improve horizontal scalability. The FE system serves as a protocol parser, and the BE system is the interface to the store. An IMAP or POP client connects to the FE system and specifies the user's mailbox. Once the user is authenticated, the FE system consults the Active Directory to determine which BE system has the user's data. Round-robin DNS can be used to make the entire group of IIS FE systems appear to the client as a single system with a single IP address. This can be used to balance the user load across all of the FE systems. When the user load exceeds the capabilities of the FE systems, additional FE systems can be added without changing the client configuration.

Note 

MAPI clients, such as Outlook, do not use Internet protocols. Therefore, the IIS FE/BE architecture has no advantages if you only have MAPI clients.

Messages submitted by an Internet client (e.g., HTTP, SMTP, NNTP, POP, or IMAP) are stored in their native MIME format. Storing the messages in their native format means that the messages do not need to be converted when the client retrieves the message. Of course, if a MAPI client such as Outlook accesses the same MIME message, the message will be converted to Exchange Rich Text format.

Epoxy is a high-performance inter-process communication facility that uses shared memory to communicate between IIS processes and Information Store processes running on the same system.

The Exchange Installable File System is a file system interface to the Exchange Information Store. One of its purposes is to reduce memory copies and disk I/O for inbound and outbound messages. This allows the protocol servers to retain the appearance of a one-to-one correspondence between messages and files, even though the actual contents are stored in a single NTFS file.

Exchange no longer contains a directory or a directory service. Instead, it relies on the Active Directory. If you are familiar with the Exchange 5.5 directory service, with X.500, with Lightweight Directory Access Protocol directories, or with Netware NDS, then you will find the Active Directory similar-but more complex. Exchange uses the Active Directory to authenticate users, to locate other directory servers, and to supply infrastructure and configuration information.

Exchange also depends on the Active Directory Global Catalog to replicate Exchange configuration data to all servers within a forest. The Global Catalog contains all objects from the local Windows domain plus selected attributes for objects from other domains in the forest.

Exchange extends the Active Directory schema to add new Exchange-related properties to the user objects. These properties include the information store that holds the user's mailbox, user-specific quotas, and delivery restrictions. Configuration data are placed in a special Exchange container. Because Exchange is no longer responsible for the directory service, it is also no longer responsible for replicating the directory information throughout the environment. Replication of all Active Directory objects-including the Exchange objects and properties-is performed by Windows. Tailoring the replication process is also done using Windows.

All Active Directory objects and properties-including those added by Exchange-are managed using the Microsoft Management Console. Exchange users are just Windows users with the rights to use Exchange. The Exchange properties associated with a user are additional property pages for the Windows user, and they are managed using the same Active Directory Users and Computers Microsoft Management Console snap-in that is used to manage other user-related properties.

The Exchange message transfer service uses the Windows SMTP Routing Engine. The old Exchange 5.5-style Message Transport Agent is still available. However, by default, it is not configured. It is only used if needed to handle X.400 or for transport in environments that contain both Exchange 5.5 and Exchange 2000/2003 servers.

The Information Store has also changed. Each Exchange 5.5 server had a single-large private information store containing the mailboxes for all users. The size of the private information store grew in direct relation with the number of users and the number of messages retained by these users. The resulting private information store-stored as a single Windows NT file-could easily reach many gigabytes in size spanning multiple physical disks. The most significant problem caused by the large size is the increased amount of time required to restore the file from backup tapes should the file become corrupted (Figure 1.3).

Figure 1.3: Exchange 2003 Information Store architecture. ESE, Extensible Storage Engine

The Information Store has been significantly enhanced to improve scalability and availability. These changes will affect Exchange organizational designs and will also affect how Exchange is managed once it is deployed. The Exchange 2000/2003 Information Store can be partitioned into up to four Storage Groups. Each Storage Group is managed by a separate Extensible Storage Engine instance and can contain up to five databases. All databases within a Storage Group share the same set of transaction log files. Each database actually includes the following two files:

• An EDB file similar to those found in Exchange 5.5

• An STM file that stores messages submitted by Internet clients (e.g., HTTP, SMTP, NNTP, POP, or IMAP) in their native format

Changes to the Information Store influence both the placement of user mailboxes and the backup/recovery strategy for Exchange. An updated backup utility that understands and takes advantage of the new Information Store architecture is included with Exchange.

Even much of the basic terminology has changed. In Exchange 5.5, a site was both a routing topology and management boundary. Most good Exchange 5.5 designs began by defining sites on the basis of network topology and then adjusting the design to address corporate administrative needs. Trying to meet both topology and management requirements with a single structure usually required compromises that resulted in a less than desired administrative structure. One of the key advantages of Exchange 2000/2003 is the separation of these two concepts. The Exchange 5.5 site concept has been replaced by two separate structures. An Exchange routing group defines the routing topology boundary, and an Exchange administrative group defines the management boundary.

Since the Exchange 5.5 site has disappeared, the Exchange 5.5 Site Connector also has been replaced. The corresponding Exchange 2003 concept is the Routing Group Connector. The Exchange 5.5 IMS has been replaced by the SMTP Virtual Server. All of the Internet protocols can be implemented as multiple virtual servers. Exchange 5.5 Address Book Views have been replaced by Address Lists. The familiar Global Address List is just one of these address lists.

Most of the changes are designed to improve scalability, performance, or reliability. However, many of the changes either directly or indirectly influence how the Exchange environment is managed.

Do not look for the familiar Exchange 5.5 Admin program. It is gone. Exchange administration is now performed by a set of Microsoft Management Console snap-ins. User information is maintained using the Active Directory Users and Computers snap-in. Exchange-specific components are managed using the ESM snap-in.

---