Transport Dependencies for Exchange Server 2003

 

To function properly, Simple Message Transfer Protocol (SMTP) depends on the following components:

• Internet Information Services (IIS), a feature in Microsoft® Windows Server™ 2003

• Microsoft Active Directory® directory service

• Domain Name System (DNS)

• Recipient policies

• Recipient update service

• Directory service to metabase service (DS2MB)

This topic provides detailed information about each of these components and how they interact with SMTP.

Internet Information Services

Internet Information Services (IIS) provides a framework process for Internet services such as the World Wide Web Publishing Service (W3SVC), SMTP service (SMTPSVC), and Network News Transfer Protocol service (NntpSvc). Do not confuse IIS with Web services because several other services, such as SMTP, depend on IIS to function.

The installation of IIS provides:

• The framework process known as the IIS Admin Service (IISADMIN), which allows for the administration of services through the IIS snap-in.

• Administrative consoles or snap-ins for the Microsoft Management Console (MMC).

• The IIS metabase, which is the configuration repository for IIS.

• Common files, which are shared libraries that provide socket connection pooling, registration, and management of these Internet services.

Microsoft Exchange 2000 Server and Exchange Server 2003 setup requires that the World Wide Web Publishing Service, SMTP service, and NNTP service be installed. This prerequisite ensures that all the necessary components are installed prior to the installation of Exchange. Exchange leverages the core SMTP service through an event infrastructure. (For more information about event infrastructures, see the MSDN® Web site.) After Exchange is installed, the SMTP service is dependent only on the IIS Admin Service. You can disable the World Wide Web Publishing Service without affecting the SMTP service; however, you cannot use the Add/Remove Windows Component option in Add or Remove Programs to disable the IIS Admin Service or to remove the IIS component entirely.

Installing IIS creates several virtual directories under the World Wide Web Publishing Service that are not required for any Exchange component, including Microsoft Outlook® Web Access. To help secure IIS, Microsoft provides the following tools:

• URLScan version 2.5 for Windows Server 2003

  URLScan version 2.5 is a security tool that restricts the types of HTTP requests that IIS will process. To increase security on your server that is running Windows Server 2003, run URLScan. You can download URLScan from the Microsoft Download Center. For more information about URLScan, see Microsoft Knowledge Base article 823175, "Fine-Tuning and Known Issues When You Use the Urlscan Utility in an Exchange 2003 Environment."

• IIS Lockdown Wizard for Windows® 2000 Server

  IIS Lockdown Wizard is a security tool that removes unnecessary virtual directories, enhances file security, and processes real-time URL requests against user-defined configurations. To increase protection in the unlikely event that the World Wide Web Publishing Service is started in error, if you are running Exchange on Windows 2000 servers, you should deploy the IIS Lockdown Wizard on every Exchange server and domain controller. You can download the IIS Lockdown Wizard from the Microsoft Download Center. For more information about using the IIS Lockdown Wizard, see "Using IIS Lockdown Wizard on Windows 2000 Server" in Securing Your Infrastructure.

Active Directory

Exchange Server 2003 is tightly integrated with Windows 2000 and Windows Server 2003 and with Active Directory. Exchange Server 2003 stores all of its configuration information in Active Directory, including information about recipient policies, routing and connector configuration, SMTP virtual server configuration, user mailboxes, and much more. However, SMTP reads its settings from the IIS metabase. Therefore, to supply IIS with the information that it needs for SMTP functionality, Microsoft Exchange System Attendant (a service in the Exchange Default Services) replicates the configuration information from Active Directory to the IIS metabase.

Additionally, routing depends on Active Directory for information about the current routing topology. On startup, each Exchange server reads information from Active Directory about the routing topology, such as the existing connector configuration, routing groups, and local and remote bridgehead servers. If an object such as a routing group or connector is corrupt, it is not read from Active Directory. When this occurs, servers then have an incomplete topology view. Monitor for event 929 in the Event Viewer to detect this situation. For more information about Event Viewer, see How to View the Application Log in Event Viewer and How to View the System Log in Event Viewer.

After startup, the routing group master (the server that is responsible for maintaining and communicating information about the routing topology in its routing group) in each routing group registers with Active Directory and is notified by the configuration domain controller of major routing version changes. When a routing group master receives an update to the routing topology, it sends the updated information to all member servers in its routing group and notifies all bridgehead servers in remote routing groups. These bridgehead servers then notify their respective routing group masters. Additionally, the categorizer, an internal transport component, accesses a cached version of information in Active Directory using DSAccess or by querying Active Directory directly using the LDAP queries. For more information about the categorizer, see Understanding Internal Transport Components.

Domain Name System (DNS)

Although a complete analysis and discussion of DNS is beyond the scope of this guide, this section provides information about the relationship between DNS and SMTP in Exchange. Because Exchange Server 2003 relies on DNS for name resolution, DNS plays a crucial role in Internet mail flow.

SMTP depends on DNS to determine the Internet Protocol (IP) address of its next internal or external destination server. Generally, internal DNS names are not published on the Internet. Therefore, SMTP must be able to contact a DNS server that can resolve external DNS names to send Internet mail, as well as a DNS server that can resolve internal DNS names for delivery within the organization. For information about how to configure DNS for sending and receiving mail, see Verifying DNS Design and Configuration.

The following sections provide a general overview of DNS queries and an explanation of the role that DNS plays in sending and receiving mail.

How External DNS Queries Work

When a DNS client needs to resolve the name of a server, it queries the DNS servers. Each query that the client sends essentially asks the DNS server to provide the information. The client specifies the query type, which can either indicate a resource record by type or a specialized type of query operation. For example, to find SMTP mail servers from the Internet, specify the query type MX (mail exchanger resource record).

For example, the name that is specified could be an external domain, such as example.microsoft.com., and the query type that is specified to look for could be an MX record by that name. Think of a DNS query as a client asking a server a two-part question: First, "Do you have any MX resource records for a domain named 'example.microsoft.com.'?" followed by "If so, can you resolve this MX record to an A (host) record and resolve its IP address?" When the client receives an answer from the server, it reads and interprets the MX record and gets the A record, thereby resolving the computer's IP address.

Querying a DNS Server

When the DNS server receives a query, the server first checks to see if it can answer the query authoritatively, based on MX record information that is contained in a locally configured zone on the server. If the queried name matches a corresponding MX record in the local zone, the server answers authoritatively and uses this information to resolve the queried name.

If no zone information exists for the queried name, the server then checks to see if it can resolve the name by using locally cached information from previous queries. If a match is found, the server answers with this information. Again, if the preferred server can provide the requesting client with a positive matched response from its cache, the query is completed.

If no zone or cached information exists for the queried name, the query process uses recursion to fully resolve the name. Recursion is the process in which a DNS server queries other DNS servers on behalf of the requesting client to fully resolve the name, and then sends an answer back to the client. By default, the DNS Client service requires that the server use recursion to fully resolve names on behalf of the client before returning an answer. In most cases, the DNS server is configured (by default) to support the recursion process.

How DNS resolves a query for an MX record and finds the IP address

For more information about DNS, see the Windows 2000 or Windows Server 2003 Help.

Role of DNS in Sending and Receiving Internal Mail

Windows 2000 and Windows Server 2003 both register the fully qualified domain name (FQDN) of each server with dynamic DNS. Your Exchange server and your SMTP virtual servers also use the FQDN. If you change the FQDN that your SMTP virtual server uses, be sure to add a record for this FQDN into DNS manually.

Role of DNS in Receiving Internet Mail   To receive Internet mail, your external DNS servers must have an MX record pointing to an A record that contains the IP address of your mail servers, or a server that can forward mail to your mail servers. To ensure that your MX records are configured correctly, you can use the Nslookup tool. To verify that your server is accessible on port 25 to other servers on the Internet, you can use telnet.

For more information about Nslookup, see How to Use Nslookup to Verify DNS Configuration.

For more information about Telnet, see How to Use Telnet to Ensure Internet Accessibility.

• Role of DNS in Sending Internet Mail   Exchange Server uses one of two methods for sending Internet mail:

  • Uses DNS for external name resolution.

  • Forwards mail to a smart host that assumes responsibility for mail delivery and name resolution.

  To send Internet mail by using DNS rather than by forwarding mail to a smart host, the Exchange server resolves the receiving domain and IP address of the recipient's SMTP server. The server then uses SMTP to establish a connection with the recipient's SMTP server and deliver the mail.

Using DNS to Send Internet Mail

When you use DNS, the most important thing to remember is that all servers in the DNS search order must be able to resolve external domains (also referred to as Internet domains). Because it is likely you will use internal servers for internal name resolution, you have three possible setup options:

• Set up your internal DNS servers as caching servers that use root hints for Internet domains.   Root hints point to DNS servers that are authoritative for the zone containing the domain root and top-level domains. Root hints help DNS servers locate the correct server to resolve a domain name.

• Set up the internal DNS servers with forwarders to external DNS servers.   A forwarder is a DNS server that is designated by an internal server to be used for resolving external DNS names. (To set up a forwarder, in the DNS console, select the DNS server. On the Action menu, click Properties, click the Forwarders tab, and then select the Enable forwarders check box. Add IP addresses for other DNS servers that act as forwarders for this server.)

• Configure the SMTP service to use external DNS servers.   To configure an external DNS server, right-click your SMTP virtual server, click Properties, and then click the Delivery tab. Click Advanced, and then click Configure to set up an external DNS server.

For example, consider that an internal client in the domain example.com sends a message to a recipient in the remote domain contoso.com. To route the message, Exchange uses DNS to resolve the IP address of the SMTP server in the Contoso domain and deliver the message to the recipient at contoso.com.

How Exchange uses DNS to resolve external IP addresses

The following sequence also explains how Exchange uses DNS to resolve an external IP address:

1. After the SMTP server in the domain example.com receives the message that is destined for the recipient at contoso.com, the SMTP virtual server contacts the appropriate DNS server and sends an MX query for the external domain of contoso.com.

