If you would like to read the other parts in this article series please go to:
- Configuring Edge Transport Server Without Edge Synchronization (Part 2)
- Configuring Edge Transport Server Without Edge Synchronization (Part 3)
- Configuring Edge Transport Server Without Edge Synchronization (Part 4)
Introduction
I recently needed to install and configure an Edge Transport server into an organization that was not able to use the EdgeSync process. The EdgeSync process does most of the configuration work for you and therefore implementing an Edge Transport server without the EdgeSync process means that there is more manual configuration work to be done. This manual configuration process centers largely around the creation of the required Send and Receive Connectors. Microsoft details a great process for creating all the required connectors and in this article I will go over this process and aim to describe the process thoroughly using screen shots where appropriate.
In this article I will also be using a lab environment consisting of two servers. One server, called SRV1, which is running as an Active Directory domain controller as well as an Exchange 2007 server hosting the mailbox, Hub Transport and Client Access Server roles. The only role of interest on this server is the Hub Transport role. The other server, called EDGE, is running the Edge Transport server role. The Edge Transport server has two network cards assigned to it, one network card is classified as the ‘internal’ network card that is used to communicate with the Hub Transport server, whilst the other is classified as the ‘external’ network card that is used to communicate externally with the Internet. The following IP address structure is used and you can refer to these if you want, when looking at the following screen shots.
- 192.168.40.40 – Edge Transport external interface
- 10.1.1.2 – Edge Transport internal interface
- 10.1.1.1 – Hub Transport server
Figure 1 below shows the overall configuration and the various connectors that will be created.
Figure 1: Lab Layout
In this article, I’ll use an ‘inside-out’ approach whereby I will start by examining the requirements on the inside of the Exchange 2007 organization. In this case, these will be the requirements for the Hub Transport server. I will then move on to the requirements for the outside of the Exchange 2007 organization (which in this case will be the Edge Transport server) and also any other considerations, such as additional relay services like MessageLabs or Postini. The reason that I am including the Edge Transport server as an external component is based mainly on the fact that the Edge Transport server is deployed into a workgroup or, sometimes, a perimeter network Active Directory environment. In other words, the Edge Transport server does not form a part of the internal Active Directory infrastructure and is therefore not strictly a part of the Exchange 2007 organization.
Authentication Accounts
Before we get going by looking at the configuration required within the Exchange 2007 organization, we need to create two user accounts. One of these will be created in the internal Active Directory domain, whilst the other will be created locally on the Edge Transport server. The reason for creating these accounts is because in the procedures that will follow in this article series we will be creating connectors, to communicate with either the Edge Transport server or the Hub Transport server. The connectors will be using smart host authentication with the other server that they are connected to using basic authentication over Transport Layer Security (TLS). To do this we need a user account and password that is specified within the properties of the connector.
You could consider not using any form of smart host authentication and get away with using anonymous access. This would only really be acceptable if you ensured that each Receive Connector was configured to only accept connections from specific IP addresses. As it happens, the procedure I will be explaining in this article uses the IP address restrictions as well as smart host authentication using basic authentication over TLS. In this way, you will get the best of both worlds. The general recommendation is to use smart host authentication using basic authentication over TLS if you can, but of course you must remember that certificates come into the equation if you do so.
I will not include all the details on how to create user accounts as I am sure that you will know how to do this. The main thing to remember regarding the creation of these accounts is that the account created on the Edge Transport server must be created in the Local Users and Groups area in the Computer Management snap-in, since the Edge Transport server is not part of the internal Active Directory domain. For the purposes of this article, both accounts will have a name of SMTPAUTH.
There are two other key things to note about these user accounts:
- The SMTPAUTH user account on the Edge Transport server must be made a member of the local Administrators group on the Edge Transport server.
- The SMTPAUTH user account in the internal Active Directory domain must be made a member of the Exchange Servers universal security group.
Hub Transport Send Connector
Of course, it is possible to deploy an Exchange 2007 organization without an Edge Transport server; the Edge Transport server role is purely optional. In an Exchange 2007 organization that does not contain an Edge Transport server the Hub Transport server is responsible for sending email messages to Internet-based recipients as well as messages destined for internal users. To send email messages to Internet-based recipients, we need a Send Connector created within the Exchange 2007 organization. Actually, although I have started this section discussing the requirements for the Hub Transport servers, the Send Connector is not actually created directly on a Hub Transport server, but rather, within the overall Exchange 2007 organization configuration area. You will see this as we progress with the Send Connector creation. The Send Connector can either be configured to send messages directly to Internet-based hosts or it can be configured to send messages to another upstream SMTP relay host within your organization, such as a perimeter network Edge Transport server. The latter option is, of course, the option we will be taking in this article. Let us look at the process required using the Exchange Management Console:
- Run the Exchange Management Console.
- Expand the Organization Configuration object and then select Hub Transport underneath it. In the result pane you will see various tabs, one of which is called Send Connectors. By default, this tab will be empty. Since this tab exists within the overall Organization Configuration area of the Exchange Management Console, you can see why a Send Connector is actually an organization-wide object and not tied to any specific Hub Transport server.
- Right-click Hub Transport in the console tree and choose New Send Connector from the context menu. The New SMTP Send Connector wizard now appears.
- On the opening screen of the wizard, called the Introduction screen, give the Send Connector a suitable name and set the intended use to be Internal as you can see from Figure 2. Setting the intended use to internal allows the connector to send messages to other Exchange servers within the organization, including Edge Transport servers. Once complete, click Next.
Figure 2: Send Connector Introduction Screen
Summary
That is it for part one of this article. So far I have described the lab layout that I am using for this article, then I have gone on to start looking at the configuration of the Send Connector that’s required within the Exchange 2007 organization. In part two of this article series, I will conclude the configuration of this Send Connector.
If you would like to read the other parts in this article series please go to:
