In Part One of this series, I will walk you through the steps for creating and configuring send connectors using the Exchange management console (EMC). In Part Two, I will teach you how to create send connectors using the Exchange management shell.

Before we begin, take a moment to review the various types of connectors that can be created and configured in Microsoft Exchange server 2010:

  • Send connector
  • Receive connector
  • Foreign (Delivery Agent) connector
  • Linked connector
  • Routing Group connector

Send connectors

A Send connector is used to send email to Internet Servers, which are defined as servers outside of your own organization. Thus, it controls the transmission of email to the outside world. At least one send connector needs to be created manually since none are created by default during the installation and setup of your Exchange server roles. I will cover this process for you in just a moment.

While there are invisible Send connectors created by default, these are used for mail delivery within the Exchange 2010 organization and we have no control over them. Manually created Send connectors must be created on a Hub Transport server, and then get stored in Active Directory. This information is therefore accessible to any Hub Transport Server in the organization, which can use this connector to send email to the internet.

You can configure multiple Send connectors to send email outside your organization. These connectors can be created for different costs depending on the ISP Connection you use. This is helpful when you have multiple ISP connections. In the event that one of your ISPs fails, you can use different Send connectors to route the email to the internet. Multiple send connectors are also helpful when you want certain traffic routed using a different connector.

Real-world example: Having different send connectors comes in handy if you want to send email to Microsoft.com using one ISP connection and then send email to Simple-talk.com using a different connection.

In addition, the Hub Transport server can be configured to send email directly to the recipient, or it can direct outgoing email to a smart host. (A smart host can be an Edge Server or any application such as Borderware, Postini, or Ironport, etc.). If your HUB Transport server is configured to send email directly, then you need to make sure that the DNS is properly configured so that it can resolve internal and external DNS MX records. On the other hand, if your HUB server is configured to send email to a smart host, then naturally the smart host should be configured to deliver the email to the Internet. Let us take a look at how to set up these options.

How to Create and Configure Send Connectors

There are two ways to create a Send connector: 1) via the Exchange Management Console or 2) via the Exchange Management Shell. Both methods deliver exactly the same result, so it is just a matter of choosing the process you prefer. For instructions on creating Send connectors via the Exchange Management console, please see below. Part Two of this series will cover how to create Send Connectors via the Exchange Management Shell.

Creating Send Connectors Via the Exchange Management Console

Open the Exchange management console and navigate to the result pane underOrganization Configuration > Hub Transport Server. Select the Send connectors tab, and click on New Send Connector within the Action pane.

Figure 1. Creating a new Send Connector within the Exchange Management Console.

Now you need to go through a few configuration steps to make sure the new Send connector is set up correctly.

1) Specify the intent of the Connector

Provide a unique name describing the connector’s purpose, particularly if you have multiple connectors, will help you to identity and differentiate specific connectors. Once you have given the connector a name, you need to specify its intended use:

  • Custom: Custom options are used when you want to send mail to a specific domain which is not an Exchange Server. Custom connectors are used for forwarding messages to a smart host, which are configured to use DNS MX records to deliver the email to their destination.
  • Internal: An Internal connector is used when you want your Exchange Server to communicate with other Exchange severs in different forests. For example: If there are multiple Exchange forests in your organization and you want communication between the multiple forests to follow a specific path, use an Internal connector to define that path.
  • Internet: An Internet connector is used to send email directly to the Internet, and is configured to use DNS MX records to route email to its destination. This will be created on the organization’s Internet-facing server(s) in order to deliver email. Use this option when you do not use a smart host to deliver email.
  • Partner: The Partner connector is used to send email to a partner domain (surprise!). For example, if one company acquires another, these two companies may need to run independently. However, they also want to make sure that emails shared between these domains are not sent over the public internet. This is when the Partner Send connector comes into effect.

More in-depth information on the Intended options can be found on Technet.

Figure 2. Specifying the intended use of your Send connector

2) Specify the Address Space

Once you have specified the purpose of your Send connector, you must state the domain address space to which the connector will be used to send mail:

  • An “*” (asterisk) in the Address indicates that this connector will route all domains that do not match the internal organization’s list of accepted domains.
  • “Domain.com” in the address indicates that this connector is dedicated to sending email to domain.com addresses.
  • “*.Domain.com” in the address space indicates that this connector is used for sending email to recipients in domain.com and any sub-domains.
  • Cost is used to set the priority of this connector when two or more connectors are configured for the same address space. The lower the cost, the higher the priority.
  • A Scoped Send connector identifies which Hub Transport servers can use this connector. Send connectors are objects stored in Active Directory. As they are also configuration objects, they can normally be used by any Hub Transport servers in the organization. If you want to restrict the scope of the Send connector in order to limit its use to the AD site of the Hub server it was created on, then this option needs to be checked.

Figure 3. Configuring the address space of the new Send Connector

3) Configuring the Network Settings

The Network Settings determine how the message is routed to the destination SMTP server. They can be configured to work in one of two ways:

  1. Use DNS (Domain Name System) MX records to route mails automatically.
  2. Route mails through one or more smart hosts and let them handle the rest of the delivery.

Use the first option when you want your Send connector to talk directly with the destination SMTP server’s gateway and deliver the emails to that destination gateway itself. Make sure that DNS is properly configured for the server to resolve the Destination MX Records. This option is only available when you have selected Custom, Partner or Internet as your connector intent in step 1 above.

Alternatively, if you select the second option, you will need to supply one or more IP addresses or the FQDN of the smart host which is going to accept the email from this connector. Obviously, you need to make sure that the smart host is capable of delivering emails to the destination SMTP server.

If this send connector needs to resolve remote domains using External DNS server, then check “Use the external DNS lookup settings on the Transport Server” as shown in Figure 4. When you use this check box, you also need to make sure that each Hub Transport server that communicates with the Internet has its External DNS Servers configured.

Figure 4. Specifying IP addresses for smart hosts.

Configuration of the connection(s) to the smart host(s) requires some additional steps to control authentication with the smart host server(s). The options available are:

  • None: The smart host does not require any authentication, and it accepts anonymous connections.
  • Basic Authentication: You will need to provide the smart host with an appropriate username and password to authenticate the connection. If you have multiple smart hosts, then you will need to make sure that they all allow access to the same username and password. Basic Authentication sends the credentials as plain text, and checking Basic authentication Over TLS will enable encryption on the communication.
  • Exchange Server Authentication: This option authenticates the connection to a smart host using an Exchange authentication mechanism, such as TLS direct trust or TLS\Kerberos.
  • Externally Secured: Select this option if the connection to the smart host is secured by external means, such as being physically secured over a private network or secured using Internet Protocol security (IPsec).

Figure 5. Authenticating the connection to the smart host.

4) Source Server Settings.

This is the final configuration step in which you need to identify which severs will be making use of the new connector to route emails. Adding just the required servers helps to ensure that only specific servers are able to participate in email delivery to the Internet or other partner networks. Adding the required servers is simply a matter of clicking the Addicon at the top of the configuration pane, and supplying the necessary server names and details.

Figure 6. Specifying which servers will be using the new Connector

5) Create the Send Connector

Once you are done with the configuration, click Next and then New to create the new Send connector

Figure 7. The newly created Send connector, configured and active.

At this point, we are finished creating send connectors using the Exchange management console. Stay tuned for Part Two of this series in which I will provide step by step instructions for creating Send connectors using the Exchange management shell.