2. The DNS server locates an A record that is associated with the MX record for contoso.com, and then uses that A record to determine the IP address. For more information about how the DNS server locates the A record, see "Querying a DNS Server" earlier in this chapter.

3. The DNS server returns the IP address of 172.234.234.23 for the mail server in contoso.com to the SMTP virtual server.

4. The SMTP virtual server opens a connection on port 25 of the remote SMTP server at the IP address of 172.234.234.23 and delivers the mail.

Forwarding Internet Mail to a Smart Host

A smart host is a server or mail process that handles the delivery of Internet mail. A smart host does not have to be an Exchange server—it can be any SMTP process or server that takes the responsibility of delivering mail, either by sending it to another SMTP server or by using DNS to deliver the mail directly. In scenarios where there is a persistent connection to the Internet, a smart host is not required. However, often the smart host is an antivirus scanner or a Windows 2000 or Windows Server 2003 SMTP service that is in a perimeter network.

Using a smart host for DNS resolution is similar to using a DNS server, except that the smart host assumes the responsibility of resolving the IP address and sending the mail.

For more information about how to configure the Windows 2000 SMTP service in a perimeter network, see Microsoft Knowledge Base article 293800, "XCON: How to Set Up Windows 2000 as a SMTP Relay Server or Smart Host."

For more information about how to set up Exchange behind Microsoft Internet Security and Acceleration (ISA) Server, see the technical article Microsoft ISA Server 2000 – Configuring and Securing Exchange 2000 Server and Clients.

Recipient Policies

A recipient policy establishes the default e-mail addresses that use a specific protocol (such as SMTP) for a set of users. E-mail addresses are used to define the valid formats for addressing inbound e-mail messages to the Exchange system. The default recipient policy sets the mail domain for which the virtual server accepts incoming e-mail messages. It specifies the default SMTP and X.400 addresses for all Exchange Server 2003-based, mailbox-enabled objects.

Any SMTP domains that are specified in the recipient policies are replicated into the IIS metabase and set as authoritative local domains. As a result, SMTP accepts inbound mail for these domains. The only time that an SMTP address is not considered local is when you clear the This Exchange Organization is responsible for all mail delivery to this address check box in SMTP Address Properties while adding the address to the recipient policy.

A recipient policy can contain more than one e-mail address for a specified protocol (such as SMTP or X.400). For example, if all users in your Exchange organization have an external e-mail address of @example.com, but you want all your Seattle users to have two external mail addresses—one with @example.com, and another with an e-mail address of @seattle.example.com—you can set up a recipient policy for all users in your Seattle office and add an additional address of @seattle.example.com. To achieve this result, perform the following procedure.

For more information about Recipient Policies, see Connecting Exchange to the Internet and "Managing Recipients and Recipient Policies in Exchange Server 2003" in the Exchange Server 2003 Administration Guide.

Recipient Update Service

The Recipient Update Service is part of the Microsoft Exchange System Attendant service (MSExchangeSA) that monitors Active Directory for new recipients and writes the appropriate e-mail address and other Exchange properties for the user in Active Directory. The Recipient Update service uses the information that is defined in recipient policies to update Active Directory with the correct user information for the recipients that are included in each recipient policy.

You must have a Recipient Update Service for each domain in your organization. In large organizations, multiple recipient update services are recommended. Consider having a recipient update service for each Active Directory site. Otherwise, replication of new recipients and their updated information can take up to thirty minutes in a simple replication topology. Until this replication is complete, these recipients are unable to send or receive mail.

Directory Service to Metabase Service

DS2MB service (directory service to metabase service), a component of the Exchange System Attendant service, is responsible for propagating information from Active Directory into the IIS metabase. DS2MB is critical to the operation of SMTP, Internet Message Access Protocol 4 (IMAP4), Post Office Protocol 3 (POP3), and the World Wide Web Publishing Service (W3SVC), which is the service for Microsoft Outlook® Web Access.

DS2MB replicates the following information from Active Directory into the IIS metabase:

• SMTP virtual servers and most of their configurable properties.

• SMTP connector address spaces so that the metabase for the advanced queuing engine routes messages properly.

• Authoritative domains from the recipient policies (replicated to the SMTPSVC/x/Domain subkey and used by the advanced queuing engine).

At startup, DS2MB checks all objects that it has replicated in the past, as well as for any changes since the last replication. If DS2MB detects that no replication has previously occurred, it initializes and replicates all objects.

After startup, DS2MB registers with the configuration domain controller so that the domain controller notifies DS2MB if any changes are made to the Exchange configuration and deleted objects container. As a result, almost as soon as a change is replicated to the configuration domain controller, DS2MB replicates that object to the metabase.

If DS2MB experiences problems, it logs an event with an ID of 1040. If this occurs, increase diagnostic logging to level 5 for MSExchangeMU, the metabase update service. You can turn on diagnostic logging in Exchange System Manager by right-clicking your Exchange server, clicking Properties, clicking the Diagnostic Logging tab, and selecting MSExchangeMU under Services. For more information about this procedure, see How to Modify Logging Settings for MSExchangeTransport.