Thomas' Tech Talk

Just Can't Get Enough Of IT

The Stepchild of Exchange Server – The Edge Transport Role

Filed under: Exchange Server — Thomas Stensitzki at 9:47 pm on Sunday, February 16, 2020

Exchange 2019 - Edge Transport Role Icon

The Exchange Edge server role was introduced with Exchange Server 2007. Back in those days, it was State-Of-The-Art to terminate protocol connections in the perimeter network, preferably on servers not being member servers of an internal Enterprise Active Directory.

The Edge server role had been introduced by the Exchange product team to meet this design pattern. Shortly after the initial product launch first Best Practices had been published, describing the optimal deployment options for the new messaging transport role. The adoption rate of the new server role was very low in the beginning. This was mostly due to the technical requirements (e.g. subscription of the Edge server to a dedicated AD site containing Hub transport servers) and to slowly introduced Exchange Server virtualization. Nobody wanted to waste additional hardware resources for an Exchange server role providing so little benefit. This was a kind of technology that was only useful to large enterprises.

Since the Edge server role got introduced there are constant discussions between Messaging Administrators, who want to avoid additional levels of complexity to their Exchange infrastructure, and Security Administrators, who do not allow direct protocol communication originating from the Internet to internal servers (in this case Hub transport servers).

One of the major benefits of an Edge server, from a security standpoint, is the fact that the server is not a member server of an Active Directory Domain. In addition all required information about internal recipients, block- and allow lists are stored encrypted in an AD LDS instance. Updates are pushed from internal servers using the encrypted Edge-Sync.

The RTM release of Exchange Server 2010 included a new version of the Edge server role. There haven’t been any new major features, besides some minor functionality enhancements. The primary feature set remained unchanged:

  • Email filtering
  • Anti-Spam and Anti-Virus
  • Dedicated connectors to partners
  • Connectors using Domain Validation
  • Connectors using Domain Secure, which shows green tick in Outlook when a message has been received via such a secured connector
  • Integration with Office 365
  • Delayed Acknowledge for incoming messages to support Shadow Redundancy
  • Address rewriting

Some of these features are available with properly configured Hub transport servers as well. But as already mentioned, it is a question of transport layer security. Some administrators trust protocol inspection technologies provided by modern firewalls (without naming any specific brand or model). Where do you want to have your attackers end up first? In your perimeter network, right? Otherwise, there is no need for a perimeter network.

With Exchange Server 2013 Microsoft missed providing the Edge server role with the initial RTM release. Instead, it was fully supported to operate internal Exchange 2013 servers with Exchange 2007 or Exchange 2010 server. This “mixed” operating mode was not well accepted, because nobody really wanted to operate and maintain such a configuration. With the release of the so-called Exchange Server 2013 SP1 a bunch of missing Exchange features had been made available including the Edge server role.

Exchange Server 2016 and Exchange Server 2019 support the Edge Transport role as well. The technology stack of the Exchange transport role has not much changed. The reason is that there is not much that needs to be changed.

Is there a need for the Exchange Server Edge Transport Role today?

Yes, we do need the Edge server role these days. The Edge server role provides dedicated endpoints for messages received from and sent to the internet. Such central endpoints provide a starting point for message transport-related support issues. Two Edge servers provide a good redundancy for message flow. Internal Hub transport servers can be scaled as needed. There are no specific system requirements for Edge transport servers that would avoid virtualization. The Edge server role, like the Hub transport role from previous Exchange versions, is a perfect candidate for being virtualized.

Mergers are a perfect example where the Edge server role shows its benefit. Merger situations are always characterized by the need to introduce a new email domain to external recipients as quickly as possible. This should be done without any major technical problems. The expectations expressed by the marketing department are met with resistance from the IT department.  The Edge server role supports such requirements by utilizing the address rewriting capabilities.

But wait, there is another important reason why we need the Edge Transport Role. Edge Server comes into play when you implement an Exchange Server hybrid setup. The supported setup for connecting your on-premises Exchange organization with Exchange Online requires an SMTP-communication flow between Exchange servers. The internal Exchange Servers are domain member servers. Any incoming SMTP-connection must terminate in the perimeter network. The Edge Server is the perfect candidate for this scenario. The use of Edge Server in the perimeter network secures the hybrid mail-flow regardless if you use centralized mail-flow or not.

Even today there are valid reasons for deploying the Exchange Edge Server role.




No Comments »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a comment

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>