EdgeSync and Send Connectors
Microsoft Exchange Server 2007 will reach end of support on April 11, 2017. To stay supported, you will need to upgrade. For more information, see Resources to help you upgrade your Office 2007 servers and clients.
Applies to: Exchange Server 2007, Exchange Server 2007 SP1, Exchange Server 2007 SP2, Exchange Server 2007 SP3
After an Edge Transport server is subscribed to the Microsoft Exchange organization, all configuration of Send connectors for that Edge Transport server must be performed on a Hub Transport server. The EdgeSync synchronization process then replicates those Send connectors to the Active Directory Application Mode (ADAM) directory service as part of the configuration data. This topic describes the Send connectors that are automatically created during the EdgeSync synchronization process and how the Edge Subscription affects the configuration of Send connectors for the Edge Transport server.
Automatically Created Send Connectors
By default, when you complete the Edge Subscription process by importing the Edge Subscription file to a Hub Transport server, the Send connectors that are required to enable end-to-end mail flow between the Internet and the Exchange organization are created automatically. Any existing Send connectors on the Edge Transport server are deleted. You can also select to suppress automatic creation of Send connectors and configure Send connectors manually. Manual Send connector configuration for a subscribed Edge Transport server is discussed in "Manually Configuring Send Connectors" later in this topic.
The EdgeSync synchronization process provisions the following Send connectors:
A Send connector that is configured to relay e-mail messages from the Exchange organization to the Internet
A Send connector that is configured to relay e-mail messages from the Edge Transport server to the Exchange organization
Also, by subscribing an Edge Transport server to the Exchange organization, you enable Hub Transport servers that are located in the Active Directory directory service site to which the Edge Transport server is subscribed to use the intra-organization Send connector to relay messages to that Edge Transport server. These Send connectors are described in the following sections of this topic.
Automatically Created Send Connector to the Internet
By default, when you run the New-EdgeSubscription cmdlet in the Exchange Management Shell on the Hub Transport server, the CreateInternetSendConnector parameter is set to $true
. The following table shows the default configuration of this Send connector.
Automatic Internet Send connector configuration
Parameter | Value |
---|---|
Name |
EdgeSync - <Site Name> to Internet |
Address Space |
SMTP:*;100 |
Source Servers |
Edge Subscription name Note The name of the Edge Subscription is the same as the name of the subscribed Edge Transport server. |
Enabled |
True |
DNS Routing Enabled |
True |
Domain Secure Enabled (Mutual Auth TLS) |
True |
If more than one Edge Transport server is subscribed to the same Active Directory site, additional Send connectors to the Internet are not created. Instead, all Edge Subscriptions are added to the same Send connector as source servers. This configuration causes outbound connections to the Internet to be load balanced between the subscribed Edge Transport servers.
This Send connector is configured to send e-mail messages from the Exchange organization to all remote Simple Mail Transfer Protocol (SMTP) domains. It will use Domain Name System (DNS) routing to resolve domain names to mail exchange (MX) records. You can modify the configuration of this connector manually. However, if you must route outbound e-mail through a smart host, for example, you can suppress creation of this connector and manually configure a Send connector to the Internet.
Note
A Send connector that is configured to use a smart host to route e-mail must have the DNSRoutingEnabled parameter set to $false
. If the DNSRoutingEnabled parameter is set to $false
, the DomainSecureEnabled parameter must also be set to $false
.
Automatically Created Inbound Send Connector
By default, when you run the New-EdgeSubscription cmdlet in the Exchange Management Shell on the Hub Transport server, the CreateInboundSendConnector is parameter set to $true
. You cannot change the value of this parameter when you use the New Edge Subscription Wizard in the Exchange Management Console. The following table shows the configuration of this Send connector.
Automatic inbound Send connector configuration
Parameter | Value |
---|---|
Name |
EdgeSync - Inbound to <Site Name> |
Address Space |
SMTP:--;1 |
Source Servers |
Edge Subscription name |
Enabled |
True |
DNS Routing Enabled |
False |
Smart Hosts |
-- |
The -- placeholder in the address space for the inbound Send connector represents the authoritative and internal relay accepted domains for the Exchange organization and is the literal character displayed. Any messages that the Edge Transport server receives for authoritative and internal relay accepted domains are routed to this Send connector and relayed to the smart hosts.
The -- placeholder in the list of smart hosts represents all the Hub Transport servers that are located in the subscribed Active Directory site and is the literal character displayed. Hub Transport servers that are added to an Active Directory site after an Edge Subscription has been established do not participate in the EdgeSync synchronization process. However, they are automatically added to the list of smart hosts for the inbound Send connector. If more than one Hub Transport server is located in the subscribed Active Directory site, inbound connections will be load balanced across the smart hosts.
You cannot modify the address space or list of smart hosts for the inbound Send connector. However, if you use the New-EdgeSubscription cmdlet in the Exchange Management Shell when you create the Edge Subscription on the Hub Transport server, you can set the value of the CreateInboundSendConnector parameter to $false.
If you do this, no inbound connector is created and you must manually configure a Send connector from the Edge Transport server to the Exchange organization.
After the initial EdgeSync synchronization has finished, you can run the Get-SendConnector cmdlet in the Exchange Management Shell on the subscribed Edge Transport server to verify that these Send connectors are created.
Intra-organization Send Connector
The intra-organization Send connector is an implicit and hidden Send connector that is automatically computed by Exchange Server 2007 and enables Hub Transport servers in the same organization to relay messages to each other without using explicit Send connectors. Because a configuration object that has an Active Directory site association exists in Active Directory for an Edge Subscription, the intra-organization Send connector will also be used to relay messages to that Edge Transport server.
Only Hub Transport servers that are located in the same Active Directory site to which the Edge Transport server is subscribed can send and receive e-mail directly to or from the subscribed Edge Transport server. If you have a multi-site forest and Exchange 2007 is deployed in more than one site, the Hub Transport servers in non-subscribed sites will route outbound e-mail to the subscribed site. A Hub Transport server in the subscribed site will route outbound e-mail to the Edge Transport server.
The following figure shows outbound mail flow from a non-subscribed Active Directory site in an Exchange organization. An Active Directory forest with two sites has associated an Edge Subscription with Site-A. If a message is sent from Site-B to an Internet recipient, it will be relayed first to Site-A. The receiving Hub Transport server in Site-A relays the message to the Edge Transport server by using the intra-organization Send connector. The Edge Transport server then routes the message to the automatically created EdgeSync - Site-A to Internet Send connector for delivery to the recipient domain.
Outbound mail flow with an Edge Subscription
The following figure illustrates inbound mail flow from the Internet through a subscribed Edge Transport server. In this example, a message is received for a recipient whose mailbox is stored on a Mailbox server that is located in Site-B. The Edge Transport server receives the message and routes it to the EdgeSync - Inbound to Site-A Send connector. The receiving Hub Transport server in Site-A then routes the message to Site-B by using the intra-organization Send connector.
Inbound mail flow with an Edge Subscription
Manually Configuring Send Connectors
After an Edge Transport server is subscribed to an Active Directory site, the tasks for creating and modifying Send connectors are disabled on the Edge Transport server. If you want to create a Send connector for which the Edge Transport server is a source server, you create the Send connector inside the Exchange organization. You can specify one or Edge Subscriptions as the source server for a Send connector. You cannot specify both Hub Transport servers and Edge Subscriptions as source servers for the same Send connector. The Send connector will be replicated to the ADAM instance on the Edge Transport server that is configured as a source server the next time that configuration data is synchronized by the EdgeSync synchronization process. If you list more than one Edge Subscription as a source server, connections to that Send connector will be load balanced between the subscribed Edge Transport servers. However, the Edge Transport servers have to be subscribed to the same Active Directory site for load balancing to occur. If Edge Subscriptions in different Active Directory sites are configured as source servers on the same Send connector, Hub Transport servers will route only to the closest source server.
You have to create Send connectors manually in the following scenarios:
You have suppressed automatic creation of the Internet or Inbound Send connectors.
You have accepted domains that are configured as external relay domains.
Suppressing Automatic Creation of Send Connectors
Depending on the topology of your Exchange organization, you may decide to suppress automatic creation of Send connectors. The following scenarios provide examples of topologies that require that you suppress automatic creation of Send connectors.
Partitioning Mail Flow
You may decide to partition the inbound and outbound mail processing between two Edge Transport servers. In this scenario, one Edge Transport server is responsible for processing outbound mail flow and a second Edge Transport server is responsible for processing inbound mail flow. To achieve this scenario, you configure the Edge Subscriptions as follows:
For the Edge Transport server that processes only outbound mail flow, run the following command in the Exchange Management Shell on the Hub Transport server:
New-EdgeSubscription -File "c:\edge1subscriptionfile.xml" -Site "Site-A" -CreateInboundSendConnector $false -CreateInternetSendConnector $true
For the Edge Transport server that processes only inbound mail flow, run the following command in the Exchange Management Shell on the Hub Transport server:
New-EdgeSubscription -File "c:\edge2subscriptionfile.xml" -Site "Site-A" -CreateInboundSendConnector $true -CreateInternetSendConnector $false
Routing Outbound E-Mail to a Smart Host
If your Exchange organization routes all outbound e-mail through a smart host, the default automatically created Send connector to the Internet will not have the correct configuration.
In this scenario, you run the following command in the Exchange Management Shell on the Hub Transport server to suppress automatically creation of the Send connector to the Internet:
New-EdgeSubscription -File "c:\edgesubscriptionfile.xml" -Site "Site-A" -CreateInternetSendConnector $false
After the Edge Subscription process is complete, manually create a Send connector to the Internet. Create the Send connector inside the Exchange organization and select the Edge Subscription as the source server for the connector. Select the Custom usage and configure one or more smart hosts. The Send connector will be replicated to the ADAM instance on the Edge Transport server the next time that EdgeSync synchronizes configuration data. You can also force EdgeSync synchronization to immediately start by running the Start-EdgeSynchronization cmdlet in the Exchange Management Shell on a Hub Transport server.
The following code provides an example of how to use the Exchange Management Shell to configure a Send connector for a subscribed Edge Transport server to route messages for all Internet address spaces through a smart host. This task is run inside the Exchange organization, not on the Edge Transport server.
New-SendConnector -Name "EdgeSync - Site-A to Internet" -Usage Custom -AddressSpaces SMTP:*;100 -DNSRoutingEnabled $false -SmartHosts 192.168.10.1 -SmartHostAuthMechanism None -SourceTransportServers EdgeSubscriptionName
Important
This example does not specify any smart host authentication mechanism. Make sure that you configure the correct authentication mechanism and provide all necessary credentials when you create a smart host connector in your own Exchange organization.
Configuring Send Connectors for External Relay Domains
If you have accepted domains in your Exchange organization that are configured as external relay domains, you have to manually create a Send connector for those address spaces. Messages that are being delivered to external relay domains are relayed by the Edge Transport server. The Edge Subscription process does not automatically create and configure Send connectors for external relay domains. Therefore, you have to configure Send connectors for those domains and specify one or more Edge Subscriptions as the source server for those Send connectors.
The DNS MX resource record for an external relay domain resolves to your Edge Transport server. Configure a Send connector that relays e-mail to an external relay domain to use a smart host for routing. If you configure the Send connector for an external relay domain to use DNS routing, a routing loop will occur. For more information about external relay domains, see Managing Accepted Domains.
For More Information
For more information, see the following topics: