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.




Register Azure AD Pass-through agent manually

Filed under: Azure AD,PowerShell — Thomas Stensitzki at 1:26 pm on Monday, February 10, 2020

Azure AD Pass-through authentication (PTA) recommends that you run at least three authentication agents to provide high availability for authentication.

When you download and install the PTA agent, registering the PTA agent to Azure AD might fail. This happens most of the time when the network connectivity to Azure AD requires the use of a proxy server. In such a network setup you normally encounter configuration errors only, if the proxy server is misconfigured or the Internet Explorer zone configuration is missing required entries for trusted sites.

When you encounter an error during installation and registration of the dedicated PTA agent I recommend to separate these two steps. You need the credentials of an Azure AD account that is a member of the Global Administrator management group.

  1. Download the most current release of the PTA agent:
  2. Copy the downloaded file to the server that will serve as a PTA agent
  3. Open an administrative command prompt and install the PTA agent software in silent mode without registering the agent:
AADConnectAuthAgentSetup.exe REGISTERCONNECTOR="false" /q
  1. Open an administrative PowerShell session, navigate to the default installation location and register the PTA agent manually
# navigate to the default installation location
cd "C:\Program Files\Microsoft Azure AD Connect Authentication Agent"

# enter the global admin credentials
$cred = Get-Credential

# register the PTA agent using the RegisterConnector.ps1 script
# multiline example
.\RegisterConnector.ps1 `
-ModulePath "C:\Program Files\Microsoft Azure AD Connect Authentication Agent\Modules\" `
-ModuleName "PassthroughAuthPSModule" `
-AuthenticationMode Credentials ` 
-UserCredentials $cred `
-Feature PassthroughAuthentication

The Azure AD Pass-through agent Quickstart documentation has an example for automating the installation of the PTA agent as part of a server provisioning process. The current example references the wrong PowerShell module named AppProxyPSModule. The most recent release of the PTA agent does not contain a PowerShell module by that name. Use the PowerShell module PassthroughAuthPSModule, as shown in the PowerShell example shown above.


The automation example shown here, stores the account password in cleartext. This is not the best solution for running an IT-infrastructure with enhanced security. Do not use clear text passwords in PowerShell script. Never.

One example on how to use proper password encryption is shown in this blog post by Dennis Span:






Thomas’ Tech Talk YouTube Channel

Filed under: Exchange Server,Tech Talk — Thomas Stensitzki at 8:56 am on Friday, February 7, 2020

My new Tech Talk YouTube Channel (German) is online.

I have published the first talk this week, covering the migration options for Exchange Server 2010. The upcoming end-of-life of Exchange Server 2010 on October 13th 2020 brings some challenges to Exchange organisations still running on 2010.



Exchange Environment Report – V2 – updated

Filed under: Exchange Server,PowerShell — Thomas Stensitzki at 6:54 pm on Monday, January 27, 2020

The PowerShell script for generating an Exchange Environment Report has been updated to version 2.2.

The changes for this version are:

  • Bug fixes and enhancements
    • CCS fixes for Html header tags (issue #5)
    • New script parameter ShowDriveNames added to optionally show drive names for EDB/LOG file paths in database table (issue #4)
    • Exchange organization name added to report header


The PowerShell source is available at GitHub and TechNet Gallery: