Thinking about Exchange 2019?
In October of last year Microsoft released a new version of on-premises Exchange server. Here at...
Microsoft first introduced the Edge Transport role as one of the five Exchange roles in Exchange 2007 and offered it again in Exchange 2010. The purpose of the Edge server role is to provide a solution for customers who require inbound SMTP connections to terminate in the perimeter network (DMZ), rather than in the internal network. Since most inbound SMTP connections are unauthenticated, some security departments are uneasy at allowing these connections directly to internal resources (your Exchange servers). Edge transport servers allow these customers to deploy Exchange without having to buy an SMTP gateway appliance.
For further security, computers running the Edge Transport role are not joined to the internal Exchange organization’s domain and cannot run any other Exchange roles. It is possible to join Edge servers to a separate DMZ domain for group policy configuration and common security configuration, but this is rare since most customers do not deploy Active Directory in their perimeter network.
As the SMTP ingress point for the organization, Edge servers can act as your first line of defense for SMTP malware and denials of service. The Edge Transport role works with internal Exchange servers using an Edge subscription. An Edge subscription provides a mutually authenticated and encrypted connection between the Edge Transport servers and the internal Exchange servers. The Edge Transport role provides additional security benefits, such as:
When Exchange 2013 RTM was announced on October 11, 2012, it shipped without the Edge Transport role. Customers who required their SMTP connections to terminate in the perimeter network were told they could still use Edge Transport 2007 or 2010 servers as an SMTP front-end to Exchange 2013. Since Edge Transport servers are not domain-joined it was a simple matter to subscribe these existing legacy Edge Transports servers to the Exchange 2013 front-end transport on the CAS role.
Exchange 2013 SP1 reintroduced the new 2013 Edge Transport role. Customers can continue to use legacy Edge servers with Exchange 2013 SP1+ or they can redeploy new Edge 2013 SP1 servers. By upgrading to Edge 2013 servers customers can enjoy the same cumulative update servicing schedule and support offered to their internal Exchange 2013 servers.
This Edge transport functions essentially the same as legacy versions, but it lacks an administrative interface. Edge 2013 is managed entirely using the Exchange Management Shell (EMS). This further hardens Edge 2013 servers since the IIS role does not need to be deployed. As a matter of fact, the only prerequisite software to install is the Microsoft .NET Framework 4.5 and the AD LDS role. I recommend installing Exchange 2013 SP1 on Windows Server 2012 R2 servers for the best features and security, but it can also be installed on Windows Server 2012.
Both the legacy versions and the new Exchange 2013 Edge servers include basic anti-malware protection capabilities, but with Exchange 2010 Edge servers you have the added advantage of installing Forefront Protection for Exchange 2010. That’s of questionable benefit though, since Microsoft has discontinued FPE. I have seen a marked increase in spam getting through since it was announced that FPE was being discontinued. Microsoft now recommends using the Exchange Online Protection hosted email filtering service as your primary malware solution. EOP can then forward your inbound emails to the Edge Transport servers or directly to your internal Exchange 2013 servers using TLS connections.
Exchange 2013 Mailbox servers automatically include basic anti-malware protection, but Edge Transport servers offer Recipient Filtering. The Recipient Filter agent on Edge servers processes all inbound non-authenticated messages from the Internet and treats them as external messages. This allows the Edge server to perform the following functions:
Note that while Recipient Filtering is also installed on Exchange 2013 mailbox servers, you should not configure it. Mailbox servers are unable to distinguish external messages and will block the entire message if a single bad address is detected in a message.
So when does it make sense to deploy Exchange 2013 Edge Transport servers in your organization? You may want to consider Edge servers if:
As always, you should review your organization’s email policies and requirements. Often, a security policy written years ago does not apply to today’s much more secure and hardened servers.