If you would like to read the other parts in this article series please go to:
- Configuring Edge Transport Server Without Edge Synchronization (Part 1)
- Configuring Edge Transport Server Without Edge Synchronization (Part 2)
- Configuring Edge Transport Server Without Edge Synchronization (Part 3)
Introduction
This is the fourth and final part of an article series covering the configuration required on Hub Transport and Edge Transport servers when the Edge synchronization process is not in use. In part three, we completed the configuration of the Hub Transport server by looking at the requirements of the Receive Connector. We then moved on to look at the configuration of the internal Receive Connector on the Edge Transport server. In this final part, we will look at the remaining configuration required on the Edge Transport server.
Edge Transport Internal Send Connector
To complete the configuration of the connectors that interface between the Hub Transport and the Edge Transport server, we need a Send Connector created that can direct inbound Internet messages that arrive at the Edge Transport server onwards to the Hub Transport server.
In parts one and two of this article series I covered the creation of a Send Connector via the Exchange Management Console in quite some depth, so clearly I do not want to repeat the same information here. What I will cover, therefore, is the configuration in brief format, highlighting any key differences that are required for this particular Send Connector. The configuration of the Edge Transport server Send Connector to process inbound messages destined for the Hub Transport server is as follows:
- Run the Exchange Management Console on the Edge Transport server.
- Right-click on the Edge Transport server name in the console tree and choose New Send Connector… from the context menu.
- On the opening Introduction screen of the New Send Connector wizard, ensure that the intended use of the connector is specified as Internal.
- Ensure that the address space is also set to cover each accepted domain in use within your Exchange 2007 organization. In my example, the address space will contain a single domain entry for neilhobson.com. If you have multiple accepted domains in use, you will need to add the additional domains as required. This configuration ensures that this particular Send Connector only processes messages destined for your internal users.
- In the Network Settings page of the wizard, choose the Route mail through the following smart hosts option. In the resulting Add smart host window, enter the FQDN of the Hub Transport server. If you have multiple Hub Transport servers, make sure that each one is entered individually. It is also important to note that the Edge Transport server must be able to resolve this FQDN, so make sure that the configuration element is overlooked. This is typically achieved either by a perimeter network DNS infrastructure, or via hosts files configured on the Edge Transport server. In my example, the FQDN of the Hub Transport server is srv1.neilhobson.com, so this particular page of the wizard looks like the one shown in Figure 11.
Figure 11: Routing Through a Smart Host
- At the Configure smart host authentication settings page of the wizard, select the Basic authentication and Basic authentication over TLS options in the same way as you can see in Figure 5 earlier in this article series. Also, ensure that the username and password of the authentication account you created in the internal Active Directory domain is included in the User name and Password fields.
That completes the configuration of the Edge Transport Send Connector responsible for sending inbound Internet email messages onwards to the Hub Transport server.
Edge Transport Internet Send Connector
We have now completed the loop of connectors between the Hub Transport server located in the internal network and the Edge Transport server located in the perimeter network. It is now time to look at the configuration required on the Edge Transport server to send and receive messages from Internet-based hosts. Since we have already configured a Receive Connector on the Edge Transport server responsible for receiving messages from the Hub Transport server that are destined for Internet-based recipients, it follows that we need a Send Connector on the Edge Transport server to send these messages on their way.
The objective of this new Send Connector is simply to transmit these messages to the next hop, typically the primary SMTP host of the destination domain. Of course, it could also be that you are using an additional 3rd party relay service such as MessageLabs or Postini. In this case, the Edge Transport server must be configured to send outbound Internet email messages to these hosts rather than using DNS to lookup the destination domain name.
I have already covered the creation of a Send Connector via the Exchange Management Console in depth elsewhere in this article series so I will not be repeating the same information here. Here is a brief overview of the requirements for this particular Send Connector:
- Run the Exchange Management Console on the Edge Transport server.
- Right-click on the Edge Transport server name in the console tree and choose New Send Connector… from the context menu.
- On the opening Introduction screen of the New Send Connector wizard, ensure that the intended use of the connector is specified as Internet.
- Ensure that the address space is also set to a single star character, “*”, in the same way as was performed for the Send Connector created previously. This means that this connector will process messages destined for any Internet domain.
- In the Network Settings page of the wizard, choose whether you are routing outbound Internet email through another smart host, or whether you are routing outbound Internet email via DNS. In my example scenario, I am using DNS as shown in Figure 12.
Figure 12: Routing via DNS
That completes the configuration of the Edge Transport Send Connector responsible for sending outbound Internet email messages onwards to the destination domain. If you are forwarding your messages onto another smart host, note that you will see an extra page in the New Send Connector wizard relating to smart host authentication settings. I have already covered the configuration options that you will see on this page elsewhere within this article series. If your upstream smart host requires authentication, you will need to configure the appropriate settings at this point.
Edge Transport Internet Receive Connector
By creating Send Connectors both within the internal Exchange 2007 organization and on the Edge Transport server, it can be seen that we now have a route out of the Exchange organization and onwards to Internet recipients. What about inbound Internet email messages? We have already seen within this article that the default Receive Connector created on a Hub Transport server is already capable of receiving messages from an Edge Transport server. However, as yet, the Edge Transport server has no way of accepting messages from Internet SMTP hosts or other 3rd party message hygiene services such as MessageLabs or Postini, let alone sending them onwards to the Hub Transport servers. Let us look at how the Edge Transport server can accept messages from Internet hosts.
When the Edge Transport server role is deployed, a Receive Connector is created by default. This connector has the default name of Default internal receive connector {server name}. Let us have a look at the default permissions set on this connector:
- Run the Exchange Management Console on the Edge Transport server.
- Select Edge Transport in the console tree and in the work pane click the Receive Connectors tab. The default Receive Connector will be displayed.
- Right-click the default Receive Connector and choose Properties from the context menu.
- Click the Network tab in the resulting connector properties window. This should look like the one shown in Figure 13.
Figure 13: Default Receive Connector Network Settings
- You will see that the default receive connector is configured to use all local IP addresses on port 25, the port for SMTP traffic.
Way back at the beginning of this article series I discussed how the Edge Transport server had been configured with two network cards, one of which is classified as the internal network card whilst the other is classified as the external network card. The default Receive Connector on the Edge Transport server should now be configured such that only the external network card is used to receive email messages. By doing this, you are effectively ensuring that the default Receive Connector is only configured to receive Internet email and therefore will no longer accept connections from the internal Hub Transport servers. To allow the Hub Transport servers to communicate with the Edge Transport server, we have already created a separate Receive Connector as you have seen earlier in this article.
To make the configuration change to ensure the default Receive Connector uses the external network interface, just click the Edit… button in the Use these local IP addresses to receive mail on the Network tab as you will see above in Figure 13. This brings up the Edit Receive Connector binding window as you can see from Figure 14. Here you need to enter the IP address of the external network card in the Specify an IP address field. Once you are happy with the configuration, click OK to close the window but at this time leave the main properties window of the default Receive Connector open as we have one more changes to make.
Figure 14: Receive Connector Bindings
I also like to rename the default Receive Connector to something a little more descriptive, not to mention a little shorter. To do this, click the General tab and modify the name of the connector accordingly. For example, you can see in Figure 15 that I have renamed my default Receive Connector to From Internet. Once you are happy with your configuration, click OK to accept the change and close the properties window. That completes the configuration of the Receive Connector responsible for accepting Internet email on the Edge Transport server.
Figure 15: Naming the Receive Connector
Final Configuration
Now that we have created all the required connectors it is a good time to briefly point out two other key configuration elements in order to provide a working system. First, do not forget that you will need to amend the Accepted Domains configuration within the Edge Transport server to accept email for all your authoritative domains. Second, since we are using TLS in our configuration, ensure that you are using valid certificates on all Hub Transport and Edge Transport servers and that these certificates are trusted by the connecting server. For example, the Hub Transport server certificate must be trusted by the Edge Transport server and vice-versa.
Summary
That completes this article series where we have looked at configuring connectivity between a Hub Transport server and an Edge Transport server without using the Edge synchronization process. Admittedly there should not be too many occasions where such a configuration is required, but since I came across this situation recently I thought it worth writing an article on this very subject.
If you would like to read the other parts in this article series please go to:
