Exchange 2007 introduces a role-based administration model. Depending on your organization's requirements, you can deploy the server roles on separate hardware. Also, the roles can be combined on hardware. The transport and routing functionality in Exchange 2007 is provided by the Hub Transport server role and the Edge Transport server role.

Hub Transport server role   The Hub Transport server role provides intra-organizational message transport. Every message that is sent and received in an Exchange 2007 organization is handled by the Hub Transport server. This makes sure that no messages bypass the transport rules and journaling policies that enable compliance with corporate and regulatory policies. For more information about the Hub Transport server role, see Hub Transport Server Role: Overview.

Edge Transport server role   The Edge Transport server is deployed in your organization's perimeter network as a stand-alone server or as a member of a perimeter domain. Designed to minimize the attack surface, the Edge Transport server handles all Internet-facing mail flow. In addition to performing Simple Mail Transfer Protocol (SMTP) relay and smart host services for the Exchange organization, the Edge Transport server provides additional layers of message protection through agents that perform antivirus and anti-spam processing. 

The computer that has the Edge Transport server role installed doesn't typically have access to the Active Directory directory service. The Edge Transport server stores all configuration and recipient information in the Active Directory Application Mode (ADAM) directory service. To perform recipient lookup and safelist aggregation tasks, the Edge Transport server requires data that resides in Active Directory. You can subscribe an Edge Transport server to an Active Directory site to enable the Hub Transport servers in that site to synchronize recipient and configuration data from Active Directory to the ADAM instance on the Edge Transport server. The Microsoft Exchange EdgeSync service that is running on the Hub Transport servers establishes one-way replication and copies the recipient information that the Edge Transport server needs to perform recipient lookup and safelist aggregation. The configuration information that the Edge Transport server needs to configure the Send connectors that establish mail flow between the Internet and the Exchange organization is also replicated. The Microsoft Exchange EdgeSync service performs scheduled updates so that the information in ADAM remains current. For more information about the Edge Transport server role, see Edge Transport Server Role: Overview.

In Exchange 2007, the SMTP protocol is provided by the Microsoft Exchange Transport service (MSExchangeTransport.exe). In earlier versions of Exchange, the SMTP protocol service was provided by Internet Information Services (IIS). The SMTP stack is the core infrastructure of Exchange. Without it, you can't send and receive e-mail messages. Exchange 2007 provides a stable transport that addresses the most common security risks. By rewriting the transport stack in managed code and running as the Network Service account, we have reduced the risks that are associated with denial of service attacks. This new SMTP transport stack is a required part of Exchange. It eliminates the dependency on IIS and reduces the work that is required to help secure a server for perimeter network deployment.

The Microsoft Exchange Transport service controls every component of message processing, from SMTP IN to SMTP OUT. A series of configurable SMTP Receive agents are triggered at various SMTP events. The Microsoft Exchange Transport service enables these agents to process messages as they pass through SMTP transport, performing anti-spam, antivirus, and other tasks before messages are submitted to the categorizer. During categorization, name resolution, routing resolution, and content conversion occur. Additional agents are triggered at this point of the transport pipeline. These agents provide the Transport Policy and Compliance features that enable an administrator to determine how a message is handled and archived.

Exchange 2007 uses the Active Directory site topology to determine how messages are transported in the organization. This section describes changes related to Active Directory.

Active Directory sites and IP site links   Exchange 2007 takes advantage of the existing Active Directory site topology to eliminate the need to define a separate Exchange routing topology. The Active Directory IP site links and the costs associated with them are used to calculate the least cost route between Hub Transport servers in different Active Directory sites. Each Active Directory site that contains one or more Exchange 2007 Mailbox servers must also have at least one Hub Transport server. The Hub Transport server uses the Active Directory Topology service to retrieve the Exchange organization's configuration information and computes an implicit intra-organizational Send connector that is used when transporting messages from site to site. This topology is only updated when configuration changes occur. The result is minimized traffic related to Exchange. 

No more link state   Unlike earlier versions of Exchange, Exchange 2007 does not use a link state routing table and does not try to calculate an alternative route when a connection is unavailable. This eliminates link state communication between Exchange servers and creates a more deterministic routing topology.

Direct relay   Exchange 2007 relies on the underlying network infrastructure to transport a message. In the Exchange 2007 organization, messages are relayed directly from the source server to the target server, reducing the number of hops a message takes during delivery. When routing resolution occurs, the name and IP address of the destination server is resolved. If multiple IP site links exist between the source and destination, the route calculation is used to determine the optimal point for message bifurcation and the point at which to queue should delivery be unsuccessful. With direct relay, intermediate Hub transport servers don't process messages.

Hub sites   For administrators who require more control over Exchange routing, we have provided features that enable you to modify the default direct relay behavior. You can specify that an Active Directory site is a hub site. A hub site is an Active Directory site through which all messages to be relayed through the Hub Transport servers are forced to pass. The hub site must exist along the least cost routing path between the source and target servers. This configuration is especially useful for network environments that have firewalls between sites that may prevent successful direct relay.

