Back in 2014, Paul Cunningham wrote about the Exchange 2013 Edge Transport Server. Time goes by, and new versions of Exchange Server mean that it’s good to review the current position up to and including Exchange 2019. This article discusses using the Exchange 2019 Edge Transport server role in an on-premises environment.
The Edge Transport Server
The Edge Transport server is used as a smart host in an Exchange environment. Exchange 2019 Mailbox servers run in an internal network, and the Exchange 2019 Edge Transport servers are in the DMZ network. The Edge Transport servers allow the Exchange 2019 Mailbox server to send email over the internet.
The mailbox servers send outbound e-mails to the Edge Transport servers, and the Edge Transport servers deliver the e-mails directly to the recipient’s mail server. For inbound e-mail, an external mail server connects to an Edge Transport server, which routes the e-mail to the appropriate mailbox servers (Figure 1).
Installing the Edge Transport Server
Exchange 2019 Edge Transport servers are supported on Windows Server 2022 and Windows Server 2019. The .NET Framework 4.8 and the Active Directory Lightweight Directory Server (ADLDS) server role must be installed on Edge Transport servers. For troubleshooting purposes, I always recommend installing the Telnet client feature too.
When installed in the DMZ network, the Edge Transport servers cannot be members of the internal Active Directory. For management purposes, the servers can be members of a DMZ Active Directory. Active Directory membership is not mandatory for Edge Transport servers because they can run as stand-alone servers without a problem.
When installing an Edge Transport server, the installation process automatically configures the server with a self-signed certificate. While this is sufficient for setting up an opportunistic TLS connection, it cannot validate a server. To validate a server, you must install a third-party certificate. When a certificate is installed on an edge transport server, you can use an online tool like checktls to check that everything works. An example output of this tool is shown in Figure 2.
If the Edge Transport server uses an incorrect certificate, the test succeeds but shows a yellow-colored FAIL in the Cert box.
When you enable a certificate on an Exchange 2019 server, you will see the question: Overwrite the existing default SMTP certificate?’. Choose ‘No’. The default self-signed certificate is used for Edge Synchronization, which is the communication from the mailbox servers to the Edge Transport servers. An example of enabling the certificate is shown below.
Get-ExchangeCertificate -Server azedge01 -Thumbprint 8B58CE425DA7BBB20CE789E2794DC7C571D5AE9E | Enable-ExchangeCertificate -Server azedge01 -Services SMTP Confirm Overwrite the existing default SMTP certificate? Current certificate: 'BBF604BC232C57F9FC9BE4260D906D056EB9D9FD' (expires 8/1/2028 2:11:28 PM) Replace it with certificate: '8B58CE425DA7BBB20CE789E2794DC7C571D5AE9E' (expires 8/1/2024 1:59:59 AM) [Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"): N
Edge Synchronization
The Exchange 2019 Edge Transport servers have knowledge of the internal Exchange organization. The servers retrieve this information using a process called Edge Synchronization. Using Edge Synchronization, the Mailbox servers push information about the organization to the Edge Transport servers. This is a one-way communication where only information from the Mailbox servers flows to the Edge Transport servers. No information is sent from the Edge Transport servers to the Mailbox servers.
Edge Synchronization uses port 50636 to communicate with the Edge Transport servers, so make sure this port is open on the firewall. The port only needs to be open outbound.
Edge Synchronization is configured for each Edge Transport server. So, if you have four Edge Transport servers, there are four Edge Synchronizations.
An Edge Synchronization is created on the Edge Transport server using Exchange PowerShell. An XML file is created on the Edge Transport server and this XML file is imported by a Mailbox server. An example of the PowerShell command to create a new Edge subscription file is shown below.
[PS] C:\>New-EdgeSubscription -FileName C:\Install\Edge01.xml
An Edge Subscription file is only valid for 24 hours (1440 minutes) and you must import this file within this timeframe on a Mailbox server. When creating an Edge Subscription file, you will see a warning message about the 1440 minutes, and you must select Yes to continue. Copy the xml file to an Mailbox server from where it will be imported using Exchange PowerShell. An example to import this XML file in a Mailbox server in the default Active Directory site is shown below.
[byte[]]$File = Get-Content -Path "C:\Install\Edge01.xml" -Encoding Byte -ReadCount 0 New-EdgeSubscription -FileData $File -Site "Default-First-Site-Name" Name Site Domain ---- ---- ------ AzEDGE01 labs.local/Config... Exchangelabs.nl WARNING: EdgeSync requires that the Mailbox servers in Active Directory site Azure be able to resolve the IP address for AzEDGE01.Exchangelabs.nl and be able to connect to that host on port 50636.
After a couple of minutes, you can start the Edge Synchronization process on the Mailbox server using Exchange PowerShell. For example:
[PS] C:\>Start-EdgeSynchronization RunspaceId : 6e906aa3-4f07-44f5-8be4-4e8bd4e01359 Result : Success Type : Recipients Name : AzEDGE01 FailureDetails : StartUTC : 8/10/2023 12:39:08 PM EndUTC : 8/10/2023 12:39:08 PM Added : 0 Deleted : 0 Updated : 0 Scanned : 0 TargetScanned : 0 RunspaceId : 6e906aa3-4f07-44f5-8be4-4e8bd4e01359 Result : Success Type : Configuration Name : AzEDGE01 FailureDetails : StartUTC : 8/10/2023 12:39:08 PM EndUTC : 8/10/2023 12:39:08 PM Added : 0 Deleted : 0 Updated : 0 Scanned : 0 TargetScanned : 0
Information about the internal Exchange organization is now pushed to the Edge Transport server.
The Edge Synchronization is Active Directory site bound. This means that an Edge Transport can only service Mailbox servers in a specific site. In this example, it is the Active Directory site ‘Default-First-Site-Name’ but it can be any Active Directory site in your organization. In my lab environment I have two Active Directory sites. Next to the ‘Default-First-Site-Name’ I have a second Active Directory with Exchange 2019 servers running in Azure. Both Active Directory sites have Edge Transport servers bound to Mailbox servers in their respective Active Directory sites.
When retrieving the Exchange servers using PowerShell run on an Mailbox server, the Active Directory site configuration is clearly visible as shown below.
[PS] C:\>Get-ExchangeServer | Select-Object Name,Site,ServerRole | Sort-Object Site Name Site ServerRole ---- ---- ---------------------- AzExch01 labs.local/Configuration/Sites/Azure Mailbox AzExch02 labs.local/Configuration/Sites/Azure Mailbox AzEDGE01 labs.local/Configuration/Sites/Azure Edge EXCH01 labs.local/Configuration/Sites/Default-First-Site-Name Mailbox EXCH02 labs.local/Configuration/Sites/Default-First-Site-Name Mailbox SMTPHOST labs.local/Configuration/Sites/Default-First-Site-Name Edge
Exchange 2019 Use Cases
In the Exchange 2010 timeframe, there were sufficient anti-spam solutions available for the Edge Transport server to host an on-premises message hygiene solution, but this is no longer the case. Most anti-spam solutions have moved to cloud-based solutions where Edge Transport server is located between the mailbox servers and the cloud-based service. An example with an Edge Transport server and Exchange Online Protection is shown in Figure 3.
Another scenario is an Exchange 2019 hybrid environment, where user mailboxes are in Exchange Online and in Exchange 2019. By default, in this scenario, users with Exchange Online mailboxes send e-mail to the mail server on the Internet using the default Outbound Connector in Exchange Online. Exchange 2019 mailboxes send e-mail via the Exchange 2019 Edge Transport server to the external recipient’s mail server on the Internet. These e-mails are not routed via Exchange Online Protection. Cross-premises e-mail messages within the same organization are sent via the Edge Transport servers to Exchange Online.
The MX record for the domain points towards Exchange Online. When a recipient is in Exchange 2019, Exchange Online forwards e-mail to the Edge Transport server, which sends it to the Exchange 2019 mailbox server. This is shown in Figure 4.
Summary
The Exchange 2019 Edge Transport server is Microsoft’s solution for an on-premises smart host. The Exchange 2019 Edge Transport server is installed in an organization’s DMZ network when the organization does not allow direct connectivity with the Mailbox servers. I see the Exchange 2019 Edge Transport servers often between the internal Exchange 2019 mailbox servers and Exchange Online in a hybrid scenario, but of course, they can be used with other cloud-based message hygiene solutions as well.
On Demand Migration
Migrate all your workloads and Active Directory with one comprehensive Office 365 tenant-to-tenant migration solution.
Hello
as an architect for more than 20 years, I sincerely believe that the decision to implement Edge services should really be studied. Edge solutions are “better than nothing” and frankly can’t compare with DMZ relays such as Ironport for example. It’s a bit like comparing Windows NLB and F5.
As I’ve seen on a number of occasions, their maintenance in operational conditions is sometimes complex, especially in the case of bounce problems. Unfortunately, in a hybrid situation, if you want to be supported by MS, you need Edge servers.
Personally, I’m not a big fan.
Laurent TERUIN | MVP | https://unifiedit.wordpress.com/