Lesson 2: Communication Between Essential Server Components

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:

  • Describe the communication between Outlook 2000 and the components running on the server.
  • Describe the communication between the Exchange System Manager utility and the components running on the server.
  • Describe the communication between the most important components involved in message processing.
  • Describe the communication between the essential and additional components.
  • Understand the Exchange 2000 Server message-handling process.

Estimated time to complete this lesson: 90 minutes


Interprocess Communication Mechanisms

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."

click to view at full size

Figure 3.5 Essential components and interprocess communication mechanisms

Windows Sockets

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:

  • Familiar networking API to programmers using Windows or UNIX
  • Binary compatibility between Windows-based TCP/IP stacks and utilities from different vendors
  • Support of connection-oriented and connectionless protocols (such as TCP and User Datagram Protocol [UDP])
  • No protocol overhead added to the data packet (NetBIOS interface and mapping layers are not required)
  • Supported on workstations running only TCP/IP without NetBIOS support

If you are interested in further information about Windows Sockets, refer to the Microsoft Software Development Kit and the Microsoft Developer Network.

Remote Procedure Calls

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:

  • RPC client and server components are tightly coupled and communication is synchronous (such as the client program execution stops until the server function returns results).
  • Because of their synchronous nature, RPCs require a reliable, high-speed network connection.
  • RPCs involve further interfaces for network communication, such as Windows Sockets, and add significant overhead to the network packet.

Shared Memory, Files, and E-Mail Messages

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.

Clients and Administrative Interfaces

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.

Messaging Clients

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."

Administrative Tools

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.

click to view at full size

Figure 3.6 Outlook and Exchange System Manager communication

Active Directory Directory Service

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."

Information Store

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."

System Attendant

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).

Transport Components

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."

Additional Components

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."

Exercise 2: Communication Partners of the Exchange System Manager

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.

Prerequisites

  • Log on as Administrator to BLUESKY-SRV1.

To verify the Exchange System Manager communication

  1. Click Start, select Run, and in the Run dialog box, type cmd, then click OK to open the command prompt window.
  2. Type the command iisreset /stop, and press Enter to stop all IIS services.
  3. Type the command net stop msexchangesa /y, and press Enter to stop all Exchange 2000 Server services.
  4. Click Start, point to Programs, point to Microsoft Exchange, and then select System Manager to start the Exchange System Manager.

    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.

  5. In the console tree, iterate through the nodes under Global Settings and Recipients. You can select all containers without problems because Active Directory provides this information.
  6. Open the Servers container, then BLUESKY-SRV1, then Protocols, then SMTP, for instance, and then open the container Default SMTP Virtual Server. A red indicator will inform you that communication with IIS is not possible at this time.
  7. Under Default SMTP Virtual Server, select Current Sessions. In the SMTP Configuration dialog box, informing you that the SMTP service is not running, click OK.
  8. Under Default SMTP Virtual Server, select Queues. An Exchange System Manager warning pops up informing you that the Queue Viewer is unable to retrieve an interface to the queues.
  9. Under Protocols, select the container First Storage Group. In the Exchange System Manager dialog box, informing you that the Microsoft Exchange Information Store service needs to be running, click OK. You will be unable to examine the status of mailbox and public folder resources on this server until you restart the Information Store.
  10. Attempt to open the Public Folders container under Folders, and note the Exchange System Manager error message that an operation failed. Without an active Microsoft Web Storage System, you cannot configure public folder resources; click OK.
  11. Right-click the node named BLUESKY-SRV1 and choose Properties to display yet another Exchange System Manager warning message informing you that the communication with the SA service is impossible. Click OK and, in the BLUESKY-SRV1 Properties dialog box, note that the field Domain Controller Used By Services On This Server remains empty. Click OK to close the Properties dialog box.
  12. Close the Exchange System Manager, switch back to the command prompt, type iisreset /start to start all services again, and then optionally repeat Steps 4 to 11.

    click to view at full size

    Figure 3.7 Error messages in Exchange System Manager

Exercise Summary

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.

Component-to-Component Communication

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.

click to view at full size

Figure 3.8 Exchange 2000 Server components and Active Directory

Active Directory Directory Service

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.

click to view at full size

Figure 3.9 Caching Active Directory information

System Attendant

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:

  • Active Directory. The SA communicates with Active Directory to build routing tables and generate proxy e-mail addresses for newly created recipient objects. The DSProxy component, which forwards directory lookups on behalf of MAPI-based clients, is also a component of the SA service.
  • Information Store. The SA service communicates with the Information Store whenever you configure a monitor to check the conditions of server services and messaging links. The SA owns a hidden mailbox in the Information Store to send the monitor messages. This mailbox is also used for KMS-related messages during the process of enabling advanced security as explained in Chapter 20, "Microsoft Exchange 2000 Server Maintenance and Troubleshooting."

    click to view at full size

    Figure 3.10 Communication initiated by the SA

  • IIS process. The SA service communicates with the IIS to update the IIS metabase. The SA retrieves the information from Active Directory and hands it over to the IIS Admin Service. Internet information services retrieve their information from the metabase, as explained previously in this lesson under "Internet Information Services for Microsoft Exchange 2000 Server."
  • KMS. The SA service performs important tasks in the background if the KMS has been installed in your organization. The SA receives the requests of users in the form of e-mail messages from the Information Store to enable the advanced security that the administrator has configured for them. First the SA has to "unwrap" the e-mail messages to retrieve the requests. It then communicates with the Exchange KMS to take over the users' security keys and X.509 certificates. KMS is covered in Chapter 19, "Implementing Advanced Security."

Information Store

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:

  • Active Directory. The Information Store communicates with Active Directory to retrieve security-related information (such as access permissions) and information about the configuration of its resources.
  • Connectors for Lotus cc:Mail, Lotus Notes, and Novell GroupWise. The Information Store communicates with gateways to foreign systems to announce the presence of new mail awaiting transfer in message queues.
  • MAPI-based clients. The Information Store communicates with MAPI-based clients to notify them that new messages have arrived.
  • MTA. The Information Store communicates with the MTA to announce the presence of new mail awaiting transfer through X.400 connectors or connectors to foreign messaging systems.

    click to view at full size

    Figure 3.11 Communication initiated by the Information Store

  • SA. The Information Store communicates with the SA to request the creation of and provide information for tracking log files to be used by the message tracking center. The Information Store also submits link monitor test messages and advanced security-related messages of MAPI-based clients to the SA.
  • SMTP transport. The Information Store communicates with the SMTP transport to submit messages for delivery. The SMTP transport also expands distribution lists to perform routing for every recipient.
  • Third-party gateways and connectors. The Information Store communicates with third-party gateways in much the same way as with the connectors for Lotus cc:Mail, Lotus Notes, and Novell GroupWise to announce the presence of new mail awaiting transfer.

SMTP Transport Service

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:

  • Active Directory. The SMTP service communicates with Active Directory to look up address information to resolve recipients and expand distribution groups.
  • Information Store. The SMTP service communicates with the Information Store to obtain messages from and place messages into the Information Store.
  • Remote SMTP services. The SMTP service communicates with other SMTP services over the network to transfer e-mail messages.

MTA and Messaging Gateways

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.

click to view at full size

Figure 3.12 Communication initiated by the SMTP transport

Other Components

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

Exchange 2000 Server Message Handling

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.

SMTP Transport and the MTA

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.

SMTP Transport Components

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.

Message Handling

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:

  1. A remote SMTP system connects to the local SMTP service and transfers a message.
  2. The SMTP service creates a temporary file for each incoming message on the file system (in the \Program Files\Exchsrvr\Mailroot directory) and streams the message into this file. After that, it confirms message reception and informs the advanced queuing engine that a new message requires processing.

Alternatively:

  1. Outlook users on the local server send messages, which are placed in the information store first. Figure 3.13 also shows a path for messages that arrive through the MTA (for example, via an X.400 connector) that are directly transferred to the Information Store service.
  2. For each message, the message store driver informs the advanced queuing engine that a new message requires processing.

In both cases:

  1. The advanced queuing engine needs to pass the incoming messages to the categorizer to determine how to process the messages further. For this reason, it places the messages in a specific queue known as the precategorizer queue.
  2. The categorizer takes the messages from the precategorizer queue, processes them, and then places individual message copies in the appropriate delivery queues for delivery through the SMTP service (destination-domain queues) or the Information Store (local delivery queue).
  3. The advanced queuing engine now allows any custom event sinks installed on the server to process the message.
  4. Messages in the destination-domain queues are passed to the routing engine, which returns a next-hop identifier for each message destination. The next-hop identifier informs the SMTP service where to transfer the message next.
  5. The store driver informs the Information Store and the Information Store retrieves the messages from the local delivery queue to deliver them to local recipients or the MTA for further processing.
  6. The SMTP service transfers the messages from the destination-domain queues to the next hop in the routing infrastructure.

click to view at full size

Figure 3.13 Exchange 2000 Server message handling

Message Categorization

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:

  1. Attempts to resolve the originator address using Active Directory.
  2. Expands any distribution groups to determine all recipients, provided that local group expansion is allowed on this server. If expansion is prohibited for a group, the Categorizer analyzes the group's Home-VSI (Virtual Server Instance) attribute to determine the expansion server.
  3. Resolves all recipients that exist in Active Directory and marks the remaining recipients as unknown.
  4. Checks if delivery restrictions and other limits exist for the originator and recipients. Users with restrictions are marked for individual processing according to the restrictions.
  5. Creates multiple copies of the message if recipients require separate processing, such as local and remote recipients, or recipients with restrictions.
  6. Places the individual copies of the message in the appropriate delivery queues (destination-domain queues and local delivery queue).
  7. Informs the advanced queuing engine that the message categorization is complete.

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."



MCSE Training Kit Exam 70-224(c) Microsoft Exchange 2000 Server Implementation and Administration
MCSE Training Kit Exam 70-224(c) Microsoft Exchange 2000 Server Implementation and Administration
ISBN: N/A
EAN: N/A
Year: 2001
Pages: 186

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net