If you would like to read the other parts in this article series please go to:
- Uncovering the Exchange 2007 Edge Transport Server (Part 2)
- Uncovering the Exchange 2007 Edge Transport Server (Part 3)
- Uncovering the Exchange 2007 Edge Transport Server (Part 4)
- Uncovering the Exchange 2007 Edge Transport Server (Part 5)
- Uncovering the Exchange 2007 Edge Transport Server (Part 6)
Back in February 2004 when Exchange Server 2003 was still the primary Exchange messaging platform used by Enterprise organizations around the world, Microsoft announced (see the press release here) that they would deliver an enhanced SMTP relay implementation known as Microsoft Exchange Edge Services. The plan was to make the Exchange Edge Services an enhancement to the Simple Mail Transfer Protocol (SMTP) relay implementation in Exchange Server 2003. With Exchange Edge Services, Microsoft would provide a new set of capabilities aimed at enabling customers to better protect their e-mail system from junk e-mail and viruses as well as improve the efficiency of handling and routing Internet e-mail traffic.
Enhancing the Exchange Server 2003 product, which already included several anti-spam features at that time and had additional features added via service pack 1 and 2, sounded like sweet news to the messaging consultants and administrators working for or at Enterprise organizations that relied on Exchange as the underlying messaging platform. But then, just before Christmas the same year, the Exchange product group posted this information on the Microsoft Exchange team blog. Basically what they were saying was that since several customers also requested features such as regulatory compliance that would mean additional development time. Therefore, the Exchange Product group decided to ship the Exchange Edge Services as part of the next version of Exchange Server, which was Exchange Server 2007. And this is how the Exchange 2007 Edge Transport Server role was born.
In this articles series, I will take a deep look at the Edge Transport Server role and its feature-set. In part 1, I will talk about what an Edge Transport Server is and why it could be an interesting platform to base your anti-spam as well as anti-virus solution on.
Enough background information, let’s get started.
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.
Summary
In this part of the series covering the Edge Transport server role in Exchange server 2007, we went over Microsoft’s vision with this server role and explained how it can be used in your organization. In the next article we will cover how to deploy the Edge Transport server.
If you would like to read the other parts in this article series please go to:
