Planning the Exchange Server 2010 Infrastructure

Objective 1.2: Design Message Routing

Designing a message routing infrastructure involves determining where you need to put transport servers to effectively route messages inside and outside your organization. Not only do you need to decide where to put the transport servers, but you also need to ensure that these servers are sufficiently capable of handling the message traffic generated by your organization. Your design needs to include the mail domains that your organization will accept mail for, how to handle the routing of email to third-party messaging systems that might be used within your environment, and how messages will be forwarded from your organizations to destinations on the Internet. In this objective, you’ll learn about message routing design. In Chapter 2 you’ll learn about how to implement message routing with Edge Transport and Hub Transport servers.

Design Message Transport

At the most basic level, when designing Exchange transport server deployment you need to ensure that you place at least one Hub Transport server in each Active Directory site that has an Exchange Mailbox server. When designing a traditional Exchange 2010 deployment, you will also place at least once Edge Transport server on a perimeter network that is adjacent to an Active Directory site with a Hub Transport server.

Messages are routed through an Exchange 2010 organization in the following general way:

• Internal Message Routing When a message arrives at a Hub Transport server, processes within the Hub Transport server determine the Active Directory site location of the mailbox server that hosts the recipient’s mailbox. If the destination Mailbox server is in another Active Directory site, the message is forwarded to the Hub Transport server in that site. If the destination Mailbox server is in the local Active Directory site, the message is queued for local delivery and delivered to the destination mailbox store using an Exchange remote procedure call (RPC).

• External Message Routing When a message arrives at a Hub Transport server and the Hub Transport server determines that the recipient does not have a mailbox within the Exchange organization, the Hub Transport server attempts to select a Send connector through which to send the message. If the source server for that Send connector is in another Active Directory site, the Hub Transport server forwards the message to the Hub Transport server in that site. Through the configuration of Send connectors, you can also allow messages to be routed to other messaging systems within your organization. For example, if you have a cross-forest Exchange topology, you can configure a Send connector to route messages to the other internally hosted Exchange organization.

Modifying Default Message Routing Topology

If you don’t modify the initial configuration, when a Hub Transport server needs to deliver a message to a recipient whose mailbox is hosted on a mailbox server in another Active Directory site, that Hub Transport server will initiate a direct connection to a Hub Transport server in that site. For example, if a Hub Transport server in the Melbourne site needs to deliver a message to a mailbox server in the Darwin site, it will initiate a connection to a Hub Transport server in the Darwin site. Although the default routing topology, based on Active Directory site topology, is suitable for most organizations, you can modify it in the following ways:

• Configure hub sites.

• Configure Exchange-specific routing costs.

• Configure expansion servers for distribution groups.

Configure Hub Sites

You can configure one or more Active Directory sites as hub sites. For example, you might configure the Sydney site as a hub site for all of the other Active Directory sites in your organization’s Australian Exchange deployment. You should configure hub sites when your organization’s network topology does not support direct connections between Hub Transport servers in different sites. When a hub site lies on a least-cost routing path between a source and destination Hub Transport server, the Hub Transport server at the hub site processes the messages before relaying them to the destination server.

You configure an Active Directory site as an Exchange hub site by using the Set-AdSite cmdlet. For example, to set the Sydney site as a hub site, use the following command:

Set-ADSite Sydney -HubSiteEnabled $true

Configure Exchange-Specific Routing Costs

You can alter the default routing topology by setting an Exchange cost on an Active Directory IP site link. Any set Exchange costs override the existing Active Directory assigned site cost. Use site-link costs to ensure that the least cost routing path between two sites goes through a hub site. You use the Set-ADSiteLink cmdlet to configure an Exchange-specific cost for an Active Directory IP site link. For example, to set the Exchange-specific cost of 20 to the IP site link IPSiteLinkMELSYD, use this command:

Set-ADSiteLink -Identity IPSiteLinkMELSYD -ExchangeCost 20

To remove the Exchange specific site cost from the IP site link IPSiteLinkMELSYD, use the following command:

Set-ADSiteLink -Identity IPSiteLinkMELSYD -ExchangeCost $null

Configure Expansion Servers for Distribution Groups

When a message is sent to a distribution group, the first Hub Transport server that intercepts the message performs the distribution group expansion, working out how to route messages to each member of the distribution group. With large distribution groups, this can cause a substantial performance hit on the Hub Transport server, slowing down all message routing operations. An alternative to allowing any Hub Transport server to perform distribution group expansion is to configure distribution groups to use specific Hub Transport servers to perform this task. You configure a specific Hub Transport server as a distribution group expansion server by modifying the properties of individual distribution groups. You’ll learn more about configuring distribution groups in Chapter 2.

Transport Server Scalability

The simplest way to scale transport server performance is to add additional Hub transport servers at each Active Directory site. When you add additional Hub transport servers, messages route through each Hub transport server in a site in a load-balanced way. In theory, each Hub Transport server can queue a maximum of 500,000 messages. If your design calls for more than 500,000 messages to be queued in a single Active Directory site, you will need to add additional Hub Transport servers. Although the 500,000 figure represents the maximum number of messages that can be queued, most organizations will require a minimum inter-organizational delivery time frame for messages as a part of an SLA. You are more likely to have to add Hub Transport servers to ensure quick delivery than you are because you’ve reached the 500,000 message queue capacity.

Also remember that scalability is different from high availability. High availability involves adding additional servers to ensure that message routing continues in the event that a Hub Transport or Edge Transport server fails. You’ll learn more about High Availability for transport servers in Chapter 4, “Designing and Deploying Exchange Server 2010 Availability and Recovery.”

You can use several other technologies in your Exchange design to ensure that your transport server infrastructure isn’t overwhelmed by excessive traffic. These include message throttling and back pressure.

Message Throttling

Message throttling allows you to limit the number of messages and connections that an Exchange 2010 Hub or Edge Transport server will accept. These limits ensure that the system resources of the transport server are not overwhelmed, either accidentally or intentionally. You can configure message throttling options on the transport server itself, on individual Send connectors, and on individual Receive connectors.

You can configure the following message throttling options:

• Maximum concurrent mailbox deliveries This option determines the maximum number of delivery threads that a Hub Transport server can concurrently use to deliver messages to mailboxes. The default value is 20. This setting can be configured with the MaxConcurrentMailboxDeliveries parameter of the Set-TransportServer cmdlet.

• Maximum concurrent mailbox submissions This option determines the maximum number of delivery threads that a Hub Transport server can concurrently use to accept messages from mailboxes. The default value is 20. This setting can be configured with the MaxConcurrentMailboxSubmissions parameter of the Set-TransportServer cmdlet.

• Maximum connection rate per minute This option determines the maximum rate at which the Hub Transport or Edge Transport server will accept new inbound connections. The default value is 1200 connections per minute. This setting can be configured with the MaxConnectionRatePerMinute parameter of the Set-TransportServer cmdlet.

• Maximum outbound connections This option determines the maximum number of outbound connections that a Hub or Edge Transport server can have open concurrently. The default value is 1000. You can configure this setting with the MaxOutboundConnections parameter of the Set-TransportServer cmdlet.

• Maximum per domain outbound connections This option limits the number of connections that a transport server connected to the Internet—which will usually be an Edge Transport server but might in some cases be a Hub Transport server—can open to any individual remote domain. The default value is 20. You can configure this setting with the MaxPerDomainOutboundConnections parameter of the Set-TransportServer cmdlet.

• Pick up directory maximum messages per minute This option limits the message processing rate for the Replay and Pickup directories. These directories are polled every five seconds and the default settings allows for eight messages to be processed every five-second interval. You can configure this setting with the PickupDirectoryMax-MessagesPerMinute parameter of the Set-TransportServer cmdlet. This figure you enter when using this parameter is for a 60-second duration, so you need to divide it by 12 to determine the number of messages processed during the polling interval.

• Connection inactivity time out This option limits the maximum amount of time that an SMTP connection to a remote server will remain open while idle before closing. The default value is 10 minutes. You configure this option on Send connectors by using the ConnectionInactivityTimeOut parameter with the Set-SendConnector cmdlet.

• Connection time out This option limits the maximum amount of time that an SMTP connection from a remote server will remain open, even if it is in the process of transmitting data. The default value on Hub Transport servers is 10 minutes and the default value on Edge Transport servers is 5 minutes. You configure this option on Receive connectors by using the ConnectionTimeOut parameter with the Set-ReceiveConnector cmdlet.

• Maximum inbound connection This option limits the maximum number of concurrent inbound connections that the Receive connector will accept. The default is 5000. You configure this option on Receive connectors by using the MaxInboundConnection parameter with the Set-ReceiveConnector cmdlet.

• Maximum inbound connection percentage per source This option limits the maximum number of SMTP connections that a Receive connector will accept from a single source as a percentage of available remaining connections. The default value is 2 percent. You configure this option on Receive connectors by using the MaxInbound-ConnectionPErcentagePerSource parameter with the Set-ReceiveConnector cmdlet.

• Maximum inbound connection per source This option limits the maximum number of SMTP connections that a Receive connector will accept from a single source as a fixed value. The default value is 100. You configure this option on Receive connectors by using the MaxInboundConnectionPerSource parameter with the Set-ReceiveConnector cmdlet.

• Maximum Protocol errors This option limits the maximum number of SMTP protocol errors that can occur over an established connection before that connection is terminated. The default value is 5. You configure this option on Receive connectors by using the MaxProtocolErrors parameter with the Set-ReceiveConnector cmdlet.

• Tarpit Interval This option determines the delay that is used when SMTP communications patterns suggest a directory harvest attack or other unwelcome messages. Directory harvest attacks are attempts to determine valid email addresses for use with spam. You configure this option on Receive connectors by using the TarpitInterval parameter with the Set-ReceiveConnector cmdlet.

Back Pressure

Back pressure monitors the Microsoft Exchange Transport service on Hub and Edge Transport servers, taking action when resource pressures build up as a method of ensuring availability. Back pressure works by preventing system resources from being overwhelmed by rejecting or limiting incoming connections until the pressure on system resources eases. Back pressure works in conjunction with message throttling. The difference is that back pressure only applies when the transport server’s system resources are under pressure, whereas message throttling limits apply all the time.

Message Queues and Shadow Redundancy

Shadow redundancy is a transport server feature that ensures that email messages are not lost in transit if a transport server fails. Shadow redundancy works by waiting until the transport server can verify that delivery has occurred to the next hop in a message’s path before deleting the local copy. If the next hop delivery fails, the transport server resubmits the message to the next hop. Shadow redundancy is handled by the Shadow Redundancy Manager, which is responsible for keeping track of the shadow server for each primary message that the server is currently processing and the discard status to be sent to shadow servers. Including shadow redundancy in an Exchange design accomplishes the following goals:

• Ensures that as long as a redundant message path exists in a routing topology, message routing will occur in the event of transport server failure.

• Allows you to bring a Hub or Edge Transport server down for maintenance without having to worry about emptying queues or losing messages.

• Minimizes additional network traffic because it doesn’t require duplicate messages to be transmitted to multiple servers. The only additional traffic is a discard status message.

• Reduces the necessity for storage hardware redundancy on transport system. Even if you don’t have a redundant path, you can get a replacement transport server in place and the mail flow will resume without losing any messages. Whether this is an appropriate strategy depends on your SLA.

Shadow redundancy requires an extension of the SMTP service that is currently supported only by Exchange Server 2010 transport servers. During SMTP communication, a check is performed to determine whether the next hop server supports the shadow redundancy feature. In the event that the next hop server does not support shadow redundancy, the Shadow Redundancy Manager marks the message as delivered after it has been handed off to the next server and deletes it rather than waiting for confirmation from the next hop server that it has been successfully delivered to the next hop plus one server.

Shadow redundancy can be enabled or disabled on a per-organization level basis using the Set-TransportConfig cmdlet with the ShadowRedundancyEnabled parameter. For example, to enable shadow redundancy for all servers in the organization, use the following command:

Set-TransportConfig -ShadowRedundancyEnabled $true

Transport Storage Requirements

The amount of disk space required by a transport server depends on the number of messages sent and received each day, how long you keep transaction logs, and whether protocol logging has been set up. When including Hub Transport storage requirements in an Exchange design, you need to make an estimate of the number of messages that will queue on the server. Although a single server can queue up to 500,000 messages, unless a Hub Transport server routes messages directly to the Internet or a failure occurs, the average number of messages sitting in the queue is unlikely to be high. Your design should take into account failure scenarios, but you probably don’t need to configure storage for a transport server so that it can cope with 500,000 queued messages, unless the server is likely to process that number of messages over a 24-hour period.

Your design needs to take into account how Hub Transport servers will respond in the event of some failure that prevents them from offloading messages to other transport servers.

When planning transport server storage requirements, take into account the following:

• If the average message size at an organization is 200 KB and 10,000 messages pass across the organization’s main site every day, the queue database could grow to almost 2 GB if a failure occurs that stops messages being transmitted off the server for a 24-hour period.

• Message tracking logs consume roughly .5 KB per message sent or received. At a site that has 10,000 messages passing through each day, keeping message tracking logs for the default 7 days will consume another 35 MB or so of space.

• Agent, Protocol, and Connectivity logs record information about SMTP traffic. These logs vary in size depending on the size, amount, and kind of messages delivered by the transport server. Agent, Protocol, and Connectivity logs consume approximately 2 KB per message. At the theoretical site that processes 10,000 messages, that’s another 20 MB a day.

• If you are using Database Availability Groups (DAGs), the transport dumpster can grow up to a default 18 MB for every mailbox database in a single Active Directory site. The Transport Dumpster holds a copy of messages sent to mailboxes that are part of a DAG and only deletes those messages when the message has successfully replicated to all members of the DAG. If a site hosts 200 Exchange mailboxes, it is theoretically possible that the combined transport dumpsters for those mailboxes will require approximately 3.6 GB of storage space.

You can modify the size of the Transport Dumpster and configure how long it retains messages on the General tab of the Transport Settings Properties dialog box, shown in Figure 1-4. You can access this dialog box by clicking the Global Settings tab when you have selected the Hub Transport node under Organization Configuration in Exchange Management Console. You can also configure the maximum dumpster size and retention time using the Set-TransportConfig cmdlet with the MaxDumpsterSizePerDatabase and MaxDumpsterTime parameters.

Planning Accepted and Remote Domains

Your Exchange organization can only accept messages for email domains that are configured as accepted domains. An accepted domain is also an email domain for which your organization is able to send email. For example, if your organization needs to accept email for addresses within the @tailspintoys.com and @wingtiptoys.com domains, you will need to include these domains as accepted domains within your Exchange design. If your recipients want to use the @adatum.com email domain when sending messages from Exchange, @adatum.com will need to be configured as an accepted domain.

Exchange Server 2010 supports three types of accepted domain:

• Authoritative Domains This is the most obvious type of mail domain to include in your Exchange design because this is the domain you use for recipients who have mailboxes that are a part of your Exchange organization. The default authoritative domain for an Exchange organization is the fully qualified domain name (FQDN) of the forest root domain. This means that if the FQDN of your organization’s forest root domain is contoso.internal, contoso.internal will be automatically configured as the default authoritative domain.

• Internal Relay Domain You include this type of email domain in your design when Exchange will need to forward messages to another email system on the internal network. You use internal relay domains in your design if you need to route messages to a third-party email system or to another Exchange organization if your organization has multiple forests and is using the cross-forest topology model. Your design should include an internal relay domain if you’ve split your address space and some accounts in an email domain are hosted by Exchange and others by a third-party mail system.

• External Relay Domain You include an external relay domain in your design if you need to configure your Exchange organization to accept email messages from external organizations so that they can be forwarded to another external organization. To have external relay domains function properly, Send connectors to the external domain must be configured on Edge Transport servers.

Remote domains allow you to control message formatting options for specific email address domains. They also allow you to configure whether external out-of-office messages will be sent to users in those domains. You include remote domains in your Exchange design when you want to control the types of messages and message formats that are sent to a specific external domain.

Planning Send and Receive Connectors

Send and Receive connectors control how messages flow in, out, and through your Exchange organization. You include them in your Exchange design when you want to route messages between Hub Transport and Edge Transport servers when you don’t have an edge subscription, or between transport servers and other messaging systems on the internal network or the Internet.

The difference between these connector types is as follows:

