Exchange 2007 Edge Transport Server

What is an Edge Transport Server anyway?

The Exchange Product group developed the Edge Transport Server to give Enterprise organizations powerful out-of-the-box protection against spam without needing to invest in a 3rd party anti-spam solution. The messaging hygiene features in the Edge Transport server role are agent-based and consist of multiple filters which are frequently updated. Although the primary role of the Edge Transport server is to route mail and do message hygiene, it also includes features that will let you do other things such as rewrite SMTP addresses, configure transport rules, enable journaling and associated disclaimers, etc.

It is important to understand that by default the Edge Transport server only filters out spam messages and other unwanted mail using the built in agents. This means that this Exchange 2007 Server role does not perform any filtering when it comes to mail-borne viruses. To filter virus infected messages using the Edge Transport server, you must install Forefront Security for Exchange or a 3rd party product on the server.

Deployment Considerations

The Edge Transport Server role in Exchange Server 2007 is designed to be installed in your organization’s perimeter network (aka DMZ or screened subnet). The Edge Transport Server is the only Exchange 2007 server role that should not be part of your corporate Active Directory on your internal network; it should instead be installed on a stand-alone server in a workgroup or as a domain member in an Active Directory dedicated to servers located in the perimeter network as shown in Figure 1.

Figure 1: Typical Edge Transport Server Deployment Scenario

Although the Edge Transport Server role is isolated from Active Directory on the internal corporate production network, it is still able to communicate with the Active Directory by making use of a collection of processes known as EdgeSync that run on the Hub Transport Server and which, since it is part of the Active Directory, have access to the necessary Active Directory data. The Edge Transport server uses Active Directory Application Mode (ADAM) to store the required Active Directory data, which is data such as Accepted Domains, Recipients, Safe Senders, Send Connectors and a Hub Transport server list (used to generate dynamic connectors so that you do not need to create them manually).

It is important to understand that the EdgeSync replication is encrypted by default, and that the replication is a one-way process from Active Directory to Active Directory Application Mode (ADAM), this means that no data is replicated from ADAM to AD.

The first time EdgeSync replication occurs, the ADAM store is populated, and after that data from Active Directory is replicated at fixed intervals. You can specify the intervals or use the default settings, which when speaking configuration data is every hour and every 4th hour for recipient data.

Although the Edge Transport server role has been designed to provide improved anti-spam and antivirus protection for an Exchange 2007 organization, you can deploy this server role in an existing Exchange 2003 organization as well. Since you install the Edge Transport server role on a stand-alone machine in the perimeter network (aka DMZ or screened subnet), this is even a relatively simple task. But even though you would be able to use the Edge Transport server role as a smart host or an SMTP relay server in an Exchange 2003 organization, you will not be able to replicate configuration and recipient data from Active Directory to ADAM using EdgeSync as this requires an Exchange 2007 Hub Transport server on the internal network. However, this doesn’t hinder you from using the filtering agent that doesn’t rely on the EdgeSync service. If you only use the Intelligent Message Filter (IMF) in your Exchange 2003 organization, deploying an Edge Transport server in the perimeter network (aka DMZ or screened subnet) would make sense, since it would provide an additional layer of anti-spam protection. And as mentioned previously, you could also install Forefront Security for Exchange Server on the Edge Transport server in order to filter out virus infected messages.

Like is the case with the Exchange 2007 Hub Transport server, the Edge Transport server has its own Jet Database to process the delivery of inbound as well as outbound E-mail messages. When inbound E-mail messages are stored in the Jet database and are ready for delivery, the Edge Transport server lookups the respective recipient(s) in the ADAM store that as mentioned, among other things contains recipient data replicated from the Active Directory using the EdgeSync service.

In a scenario where you have deployed multiple Edge Transport servers in your organization, the Edge Transport servers uses DNS round robin (which is supported by most DNS servers today) to network and load-balance network traffic between the servers. I leave the details on how to deploy multiple Edge Transport servers using load balancing and a high availability approach for another article.

Prerequisites

In order to follow along with the deployment steps in this article, you need to have the following ready in your lab environment:

• An Exchange 2007 SP1 organization where you have deployed at least one Hub Transport server
• Have a Windows Server 2003 SP1 or Windows Server 2008 Standard edition ready (the server on which we will install the Edge Transport server role)
  
  

Installing required components and configuring the server

Okay so before we can install the Edge Transport server role on the server, there are several steps we must complete first.

Creating a DNS Suffix

Before you can install the Edge Transport Server role, you should make sure you have created a DNS Suffix on the server. Be sure to pick the right NetBIOS name as well as DNS Suffix the first time as its not supported to change these once the Edge Transport server role has been installed. In addition, the readiness check will fail if a DNS Suffix cannot be located. Creating the DNS Suffix is a very simple process; you can do so by logging on to the server with the Administrator account, or another account with administrator rights. Then click Start and then right-click My Computer and select Properties in the context menu On the system property page, click the Computer Name tab and then Change (see Figure 1).

Figure 1: Computer Name Tab

Now click the More button and then enter the respective DNS Suffix (see Figure 2). Click OK four times.

Figure 2: DNS Suffix and NetBIOS Computer Name

Click Yes to reboot the server, so the changes takes effect.

Since the Edge Transport server role uses ADAM directory service as the repository for the replicated configuration and recipient data from Active Directory, it should come as no surprise that we’ll need to install the ADAM component before we can install the Edge Transport server role. If you plan on installing the Edge Transport server role on a Windows 2003 R2 server, you can install the component via the Add or Remove Programs | Add/Remove Windows Components| Active Directory Services, here you need to tick Active Directory Application Mode (ADAM) as shown in Figure 3, then click OK twice.

Figure 3: Adding the ADAM Component

Like is the case with any other Exchange 2007 Server role you also need to install both the .NET Framework 2.0 component as well as Windows PowerShell 1.0.

SMTP Transport Stack

As most of you might recall Exchange Server 2000 and 2003 extended and made use of the Windows Server 2000 or 2003 SMTP and NNTP services, and thus required you installed both the Windows NNTP and the SMTP component (which both are part of IIS) prior to installing the Exchange Server product itself. Since NNTP is one of the features which aren’t supported in Exchange Server 2007, you need to make sure this component isn’t installed on the server, if it is the Exchange Server 2007 Readiness Check will fail. In addition because Exchange Server 2007 no longer makes use of the Windows Server SMTP service, but instead has its own transport stack, which has been written from the ground up in managed code, you also need to make sure the Windows Server SMTP component isn’t installed on the server. Like with NNTP the Exchange Server 2007 Readiness Check will fail, if this component is found on the server. Some of you might ask why the Exchange Product group replaced the Windows SMTP component with their own? Well by doing so they have reduced the risks that are associated with denial of service attacks as well as eliminated the dependency on IIS as well as reduced the work which is required to properly secure the server for deployment in the perimeter network (aka DMZ or screened subnet).

Name Resolution

It’s important that the Edge Transport server and the Hub Transport server in your Exchange 2007 organization can resolve each other’s FQDN NetBIOS names. In order to accomplish this, you can create the necessary host record in a forward lookup zone on the DNS server used by the Edge Transport server (typically a DNS server located in the perimeter network) and the Hub Transport server (typically an internal Domain Controller with DNS installed). Note that in order for the Hub Transport server to see the Edge Transport server, you must create the necessary forward lookup zone and name record on the DNS servers as shown in Figure 4.

Figure 4: DNS Management MMC Snap-in

You may also choose to simply add the FQDN NetBIOS name and IP address of the Edge Transport server to the local hosts file on each Hub Transport server, and the FQDN NetBIOS name and IP address of any Hub Transport server to the local hosts file on the Edge Transport server in your Exchange organization. Although this is a perfectly supported solution, I don’t recommend you use it unless you’re dealing with a small shop which probably got one Edge Transport server and one or perhaps two Hub Transport server. If you’re a messaging administrator/consultant in a large Exchange organization, which contains multiple Edge Transport servers as well as several Hub Transport servers, it’s far better to keep the name resolution centralized on dedicated DNS servers.

Installing the Edge Transport Server Role

Okay, we can now begin the actual installation of the Exchange 2007 Edge Transport server role. As is the case with all the other Exchange Server 2007 roles, you install this role by performing navigating to the Exchange Server 2007 source directory (DVD media or the network share containing the Exchange Server 2007 binaries) and double-click on Setup.exe. When the Exchange Server 2007 setup splash screen appears click Step 4: Install Microsoft Exchange.

When the Exchange Server 2007 Installation Wizard has initialized, click Next then accept the End User License Agreement (EULA), then click Next again.

You now have the option of enabling Error Reporting (which is recommended, so that the Exchange Product group receives information about any issues you encounter, which in the end gives us a better product). When you have decided whether you want to enable error reporting or not, you can click Next.

Since we’re going to install the Edge Transport server role, you now need to choose Custom Exchange Server Installation, then click Next (see Figure 5). This is also the screen where you have the option of changing the path for the Exchange Server installation (in the bottom of the screen).

Figure 5: Installation Type Setup page

Tick Edge Transport Role (see Figure 6), then click Next.

Figure 6: Selecting to install the Edge Transport Role

When you have selected the Edge Transport serve role as well as the installation path, click Next. If the Readiness Check completes without any issues, you can begin the installation by clicking the Install button. The Installation Wizard will now copy the required files then begin the installation. Since the server on which Edge Transport role is a stand-alone machine, which doesn’t belong to an Active Directory Forest, and since this type of installation is pretty small, the installation process will complete relatively fast.

When the installation has completed, click Finish.