This chapter is designed to provide an overview of the Exchange server's four core components and describe how they communicate with each other and with other optional components. The following are the core integrated server components (see Figure 3.1):
FIG. 3.1 The Integrated Exchange Server performs all the functions needed in the Exchange environment.
This service performs general maintenance tasks. It functions much like the central nervous system for an Exchange server. Its operation is required in order for Exchange processes to run. The System Attendant tasks are as follows:
The principal reason for communication between the System Attendant and other Exchange components involves logging messaging activity. Message logs are kept for all messages arriving and departing from the Exchange server. The following are the components that make up the communication between Exchange services:
Agent | Function |
Message Transfer Agent | The Message Transfer Agent notifies the System Attendant that it received or sent a message for delivery to other systems or sites. |
Information Store | The Information Store communicates its messaging activity for logging by the System Attendant. This includes notice that it has received or sent a message for local delivery, i.e., on the same server. |
The Message Transfer Agent (MTA) comprises the foundation of Exchange server's communication infrastructure. The MTA handles message transport to other servers, other sites, or foreign systems. In addition to being the transport vehicle for messaging information, it also maps and routs addresses, and performs some message format conversion to other system's standards. (Other connectors and "gateways" installed on an Exchange server might also handle message format conversions, such as a PROFS connector.)
Being the principal message transport mechanism, the MTA communicates with all other Exchange components, as shown in the following mini-table:
Component | Communication |
Directory Service | The MTA uses the directory service to look up a user address. The directory instructs the MTA to submit mail from other sites' directories (to perform directory synchronization). |
System Attendant | The MTA tells the System Attendant (SA) to log each instance of a message transfer. |
Administrator Program | From the Administrator Program, the MTA receives requests to manipulate messages in the queue. |
Information Store | The Information Store (IS) submits messages for delivery to other systems and is notified to receive new mail by the MTA. |
Microsoft Mail connector | The MTA is notified of new mail to handle. |
Directory Synchronization | The MTA is directed to send directory-related component messages from foreign systems. |
The Information Store (IS) is the end of the line for all messaging data successfully transmitted to an Exchange server. This includes both private messages sent to individual users and public information folders intended for viewing by many users. The IS maintains data in two distinct databases--the Private Information Store and the Public Information Store.
In addition to message storage, the IS handles local delivery of messages (when both sender and recipient are on the same server), replicates public folders, and enforces storage limits. The following is a list of the principal functions of the IS. The MTAs communicate with the following Exchange components:
Component | Communication |
Message Transfer Agent | The IS contacts the MTA to accept new incoming mail, to deliver new outgoing mail, and to resolve addresses intended for gateways. |
Exchange Clients | To the client the IS announces the arrival of new mail. Also the IS accepts new mail submitted for delivery from the client. |
Directory Service | The IS uses the directory service to look up addresses, get user mailbox information, and create directory entries for public folders. |
System Attendant | When the IS either receives or sends a message, it notifies the System Attendant so a log entry is generated. |
Administrator Program | The Administrator Program sends instructions to the IS to show statistics about connected users and other storage usage information, e.g., folder sizes. The Administrator Program connects to the IS to view information, logons, and resources. |
Connectors/Gateways | IS communication to connectors/gateways involves the retrieval and delivery of messages to foreign systems. |
The Directory Service (DS) maintains all the information about users and resources in an organization. This includes a structured view of all server names, mailboxes, and distribution lists in a site. Also, the directory service keeps configuration information used by other Exchange server components when mapping addresses and routing messages.
In order to maintain consistency of addressing information across several Exchange servers, directory data is automatically replicated among all servers in a site. This replication within a site is carried out by the MTA and administered by the Directory Service. The Directory Service also manages directory replication between sites on a scheduled basis (see Chapter 7, "Planning Connections to Microsoft Mail Systems," on directory synchronization/replication.)
The directory service classifies organization information (servers, mailboxes, and so on) as objects. Being objects, through the administrator program, one can specify their characteristics as well as determine who can use or change them (see Chapter 21, "Configuring X.400 Connections," on Exchange component administration). The following is a list of components of the Directory Service and how they communicate with these Exchange services:
Component | Communication |
Other Directories | Directories communicate with other Directory Services within the same site to replicate directory information. |
Message Transfer Agent | The directory service notifies the MTA in order to send mail to and receive mail from other directories (during directory replication). The MTA looks up addresses and configuration information from the Directory Service. |
Administrator Program | The administrator program commands the directory to display and modify the address book, list of recipients, user properties, and directory objects (servers, monitors, connectors, and so on). Also, the administrator program can create objects in the directory. |
Exchange Clients | Client programs call upon the directory to find a specific user's address and to display the address book, resolve an e-mail name to a full alias, and modify distribution list memberships. |
Information Store | The IS uses the directory to look up address and configuration information, get information about mailboxes, and create directory entries for public folders. |
System Attendant | The SA uses the directory to look up address and configuration information, build routing tables, generate e-mail addresses for new recipients, and verify consistency of directory information. |
Directory Synchronization | The directory synchronization component generates component requests to create, modify, and delete custom recipients. Also, it asks to look up recipients and configuration information. |
Microsoft Mail Connector | The Microsoft Mail Connector looks up addresses from Microsoft Mail for PC networks and configuration information in the directory. |
Connectors/Gateways | A connector/gateway uses the directory to replicate directory information and look up address and configuration information. |
The Administrator Program is the primary tool for administering Exchange. Though it is not an integrated server component, it does comprise an essential part of the Exchange architecture. Further chapters will describe the multitude of functions provided by the administrator program, but this will present the basic description of its communication with a few integrated server components. The following is a list of programs controlled by the Exchange Administrator program along with their associated functions:
Program | Function |
Directory | Through the administrator program, one can display the address book, the main viewer, lists of recipients, properties of a user, and directory objects. Also, the administrator program enables you to create objects in the directory. |
Message Transfer Agent | The administrator program enables you to manipulate messages in the various queues of the MTA. |
Information Store | The administrator program enables you to create and delete mailboxes, as well as show statistics about information storage usage such as number of users logged on. It also provides information on the private and public information stores (connections, logons, resources) and determines schedules for public folder replication. |
One of the big improvements Microsoft has made with Exchange is the integration of connectors into the server. For the most part, this feature eliminates the need for external boxes to establish connections to other mail systems. (Some exceptions might be fax or voice mail servers that may still require a dedicated machine.)
Connectors allow Exchange to swap information with various messaging systems. They provide tight integration with all the tools and utilities Exchange administrators will be using in the running of the server, such as the Performance Monitor, Link Monitor, and the Administrator Program.
This section will cover:
Using Exchange connectors is an easy transition for anyone who has configured mail gateways for other mail systems. For example, the Simple Mail Transfer Protocol (SMTP) gateway for cc:Mail has many of the same configuration parameters as the Internet Mail Service.
NOTE: In Exchange 4.0, the SMTP connector was called the Internet Mail Connector (IMC). This has been renamed in Exchange 5.5 to the Internet Mail Service to reflect the enhanced features that have been added.
These include whether to act as inbound or outbound gateways or both; which act as the administrator, where bounced and non-deliverable messages are delivered; and whether attachments are handled via Multimedia Internet Mail Extensions (MIME) compliance or UUENCODE. Being familiar with these terms as well as with Windows NT and WIN95 properties boxes facilitates configuration. By filling out property pages in the Administrator Program, as shown in Figure 3.2, you can be up and running without a lot of hassle.
FIG. 3.2 The properties page for the Internet Mail Service gives the administrator many configuration options.
In addition, connectors can be used to link multiple mail system. For example, the Internet Mail Service can be used effectively in organizations where some departments choose to use Exchange, while others choose different platforms. Many of these organizations standardize on SMTP to transfer messages between departments because most LAN-based email packages have some form of SMTP gateway since SMTP is a non-proprietary Internet standard. These kinds of uses will be explained in more detail later in this chapter.
The following connectors will be explained in this chapter:
Connecting existing Microsoft Mail systems with Exchange is very common in a large enterprise during a migration and coexistence phase. With an installed user base of at least four million users, it makes sense that Exchange server would strongly support compatibility with Microsoft Mail.
Primarily, this compatibility comes in the form of the Microsoft Mail Connector. This component bridges the gap between standard Microsoft Mail post offices and Exchange server. Essentially, Exchange emulates the functionality of a Microsoft Mail post office so other Microsoft Mail computers see it as just another member of the chain.
Microsoft Mail is a shared-file, LAN-based messaging system. Messages are sent to file servers hosting one or more post offices to which a user connects to retrieve messages. In order to integrate with this system, Exchange's Microsoft Mail Connector presents a post office of its own to which any other post office can connect. This enables other Microsoft Mail post offices to continue normal operation--that is, of course, until they are migrated to Exchange as well.
The Microsoft Mail Connector (PC) consists of the following components:
FIG. 3.3 The Microsoft Mail Connector Architecture.
FIG. 3.4 The Microsoft Mail Connector (AppleTalk) Architecture.
In this scenario, an Exchange server with the Microsoft Mail Connector installed is connected to a Microsoft Mail post office (see Figure 3.5).
FIG. 3.5 Microsoft Mail connector.
The following is a typical example of message transfer between both systems:
In the opposite situation, when a message originates from a Microsoft Mail user, the previous sequence is exactly reversed.
Microsoft Mail networks not on the same logical LAN can also be bridged with the Microsoft Mail Connector. Such connections are commonly established by modem or wide area X.25 links. Exchange's Microsoft Mail Connector (PC) MTA can be configured to support asynchronous or X.25 connections (see Figure 3.6). However, a normal Microsoft Mail post office cannot alone handle this connection. There must be a Microsoft Mail 3.x External or Multitasking MTA program set up to provide the modem management and message transfer functions over a remote link.
A single Exchange server can run multiple instances of the Microsoft Mail connector MTAs (see Figure 3.7). Each MTA runs as a Windows NT system service that can be stopped and started independently of any other service. The best way to architect such connections is to create one instance of the MTA for each type of network connection. Therefore, one MTA is dedicated to an X.25 link, while another can service a modem link, and still another can connect to a local LAN.
FIG. 3.6 Microsoft Mail Connector MTA.
FIG. 3.7 Exchange server with multiple Microsoft Mail connectors.
If your organization uses a large number of Microsoft Mail 3.x post offices, or they are spread over a wide area, then you would perhaps want to set up multiple Microsoft Mail connectors within your organization and use Exchange as a "backbone" for these scattered post offices to ease administration and improve reliability of message transfer. It is not possible to "backbone" Exchange traffic over an Microsoft Mail network of post offices due to serial number restrictions in Exchange.
NOTE: It is important to realize that all Microsoft Mail connectors in a site will use the same email address. From the Microsoft Mail perspective, each site will be seen as one large post office. As a result, it is not recommended that several Exchange servers in the same site pickup and deliver mail to a single Microsoft Mail post office in order to prevent file contention on the Microsoft Mail side.
Exchange's use of the X.400 standard enables a broad interoperability with a wide range of messaging systems. X.400 is a standard set by the International Telephone Union (ITU), formerly known as the International Telegraph and Telephone Consultative Committee (CCITT). To date, there have been three iterations of the X.400 standard (1984, 1988, 1992). The initial release version of Exchange supports the 1984 and 1988 standards, with the 1992 version to be supported in later versions.
The X.400 standard defines the basic framework of a message handling system, the structure of the message and its components, and how messages are transferred. It is widely supported and used by most public email carriers and telecommunication providers. Because of its widespread acceptance, many companies have already developed gateways to bridge their messaging systems with X.400. In real-world situations, where network, hardware, and communication standards are not strictly enforced, X.400 provides a common ground for interoperability between messaging systems. Microsoft has assured Exchange's strict conformance to government X.400 standards, which means that Exchange will be a reliable solution for the widest possible number of X.400 connections.
The Exchange X.400 connector provides all essential connectivity with this standard. In this section, you will see:
The X.400 standard makes provisions for specific components of a Message Handling System (MHS), including a structure for message content and addressing. These components are:
Microsoft fulfills each element specified by the X.400 standard. In fact, the whole Message Transfer System design is the basis for Exchange's Server site and organization structure.
When referring to a Exchange X.400 connector, one is really describing the use of an Exchange MTA configured to connect to an X.400-based system. Exchange MTAs are compliant with other MTAs (in another Exchange server or an external system) that comply with the 1984 or 1988 X.400 standards. The Exchange MTA can be extensively configured to negotiate such connection over the standard X.400 network transports TP0, TP4, and TCP/IP.
The Message Store requirement is met by Exchange's public and private information stores.
The User Agents are realized as Exchange Client programs currently available on several common platforms.
The Access Units are the many gateways currently available for use with Exchange (PROFS, SNADS, Fax, pager, and so on). Each provides a route into its particular system.
Much like an Exchange address is identified by the user at site structure, X.400 addresses are distinguished by unique personal information and information about the system on which they receive messages. A typical X.400 address contains:
c=US; admd=MCI; prmd=Software Spectrum; o=Garland; ou1=Consulting; s=Bradley; g=Tracy;
Each element is described in Table 3.1.
Element | Description |
c=US | country |
admd=MCI | Administrative Management Domain. Usually the name of your X.400 service carrier. |
prmd= | Primary Management Domain. Usually equates to the name of your company or your Exchange enterprise. |
o= | Organization. A sub-component of the X.400 prmd that to Exchange is the name of a site. |
ou1= | Organizational Unit. The X.400 attribute which helps further identify the remote site. This component is by default not utilized in auto-generated Exchange naming conventions, but could be added. |
s= | Surname. Usually a user's last name. |
g= | Given name. Generally a user's first name. |
NOTE: To appropriately route messages in a site or between sites, Exchange uses what is called the X.400 global domain identifier (GDI) of the local site. In order for messages to be routed correctly, the GDI used for an Exchange Server cannot be identical to the GDI of a connected foreign system. This will become an issue only when using Exchange to connect to foreign X.400 systems. n
As a system administrator, you can use Exchange's bulk import utility to merge a series of foreign addresses into Exchange's global address list. Additionally, the Exchange client's Personal or Outlook Address Book enables individual users to create user entries based on X.400 addresses via an X.400 template.
X.400 addresses for recipients on an Exchange server are automatically created when a new mailbox is created.
Connecting an Exchange Server site to a foreign X.400 system will be one of the primary uses of the X.400 connector. However, there are a number of connection possibilities afforded by the implementation of this versatile tool. Connections over X.400 between Exchange sites can be established to share directory information, replicate public folders, transmit standard messages, or all of the above. Figure 3.8 gives an example of possible usage.
FIG. 3.8 You can connect an existing Microsoft Mail server to a foreign X.400 system (through an Exchange server).
The Exchange X.400 connector, in conjunction with the Microsoft Mail Connector, can enable users on Microsoft Mail to access X.400 systems (see Figure 3.9).
A common use of the X.400 connector in Exchange is bridging messaging systems that are geographically dispersed. In this example, an Exchange server is set up to transfer messaging data with a Microsoft Mail system using an Exchange X.400 connector on one end and a currently available Microsoft Mail X.400 gateway on the other (see Figure 3.10).
FIG. 3.9 You can connect an Exchange Server site to a Microsoft Mail post office.
FIG. 3.10 You can connect two Exchange Server sites.
Two Exchange Server sites can be linked via a public (or private) X.400 mail system. All that is required is one properly configured message transfer agent at either end. The same technique is applicable over a TCP/IP network, either intranet or Internet and might be desirable given possible bandwidth issues that prevent the use of the Exchange Site Connector.
As its name implies, the Internet Mail Service (which replaced the Internet Mail Connector (IMC) in Exchange 4.0) provides integrated, native SMTP connectivity to the Exchange server along with other new features. In doing this, Microsoft has eliminated the need for the DOS-based SMTP gateway for Microsoft Mail 3.x that lacked robustness, had memory allocation problems, possessed little or no security, and needed an external HOST to send out SMTP mail.
The Internet Mail Service (IMS) solves those problems by providing a stable, proven, and secure platform with Windows NT Server. In addition, the Internet Mail Service can send and receive SMTP mail without the need for external hosts, is MIME-compliant, and provides robust performance.
Some of the new features added to Exchange 5.5 from version 5.0 include:
FIG. 3.11 Internet Connector Architecture.
In addition to providing Internet mail functions, the Internet Mail Service enables those users running TCP/IP over the backbone to connect Exchange sites to each other using the connector. As mentioned previously, decentralized organizations often give control of the mail system to the respective department. Many large universities and corporations operate this way. These organizations often choose SMTP as the way for disparate mail systems to communicate because it is an Internet standard. Microsoft has recognized that many companies route only TCP/IP over their WANs to maximize router throughput. A diagram showing how to link disparate Exchange sites by using the Internet Mail Service is shown in Figure 3.12.
The Internet Mail Service provides for full integration into environments where security is a big concern. Many companies configure firewalls to protect internal data from hackers on the Internet. In addition to all the security components inherent to Exchange and Windows NT Server, the Internet Mail Service provides the ability to refuse messages from any specified hosts. This provides protection from several forms of hacking or "denial of service" attacks because many hackers use the email system to carry out their work. For example, you might configure the connector to refuse mail from all hosts other than a certain mail relay. That means that a hacker could not send messages or commands directly to your Exchange server. By refusing mail from certain hosts, Exchange is flexible enough to fit into existing company security policies. Any hacker would have to compromise the firewall in order to send a message directly to the Internet Mail Service.
FIG. 3.12 Connecting Multiple Exchange Sites Over TCP/IP.
Exchange can also be configured to enable only incoming or outgoing traffic through the connector. This is an important feature because one Windows NT server can only do so many things and complete so many tasks without taking a performance hit. Configuring the connector to only send out mail might be a good idea for a machine that is already overloaded. This configuration should not be a cause for concern as long as there is an incoming Internet Mail Service elsewhere in the Exchange site or organization. For example, if you have the Internet Mail Service configured on two servers and configure one to receive-only and the other to send-only, the Exchange users' email addresses will still be the same. Users will not know where the mail came in. The connections are completely transparent. Figure 3.13 shows the properties screen where the administrator can configure security and transfer options.
Additional information about the functions and configuration of the Internet Mail Service can be found in Chapter 22, "Configuring the IMS."
The Exchange Connector for Lotus cc:Mail provides seamless communication between Exchange Server and Lotus' cc:Mail product. In the past year , Lotus has embraced the MAPI standard for messaging-enabled applications, switching from their previous Vendor Independent Messaging (VIM) standard. The cc:Mail Connector enables connectivity between Exchange and these cc:Mail post offices running Lotus cc:Mail Post Office Database Version 6 and cc:Mail Import version 5.15 and Export version 5.14 or Lotus cc:Mail Post Office Database version 8 and cc:Mail Import/Export Version 6.0. The cc:Mail Connector has many configuration variables enabling the use of the existing cc:Mail tools, such as Import, Export, and ADE to enable robust, hassle-free connections to cc:Mail VIM post offices.
FIG. 3.13 Internet Connector Connections Properties.
cc:Mail users are to be directly imported into the Microsoft Exchange Global Address Book and will appear just like any other Custom Recipient Exchange user.
Just as with the Microsoft Mail Connector, a cc:Mail post office is created on the Exchange server, resulting in Exchange server users appearing in the cc:Mail directory like all other cc:Mail users. This gives transparency to the cc:Mail user. As far as he or she is concerned, all users in the Global Address Book are local.
Exchange enables the administrator to set the paths to the standard Import and Export utilities that come with cc:Mail. These utilities are used to import and export directory and message data from the Exchange server to all other cc:Mail post offices in the cc:Mail network. Examples of the uses of this connector are shown in Figure 3.14.
On the cc:Mail side, Exchange looks just like any other post office; by using Automatic Directory Exchange (ADE), all cc:Mail post offices, including the Exchange cc:Mail post office, can be kept up to date as users are added on both sides. The following Figure 3.15 illustrates some of the components involved.
Microsoft realized that cc:Mail is a large player in the LAN-based messaging market. By making the cc:Mail Connector available, it has leveraged this popularity. In some organizations, many dollars have been spent on training personnel to install and maintain cc:Mail, as well as hardware resources. Using Exchange means that your organization will not have to throw away existing mail systems to roll out a new one.
FIG. 3.14 Architecture of the cc:Mail Connector.
Gateways provide a way for Exchange to integrate disparate information services into Microsoft's Universal Inbox, using the single Exchange Viewer to organize all types of information. These include voice mail, fax, paging, as well as email from other vendors' systems.
Despite the variety of information services that snap into Exchange, the end user sees no difference. To them, the addressee is the addressee. A user can address a message and send it, and the addressee might get a page, fax, voice mail, or Internet message. The addressee may be using cc:Mail, PROFS, SNADS, or Microsoft Mail, and the user sending the message would never know because all they need to know is the addressee's name in the Global Address Book.
In addition to native Exchange gateways, Exchange can use standard Microsoft Mail 3.x gateways by using the Microsoft Mail Connector described earlier in this chapter. Each gateway uses the Microsoft Mail Connector to exchange data with foreign mail systems. This may be useful for sites with large Microsoft Mail installations that are slowly migrating to Exchange, but want to provide the core messaging functions first and add connectors and gateways later. In addition, some organizations are hesitant to sway from things that work. For example, if the Microsoft Mail gateway to PROFS has been working fine, some may be hesitant to roll out an Exchange PROFS connector or gateway because they haven't had the opportunity to test it and get their staff familiar with it. Figure 3.16 shows how Microsoft Mail gateways fit into the Exchange topology.
FIG. 3.15 ADE Synchronization between the cc:Mail and Exchange.
In the preceding case, the PROFS gateway for Microsoft Mail simply talks to the Microsoft Mail Connector post office. When configuring the PROFS gateway for Microsoft Mail, you simply point it at the Microsoft Mail Connector post office and the exchange of information becomes transparent.
With Exchange, Microsoft took those concerns into consideration and provided the flexibility to use legacy systems in the migration to a robust Exchange environment.
This is a new connector to Exchange 5.5. The Exchange Connector for Lotus Notes allows for the delivery of messages between Exchange and Lotus Notes to be transparent.
The Connector for Lotus Notes provides:
FIG. 3.16 Message flow of Exchange to PROFS using PROFS Gateway for Microsoft Mail.
The Exchange Connector for Lotus Notes is used for message transfer and directory synchronization between Exchange and Lotus Notes. Multiple instances of the connector can be used, dependent upon your organizations messaging needs. Each Exchange server in your environment can run only one instance of the connector that directly services one connection to a Lotus Notes/Domino server. Also, a connection can only be configured to service one Lotus Notes/Domino server.
The Connector for Lotus Notes and the Lotus Notes Client are installed on the Exchange Server. On the Lotus Notes Server, a user needs to be created. This will create the connector ID file, which is used by the connector. These users need to be granted appropriate permissions to the Lotus Notes Public Address Book and Exchange.box. An example of this connector is shown in Figure 3.17.
FIG. 3.17 Exchange Connector for Lotus Notes Architecture.
© Copyright, Macmillan Computer Publishing. All rights reserved.