Site link cost override   For even more control over message routing behavior, you can assign an Exchange-specific cost to Active Directory IP site links. By default, Exchange calculates the least cost route between Active Directory sites by using the costs assigned to those links for the purposes of determining Active Directory replication topology. If these costs don't provide the optimal Exchange routing behavior, you can use cmdlets in the Exchange Management Shell to set an Exchange-specific value to the IP site link. 

Queue at point of failure   In earlier versions of Exchange, when a target server was unreachable, the down connector state was propagated throughout the Exchange organization by link state updates, and an alternative route was calculated. In Exchange 2007, when a message can't be relayed directly to the target server because of network problems, no alternative route is calculated. The message queues on a Hub Transport server in the closest reachable site to the point of failure. Using the least cost routing path calculated at startup, message delivery backs up along the path of intermediate sites until delivery to a Hub Transport server is achieved. When the network problem is resolved, or configuration changes update the routing table, message delivery resumes to the target site. This behavior helps administrators to better determine the source of network problems.

Delayed fan-out   A message sent to more than one recipient must bifurcate, or split, to be delivered to more than one destination. Exchange 2007 delays this bifurcation until it reaches a fork in the routing paths. By delaying bifurcation of the message, bandwidth consumption is reduced.

Exchange 2007 requires connectors to send and receive e-mail messages. You don't have to configure connectors to send and receive e-mail internally. The connectors between Hub Transport servers in the organization are implicit and are computed by using the IP site link information that is stored in Active Directory. To send and receive e-mail outside the Exchange organization, Send connectors and Receive connectors are required.

When you install the Hub Transport server role or the Edge Transport server role, default Receive connectors are created. Unless you want to dedicate a Receive connector to a specific domain space, no additional Receive connector configuration is required. Send connectors from the Hub Transport server to the Edge Transport server, from the Edge Transport server to the Hub Transport server, and from the Edge Transport server to the Internet are not created automatically in a default installation. You can manually create these Send connectors, or you can subscribe an Edge Transport server to an Active Directory site. When an Edge Transport server is subscribed to an Active Directory site, the following connectors are created by the Microsoft Exchange EdgeSync service:

• An implicit Send connector from the Hub Transport servers that are in the same forest to the Edge Transport server.
  
• A Send connector from the Edge Transport server to the Hub Transport servers in the Active Directory site to which the Edge Transport server is subscribed.
  
• A Send connector from the Edge Transport server to the Internet.
  

All other connectors are created explicitly by the administrator. You may have to create additional connectors if your messaging environment includes multiple forests, multiple messaging systems, or you want to provide different default message settings for a particular domain. To ease configuration of SMTP connectors for complex environments, you can select a usage type when you create the connector. The usage type determines the default permission sets that are assigned on the connector and grants those permissions to well-known security identifiers (SID).

Note:
Any Receive connector that is responsible for accepting connections from Edge Transport servers or other Hub Transport servers must have the Exchange Server authentication method assigned to it. The Exchange Server authentication method is the default authentication method when you create a new Receive connector that has the Internal usage type.

Remote domains are any SMTP domains that are external to the Exchange organization. By configuring remote domain entries, you can globally manage the out-of-office message settings and message format settings on a per domain basis. Remote domain settings already exist in Exchange Server 2003, under the Internet Message Formats subfolder of the Global Settings folder in Exchange System Manager. In Exchange 2007, you can suppress meeting forward notifications in addition to the existing settings that enable or disable automatic replies, forwards, delivery and non-delivery reports, and control message format. The remote domain settings also let you control whether out-of-office messages are sent to remote domains and which types of out-of-office messages are sent to remote domains. In Exchange 2003 and Microsoft Office Outlook 2003, only one type of out-of-office message can be configured. By using Exchange 2007 and Outlook 2007, you can use separate internal and external out-of-office messages.

Accepted domains help you easily configure both your authoritative domains and the domains that you allow to relay through the Exchange system. An accepted domain is any SMTP namespace for which an Exchange organization sends or receives e-mail. Accepted domains include those domains for which the Exchange organization is authoritative. An Exchange organization is authoritative when it handles mail delivery for recipients in the accepted domain. Accepted domains also include domains for which the Exchange organization receives mail and then relays it to an e-mail server that is outside the Active Directory forest for delivery to the recipient. An accepted domain can be configured as an internal relay domain. In this case, messages are first received and processed by the Edge Transport server and then relayed to the Hub Transport servers. The Hub Transport servers then process the messages and relay them to the destination domain. You can also configure an external relay domain. In this case, the messages are received and processed by the Edge Transport server, and then relayed to the e-mail system of the destination domain.

For more information, see the following topics:

• Planning for Hub Transport Servers
  
• Planning for Edge Transport Servers
  
• Planning to Use Active Directory Sites for Routing Mail
  
• Microsoft Exchange Server 2007 Transport Architecture Diagrams
  
• Transport Architecture
  
• Planning for Coexistence
  
• Managing Connectors
  
• Managing Accepted Domains
  
• Managing Remote Domains