Active Directory maintains all of the address lists and most of the Exchange 2000 Server configuration information in its directory database. The Information Store is responsible for the mailbox and public folder stores. The IIS process and its information services pull configuration information primarily from their metabase. The MTA keeps its data in its own specific message queues outside the Information Store. Other components, such as MS Mail Dirsync and Key Management server, might add additional data repositories, such as the Dirsync and Key Management databases. Following the object-oriented programming model, only that particular component has direct access to a repository that is responsible for its maintenance. All remaining server elements must communicate with this repository service through an appropriate communication mechanism to obtain the desired information. Well-defined communication paths have been implemented, and knowledge of these paths can help you understand the functionality of Exchange 2000 Server.
This lesson addresses the communication between server-based components and the paths between these components and Outlook 2000 and the Exchange System Manager utility. The communication between optional components and essential components is also discussed. At the end of this lesson, you can read about the flow of messages through an Exchange 2000 server system.
At the end of this lesson, you will be able to:
Estimated time to complete this lesson: 90 minutes
The components of Exchange 2000 Server can communicate with each other using various interprocess communication mechanisms. They rely on lightweight remote procedure calls (LRPCs) and simultaneously support Windows Sockets. LRPCs are the local version of RPCs used between the information store and those components that depend on MAPI and related APIs for communication. Regular RPCs, on the other hand, are used when the server components need to communicate with MAPI-based programs, such as Outlook 2000 or the Exchange System Manager, over the network. The Exchange 2000 Server components themselves prefer SMTP and e-mail messages for their network communication, a new feature in Exchange 2000 Server.
Exchange 2000 Server also utilizes new communication mechanisms, such as the ExIPC layer, which allows shuttling data between the IIS services and the Information Store quickly using shared memory (see Figure 3.5). In some cases, processes also share data via ordinary files on the file system. For instance, the internal modules of the connector for Lotus cc:Mail place temporary scratch files into the \CCMCData directory when transferring messages between the two systems, which is explained in Chapter 27, "Connecting to Lotus cc:Mail."
Figure 3.5 Essential components and interprocess communication mechanisms
Windows Sockets is Microsoft's implementation of a network communication mechanism known as Sockets, which was first popularized by Berkeley Software Distribution UNIX. Sockets is a de facto standard for accessing datagram and session services over TCP/IP. Windows Sockets, however, is not limited to TCP/IP. Windows Sockets 2 provides a protocol-independent interface supported over both TCP/IP and Internetwork Packet Exchange/Sequenced Packet Exchange (IPX/SPX). It is important to note that Windows Sockets is not a protocol in itself; it is only an interface utilized to access the underlying network protocol. Because it is not a protocol, it does not add any protocol overhead to the network packet. Exchange 2000 Server components written to the Windows Sockets interface include the IIS modules but also the Information Store, MTA, SA, and others. Basically, every Exchange 2000 Server service supports communication over Windows Sockets.
Windows Sockets is a protocol-independent networking API offering the following advantages:
If you are interested in further information about Windows Sockets, refer to the Microsoft Software Development Kit and the Microsoft Developer Network.
Microsoft RPCs are compatible with the Open Software Foundation Distributed Computing Environment specification for RPCs. RPCs are an application-layer communication mechanism, which means that RPCs use other interprocess communication mechanisms, such as NetBIOS, named pipes, or Windows Sockets, to establish the communication path. With RPCs, essential program logic and related procedure code exist in different executable modules possibly running on different computers, which is important for distributed applications. In other words, RPCs enable applications to call functions remotely. This makes interprocess communication as easy as calling a function in a program, which is why some programmers prefer this form of interprocess communication. However, RPCs have several disadvantages, including the following:
Exchange 2000 Server processes can share information through shared memory, files, and e-mail messages. The principle is always the same: One process writes the data into a file-based repository, and the component that is supposed to receive the information retrieves it from there. Shared memory can only be used on the local computer, files are used primarily for interprocess communication on the local machine, and e-mail messages are used for communication over unreliable network links. Many Exchange 2000 Server components, such as the Public Folder Replication Agent, rely on e-mail messages for server-to-server communication. Shared memory, on the other hand, works similar to ordinary files on the file system. You can think of shared memory as a file that is held in memory instead of the disk.
Messaging clients and administrative utilities communicate with various server components to perform their tasks. Clients prefer RPCs and management utilities rely primarily on LDAP to communicate with Windows 2000 Server's directory service, although RPCs are also used when necessary.
Client-based communication is straightforward and less complex than communication through administrative interfaces. This is not astonishing because clients serve one primary purpose: They provide users with access to personal mailboxes and public folders, which together are maintained by the information store. Hence, the Information Store service is the client's most important communication partner.
Outlook 2000 and other MAPI-based clients also need to communicate with Active Directory to log on to mailboxes and retrieve recipient information from address lists, which is often accomplished using the DSProxy component of the SA service. Therefore, MAPI-based clients communicate unknowingly with SA as well (see Figure 3.6). Internet-based clients, on the other hand, don't access the Information Store directly. They use their respective intermediate services, which are covered in more detail in Chapter 11, "Internet-Based Client Access."
You will start administrative utilities, such as the Exchange System Manager utility, whenever you want to inspect or change the configuration of Exchange 2000 Server components. The Exchange System Manager allows you to manage most aspects of the server configuration, so it must communicate with many server components.
Figure 3.6 Outlook and Exchange System Manager communication
When you administer Exchange 2000 Server, the Exchange System Manager communicates with the nearest Active Directory (a domain controller) via LDAP. When you change the configuration of any objects within Active Directory, these modifications are replicated automatically to all existing domain controllers in your forest. This was covered in Chapter 2, "Integration with Microsoft Windows 2000."
The Information Store service the Exchange System Manager's communication partner. Using the Exchange System Manager, you can specify which public folders your server will maintain. You can also configure the Exchange 2000 server to become a dedicated public or mailbox server by removing all mailbox or public stores, and you can configure multiple storage groups. The configuration of the information store is covered in more detail in Chapter 17, "Public Folder Management," and Chapter 18, "Public Folder Replication."
The SA service is contacted in the event you attempt to examine dynamic information maintained by the SA service, such as the Domain Controller Used By Services On This Server (which can be found on the General property page of each server object).
To view messages awaiting delivery in the message queues of the SMTP service, the MTA, or installed connectors, communication with the corresponding service is required. Otherwise, you will not be able to open the Queues tree in the System Manager (found under Servers/BLUESKY-SRV1/Protocols/SMTP/Default SMTP Virtual Server/Queues). You can read more about message queues later in this chapter and in Chapter 20, "Microsoft Exchange 2000 Server Maintenance and Troubleshooting."
The Exchange System Manager also communicates with other components when they are installed, configured, and active, for instance, to display status information, such as information about current user sessions. The Key Management server will be contacted if you want to enable users with advanced security features. Note that the Key Management Service (KMS) must be accessible through RPCs if you want to create security tokens or designate additional security administrators. The administration of Key Management server is covered in detail in Chapter 19, "Implementing Advanced Security."
In this exercise you will find out when and why the Exchange System Manager is communicating with Exchange 2000 Server components. The Exchange System Manager is introduced in more detail in Chapter 12, "Management Tools for Microsoft Exchange 2000 Server."
To view a multimedia demonstration that displays how to perform this procedure, run the EX2CH3*.AVI files from the \Exercise_Information\Chapter3 folder on the Supplemental Course Materials CD.
To verify the Exchange System Manager communication
At this point, you are able to start the System Manager successfully and display the configuration of your environment (see Figure 3.7) because the configuration is stored in Active Directory, which is still active and can be accessed.
Figure 3.7 Error messages in Exchange System Manager
The Exchange System Manager must be able to communicate with all essential components and additional components, if they are installed. This application communicates with Active Directory through LDAP, but also uses RPCs to communicate directly with other server components, such as the information store for mailbox and public folder statistics. This communication takes place through LRPCs when you run this application directly on the server computer, or RPCs when communicating over the network.
Which is the busiest component in any Exchange 2000 Server environment? As Figure 3.8 suggests, almost every Exchange 2000 Server component retrieves information from Active Directory, such as configuration information or information about recipients, or at least communicates with Active Directory for validation of access permissions. Some components, such as the MS Mail directory synchronization, may also want to place information in Active Directory. The only component this doesn't apply to is the Event Service implemented to provide backward compatibility with event scripts written for Exchange Server 5.5. The Event Service doesn't need to retrieve information from Active Directory because it only awaits notifications from the Information Store service.
Figure 3.8 Exchange 2000 Server components and Active Directory
With so many components, plus MAPI-based clients and the administrative utilities accessing directory information, Exchange 2000 Server has the potential for monopolizing Active Directory. The Global Catalog represents an especially precious resource. By default, only the first domain controller installed in a forest is a Global Catalog server, so you should manually configure additional Global Catalogs in each site and monitor their workload carefully. At least one Global Catalog should be available in each domain.
Exchange 2000 Server helps reduce the load on Active Directory through its directory access cache (DSAccess). As shown in Figure 3.9, DSAccess is used to cache directory information on the Exchange 2000 server. The IIS process, SA, Information Store, MTA, and other components perform directory lookups through DSAccess, which returns the information directly without contacting Active Directory if the information is available in the cache. This greatly increases the performance of both Exchange 2000 Server and Active Directory.
NOTE
With the exception of address book lookups from MAPI-based programs and the SMTP routing process, all directory access goes through DSAccess.
Figure 3.9 Caching Active Directory information
Active Directory is not the only component involved in component-to-component communication. The System Attendant (SA), for instance, contacts the Information Store and the KMS if installed. The SA also has to deal with the IIS process to update the IIS metabase with information from Active Directory, as explained earlier in this lesson.
According to Figure 3.10, the SA contacts several server components for the following reasons:
Figure 3.10 Communication initiated by the SA
The Information Store works primarily with the messaging clients, the SMTP service, and the SA as messages are sent and delivered within an organization. The SA, for instance, is notified about link monitor test messages and replies coming in from other SAs. The Information Store also provides delivery-related data to the SA, which is necessary if you want to maintain tracking log information that can be used to verify whether and when a particular message has arrived at its destination mailbox. Tracking logs are explained in Chapter 20, "Microsoft Exchange 2000 Server Maintenance and Troubleshooting."
As shown in Figure 3.11, the Information Store communicates with the following components:
Figure 3.11 Communication initiated by the Information Store
The SMTP service has to process all messages sent by users on an Exchange 2000 server. In other words, the SMTP service receives every individual message from the Information Store to determine whether the recipients reside on the local computer or on remote systems (see Exercise 1 in Lesson 1). When distribution lists are specified, the SMTP service can expand these lists to perform the operation for each individual distribution list member.
NOTE
In a native Exchange 2000 Server environment, the SMTP service is the only component directly communicating with its counterparts on remote Exchange 2000 servers. All other Exchange 2000 Server components rely on the SMTP message transport for their server-to-server communication.
As shown in Figure 3.12, the SMTP service communicates with the following components:
It is important to note that the SMTP service does not directly communicate with the MTA or any gateways installed on the local computer. If a message is sent to a foreign X.400 system, for instance, the SMTP service uses the MTA by means of the Information Store to transfer the message. The MTA receives its messages from the Information Store and can establish connections to remote systems via X.400 connectors. The MTA is also directly involved in the communication through the MS Mail Connector, as explained in Chapter 26, "Connecting to Microsoft Mail and Schedule+."
All MAPI-based messaging connectors, such as the connectors for Lotus cc:Mail, Lotus Notes, and Novell GroupWise, are not accessed by the MTA because they communicate directly with the Information Store where their message queues reside (see Chapters 27-29). However, the MTA performs the message routing to foreign systems and has to deliver the messages to the message queues of these gateway connectors by means of the Information Store.
Figure 3.12 Communication initiated by the SMTP transport
Table 3.1 gives a brief overview of which additional components may initiate communication with other components.
Table 3.1 Additional Components That May Initiate Communication with Other Components
Component | Contacted Components |
---|---|
Conference Management Service(CMS) | Information Store. To coordinate the conference bookings via Outlook meeting requests sent to a conferencing mailbox. (The CMS supports the Microsoft Exchange Conferencing service for video conferences and the T.120 MCU Conferencing service for data conferences, which both don't initiate any communication with Exchange 2000 Server components.) |
Connector for Lotus cc:Mail | Active Directory. To perform directory synchronization Information Store. To process messages from and to Lotus cc:Mail post offices SA. To process Address Book information from Active Directory via DSProxy |
Connector for Lotus Notes | Active Directory. To perform directory synchronization Information Store. To process messages from and to Lotus Notes SA. To process Address Book information from Active Directory via DSProxy |
Event Service | Information Store. To track and process events and data |
Exchange Chat | Does not initiate any communication with Exchange 2000 Server components but integrates with Active Director and IIS |
Instant Messaging | Does not initiate any communication with Exchange 2000 Server components itself but integrates with Active Directory |
Key Management Server | Does not initiate any communication with Exchange 2000 Server components itself |
MS Mail Connector | SA. To resolve recipient addresses from Active Directory via DSProxy and convert them into Exchange or MS Mail formats, respectively MTA. To transfer mail from and to MS Mail and StarNine/MS Mail (AppleTalk) SA. To enable message tracking for messages transferred through the MS Mail connector |
MS Mail Directory Synchronization | Active Directory. To create, modify, or delete user definitions from remote systems and to check for modifications in the Exchange address list that need to be distributed to foreign systems MTA. To receive and submit Dirsync-related messages from and to foreign systems |
MTA | Active Directory. To retrieve configuration information, perform routing to foreign systems, and to resolve remote distribution lists locally Information Store. To deliver and retrieve messages MS Mail connector. To exchange mail with MS Mail and StarNine/MS Mail (AppleTalk) users X.400 connectors. To send messages to other Exchange servers and foreign X.400 systems |
NNTP Service Outlook Web Access | Information Store. To process messages in public folders Active Directory. To resolve address information and check user privileges Information Store. To process messages in mailboxes and public folders |
Schedule+ Free/Busy Connector | Information Store. To receive and store schedule information from MS Mail postoffices and to send schedule information from Exchange Server to MS Mail SA. To retrieve Address Book information from Active Directory using DSProxy |
SRS and ADC | Active Directory. To transfer directory-related information between the SRS database and Active Directory using connection agreements Information Store. To generate and receive directory replication messages to integrate Exchange 2000 Server seamlessly with previous Exchange Server versions |
The central control station of all native Exchange 2000 Server message transfer is the SMTP service—the Exchange 2000 Server extensions of the SMTP service, to be exact. Exercise 1 in this chapter is a proof of it. However, getting a message on its way to the destination is not a trivial task. For instance, a message may be addressed to a distribution list of hundreds of people including users on the local server, remote Exchange 2000 servers, and a variety of foreign messaging systems.
If your environment contains connections to the Internet, X.400 systems, MS Mail, Lotus cc:Mail, Lotus Notes, Novell GroupWise, a legacy PROFS connection through a computer running Exchange Server 5.5, a popular fax gateway, and not to forget an exotic pager gateway, then a distribution group called Cosmopolitan may contain recipients from all these environments. By simply selecting Cosmopolitan from the address book and sending your e-mail message, you are giving your messaging system a huge job to accomplish. To get your message to all those recipients, the SMTP transport works in conjunction with the MTA. The SMTP service is responsible for delivery to local recipients as well as recipients on remote Exchange 2000 servers and the Internet. The MTA, on the other hand, takes care of the routing to foreign messaging systems.
Several SMTP components are involved in message handling and transfer (see Figure 3.13). The store driver, for instance, allows the SMTP transport to directly interact with the Information Store. As soon as the Information Store indicates to the store that new mail has arrived, the store driver informs the advanced queuing engine that a message must be routed. After parsing the message header, the engine passes the message to the categorizer, possibly to custom event sinks, and to the message router if the message needs to be transferred to remote SMTP-based systems. Each of these components processes the message and passes it back to the queuing engine.
The advanced queuing engine is the central control station of the entire SMTP-based message handling process in Exchange 2000 Server.
Exchange 2000 Server handles messages as follows:
Alternatively:
In both cases:
Figure 3.13 Exchange 2000 Server message handling
Each recipient may require specific message handling. For instance, a message may be addressed to a local recipient, a recipient on another Exchange 2000 server, and a recipient on the Internet. Consequently, multiple copies of the same message must be generated; one copy must be delivered locally, one needs to be transferred across the intranet to the remote Exchange 2000 server, and one copy needs to go to the Internet domain. It is the task of the categorizer to classify each recipient and create multiple message copies if required.
The Exchange 2000 Categorizer performs the following steps:
The Exchange 2000 Categorizer is implemented in PHATCAT.DLL, which resides in the \Program Files\Exchsrvr\Bin directory. You can read more about the SMTP service in Chapter 15, "SMTP Transport Configuration."