• A Receive connector allows a transport server to receive SMTP traffic from specific sources. This can include SMTP servers on the Internet, Edge Transport servers that aren’t configured to use edge synchronization, third-party SMTP servers on the internal network, and SMTP mail clients.

• A Send connector transmits a message to a destination location using the SMTP protocol. Send connectors can be configured to send email directly to a destination SMTP server, or you can configure a Send connector to route outgoing messages through a smart host.

You don’t need to plan Send connectors or Receive connectors for message transmission between Hub Transport servers that are in the same Exchange organization because Hub Transport servers that are members of the same Exchange organization are automatically configured to communicate with each other when you deploy Exchange. You also don’t need to plan Send connectors or Receive connectors between Hub Transport and Edge Transport servers when you configure an edge subscription because the edge subscription process creates the necessary connectors between these servers.

You do need to plan Send and Receive connectors in the following circumstances:

• You need to configure communication with another messaging system hosted on your organization’s internal network.

• You need to send messages through a smart host.

• You need to configure a secure connection with a partner organization that uses a technology such as mutually authenticated TLS.

• You want to route messages through Exchange Hosted Services as a method of using features such as hosted filtering, hosted archive, hosted encryption, and hosted continuity.

Planning Outbound Message Flow

For your Exchange organization to send messages out to hosts on the Internet, you need to have at least one SMTP Send connector that includes within its address space Internet SMTP domains. Depending on the size and structure of your organization, you may choose to deploy multiple Edge Transport servers with multiple SMTP Send connectors. You can also configure one SMTP Send connector to use multiple Edge Transport servers as a source server depending on your organizational needs.

Organizations that have multiple sites can choose to deploy an Edge Transport server at each site so that outbound messages from that site are routed directly to the Internet, rather than being routed across the internal network to be forwarded to the Internet from a single perimeter network. The Edge Transport servers at each site can either be configured with an edge subscription to their local parent site, or you can manually configure Send connectors on that local site’s Hub and Edge Transport servers. You’ll learn about setting up Edge Transport servers with and without subscriptions in Chapter 2.

Planning Inbound Message Flow

For your Exchange organization to accept incoming messages from the Internet, it is necessary for you to configure at least one SMTP Receive connector that will accept anonymous SMTP connections from SMTP servers on the Internet. You also need to configure a DNS Mail Exchange (MX) record to point to the server that hosts the SMTP Receive connector in your organization’s externally resolvable DNS zone. This record allows SMTP servers on the Internet to determine the IP address of your organization’s SMTP gateway.

If your organization has more than one location, you may choose to have multiple Edge Transport servers that process incoming email. For example, if your organization has offices in the Australian state capital cities of Brisbane, Sydney, and Melbourne, you might choose to deploy an Edge Transport server on each site’s perimeter network. Whether this would lead to any efficiencies when you are using a single email domain namespace is questionable. If you create MX records with equal priorities that point to each of these Edge Transport servers, incoming messages will distributed across each Edge Transport server with no guarantee that email messages to users in the Sydney site will enter through the Sydney Edge Transport server. Messages will still need to be routed internally in most cases unless they are lucky enough to arrive at the correct site. If you configure the MX records with different priorities, only the MX record with the lowest priority will be used and inbound messages will only route to other servers in the event that the Edge Transport server associated with the lowest priority record is unavailable. Having Edge Transport servers at multiple sites is more beneficial for outbound traffic because these messages can be sent directly to Internet hosts without having to be routed internally.

You may also want to plan additional message connectors to meet specific business requirements. For example, your organization’s external SMTP server needs to be able to accept messages from any SMTP server on the Internet. Historically the SMTP protocol does not require TLS, which means most organizations haven’t configured it on their SMTP servers. If you required TLS on all incoming SMTP connections, you’d end up blocking messages from most organizations on the Internet. You do have the option, however, in conjunction with a partner organization, of configuring a special Receive connector that requires TLS encryption or authentication. This ensures that SMTP traffic that passes between your organization and the partner will be protected from interception as it passes across the public Internet. The majority of your incoming message traffic will not be protected, but message traffic to and from that particular partner will be.

Internal SMTP Relay

You include internal SMTP relay in your design when you need to configure your Exchange organization to route messages to recipients that are not hosted within the local Exchange organization, but may have mailboxes on a third-party messaging system or in another Active Directory forest located on your organization’s internal network. This can either be in a shared address space scenario, in which multiple messaging systems host mailboxes in the same email address space, or the separate address space scenario, where Exchange accepts messages for an address space for which it doesn’t host mailboxes and then routes those messages internally to another messaging system.

In both scenarios it is necessary to configure an Accepted domain as an internal relay domain and then configure a Send connector to route messages to SMTP servers of that separate—but internal—messaging system. For example, if you had two separate Active Directory forests, both of which were configured with Exchange and both of which used the contoso.com mail domain, you would configure one of those organizations to accept and route incoming messages to the other forest. The Send connector to the second forest’s Exchange organization would only be utilized if the recipient mailbox wasn’t hosted in the first forest that accepted the message from an SMTP server on the Internet.

Planning DNS

Planning DNS for transport servers includes two main elements. The first is ensuring that your organization’s Hub Transport and Edge Transport servers are able to resolve each other’s names. The second is to ensure that your organization’s external DNS servers respond if a mail server on the Internet performs a reverse lookup on the public IP address of your organization’s Edge Transport servers.

Edge Transport DNS Resolution

Edge Transport servers need to be able to perform DNS resolution on Internet hosts, but also need to be able to resolve the addresses of Hub Transport servers to which they will route messages. When you are planning Edge Transport server deployment, you may need to configure different DNS server settings for the server’s public and private network adapters, configuring the public adapter to use your ISP’s DNS servers, and configuring the private network adapter to use your internal DNS servers. After you have done this, you can configure the Edge Transport server’s properties by right-clicking the Edge Transport server in EMC and clicking Properties. Here you can specify external DNS lookup settings on the External DNS Lookups tab, as shown in Figure 1-5, or internal DNS lookup settings on the Internal DNS Lookups tab. You can configure Send and Receive connectors to use these internal and external DNS settings when performing name resolution during message transport.

Reverse Lookup Zones

Reverse lookup zones translate IP addresses to fully qualified domain names. You need to consider reverse lookup zones in your Exchange design because many organizations use reverse lookups as a method of filtering unsolicited commercial email, better known as spam. This process works by having an email gateway verify that the DNS domain name associated with the IP address of a remote SMTP server matches the mail domain of the email sent from that server. For example, if you did a DNS lookup on IP address 131.107.125.5 using the nslookup command-line utility, the DNS server would return the result mail.microsoft.com. If your email gateway received an incoming message from 131.107.125.5, it would match the sender’s address against the DNS zone associated with that IP address.

Setting up local reverse lookup zones is straightforward and can be accomplished by performing the following general steps:

1. Open the DNS Manager console on a computer that hosts the DNS role service.

2. Right-click the Reverse Lookup Zones node and then click New Zone.

3. In the New Zone Wizard you specify what type of zone you want to create. In most cases this will be a primary zone.

4. Specify the DNS zone replication scope.

5. Specify whether you want to create an IPv4 or IPv6 reverse lookup zone:

   • If you want to create an IPv6 reverse lookup zone, you need to provide the IPv6 Address Prefix.

   • If you want to create an IPv4 reverse lookup zone, you can either provide the Network ID or the Reverse Lookup Zone Name, as shown in Figure 1-6. If you use the option to use the zone name, it needs to be in the format z.y.x.in-addr.apra where the IPv4 network that you are creating the zone for is in the format x.y.z.0. For example, network 131.107.125.0 would have the reverse lookup zone name 125.107.131.in-addr.apra.

   

   Figure 1-6 Create reverse lookup zone

6. Choose whether to allow secure dynamic updates only, no dynamic updates, or a mix of secure and nonsecure dynamic updates and then finish the wizard.

In most cases though, the public IP address that your organization’s external mail gateway uses, which in a pure Exchange 2010 environment is an Edge Transport server, has been provided to your organization by an ISP. Reverse lookup zones are often managed by ISPs because reverse lookup zones are configured in such a way that the smallest reverse lookup zone is a class C address block. This means that you can’t create a reverse lookup zone for the two or three public IP addresses that have been assigned to your organization. Instead you have to find which organization hosts the reverse lookup zone for the class C address block to which your organizations two or three public IP addresses belong. You’ll then need to get the hosts of those zones to insert the appropriate reverse lookup record.

Planning Transport Server Ports

Because you place Edge Transport servers on a perimeter network, there will be at least one firewall between any Edge Transport servers and the Hub Transport servers hosted in the adjacent Active Directory site. To support mail flow and edge synchronization between Edge Transport and Hub Transport servers, it is necessary to allow communication through specific network ports. Table 1-1 provides a list of the ports that need to be open between different components in an Exchange organization in the event that a firewall exists between them.

Table 1-1 Exchange Transport Roles and Required Ports

Exchange roles	Required ports
Hub Transport server to Hub Transport server	TCP port 25 (SMTP)
Hub Transport server to Edge Transport server	TCP port 25 (SMTP)
Edge Transport server to Hub Transport server	TCP port 25 (SMTP)
Edge Transport server to Edge Transport server	TCP port 25 (SMTP)
Mailbox server to Hub Transport server	TCP port 135 (RPC)
Hub Transport server to Mailbox server	TCP port 135 (RPC)
Edge subscription (EdgeSync) service from Hub Transport server to Edge Transport server	TCP port 50636
Active Directory Domain Controller from Hub Transport server	TCP and UDP port 389 (LDAP) TCP and UDP port 88 (Kerberos) TCP and UDP port 53 (DNS) TCP port 135 (RPC) TCP port 3268 (LDAP GC)
Hub Transport server to Active Directory Rights Management Services	TCP port 443 (HTTPS)
SMTP clients to Hub Transport server	TCP port 587 (SMTP) TCP port 25 (SMTP)

Objective Summary

• Ensure that at least one Hub Transport server is in each site that hosts a Mailbox server.

• Accepted domains determine the email domains for which the Exchange organization will process incoming messages. Authoritative domains are used when the Exchange organization hosts the mailbox. Internal relay domains are used in shared address space scenarios as well as when there is another messaging system on the internal network. External relay domains are used when accepted mail is to be processed and then relayed to an external organization.

• Remote domains allow you to control message formatting and distribution of out-of-office messages.

• Send connectors are used to forward outgoing SMTP traffic to a specific destination.

• Receive connectors are used to accept incoming SMTP traffic from a specific source.

• You can scale Hub Transport server performance by adding additional Hub Transport servers to sites.

Objective Review

Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter.

1. What type of accepted domain would you plan to use if you wanted your Exchange organization to route email messages accepted from hosts to a third-party messaging system hosted on your internal network? This email domain is not used by Exchange recipients.

   1. Authoritative domain

   2. Internal relay domain

   3. External relay domain

   4. Reverse lookup zone

2. You are in the process of designing an Exchange Server 2010 deployment. You will be using Edge Transport servers located on a perimeter network that will have edge subscriptions to Hub Transport servers located at your organization’s main site. Which of the following ports need to be opened between the perimeter network and the main site internal network to support message transport and edge synchronization? (Choose all that apply.)

   1. TCP port 25

   2. TCP port 135

   3. TCP port 389

   4. TCP port 50636

3. Your organization has two separate Active Directory forests. You are planning to deploy an Exchange organization in each forest and want to use a shared address space so that recipients in both forests can use the @contoso.com email domain. Which of the following components will you need to configure in the Exchange organization that will be able to send and receive email from hosts on the Internet to ensure that recipients in the second Exchange organization receive messages? (Choose all that apply.)

   1. Internal relay domain

   2. Remote domain

   3. External relay domain

   4. Send connector

4. You want your Exchange design to use a different routing topology than the default Active Directory routing topology. Which of the following Exchange Management Shell (EMS) cmdlets would you use to set an Exchange-specific cost for an Active Directory IP site link?

   1. Set-ADSite

   2. Set-ADSiteLink

   3. Get-ADSite

   4. Get-ADSiteLink

5. Your organization does not use database availability groups. Which of the following features should you enable to ensure that email messages are not lost in transit in the event that a transport server fails?

   1. Remote domains

   2. Send connectors

   3. Transport dumpster

   4. Shadow redundancy