Jul 08, 2014

When Microsoft released Exchange 2013 RTM back in December 2012, without an Edge Transport Server Role, many people thought that that was just Microsoft’s “rationalisation” of their server products. Remember, this was just after the time that Microsoft had pulled the plug on Essential Business Server (EBS), which had been released less than 2 years previously. When this happened, everyone was anxious with the announcements that there were to be no more editions of their “niche” products – Windows Home Server (WHS) and Small Business Server (SBS). But of course, everyone pulled up their socks and got on with life. The market changed into much more of a managed services role, Microsoft Windows Server 2012 Essentials (and now the R2 edition), teamed with Office 365, became a more than adequate replacement for SBS, and with the maturing of products like Office 365, cloud, virtualisation services, Windows InTune, and etc., a bright new world has opened up, but I digress. So getting back to the lack of an Edge Transport Server Role when Exchange 2013 was released. As I said, I thought this was a Microsoft “rationalisation” – and it wasn’t as if there weren’t any alternatives. With a little fiddling, you could still use the Edge Transport Server from Exchange 2010 or even 2007 (it was after all a “stand-alone” role – you can find a good summary here). In fact, most of the clients I was seeing were rarely implementing the Edge Transport Server Role, and instead, opted to go with a hosted alternative (Microsoft or otherwise), or one of the many software or hardware SMTP gateways available (such as new ranges of “Security Appliance” routers and firewalls from Cisco, Netgear, Watchguard and others). These have also evolved, with features such as Active Directory Integration, Spam and Malware filtering support and so on. Fast forward to February 2014 (and after 3 separate Cumulative Updates over approximately 14 months since the RTM release), Microsoft has now released SP1, which includes a new Edge Transport Server Role, but young Obi-Wan, it is not the Edge Transport Server we are used to – it has undergone a major facelift. Yes, it does perform the same feature as the previous versions. It is a standalone server designed for DMZ use, and therefore, is not a domain member, but does use AD LDS for recipient filtering, enhancing security and reducing the attack surface of your email system and so on, but it goes about things in a different way. First of all, management and configuration is purely via PowerShell cmdlets – that’s right, NO GUI. If you don’t have at least a basic knowledge of PowerShell by now, you have some catching up to do. And secondly, there are some new services, changes and updates to existing services, and as you would expect from such a role, it has a much reduced set of these services compared to the CAS and Mailbox roles. Oh, and there are also new PowerShell cmdlets and scripts, as well as cmdlets that are specific to the other roles being removed. Thankfully, setup of the Edge Transport Server Role is the same as the setup for the other roles:

1. Ensure the prerequisites are installed, which are basically the .NET Framework 4.5 and AD LDS – you can check the Edge Transport Server prerequisites here.
2. Reboot the server and start the Exchange Installation wizard.
3. In the wizard, choose whether or not you want to check for updates. Let the wizard prepare the install files and agree to the License Agreement. When choosing the recommended Settings, tick the boxes for the Edge Transport Role and Automatically install Windows Server Roles and features that are required to install Exchange Server. Let the installation run, and once it has finished, I generally reboot the server again for good luck.

So the setup is pretty much the same as previously, but remember, the configuration steps need to be done with PowerShell cmdlets. However, the steps themselves are also the same as previous installations:

1. Create a new Edge Sync Agreement and import it on a Mailbox Server (with the Hub Transport Role now defunct, the transport services are now primarily on the Mailbox Server).
2. Make sure the firewall ports 25, 50389 and 50636 are opened through to the appropriate authorised servers (and port 3389 if you intend to use remote desktop for server management).
3. Double-check that your accepted domains are correctly configured. Again, further details can be found here.

Last but not least, you can have fun configuring your Anti-Spam and/or Transport Agents on the Edge Transport Server. The image below shows a list of the agents that you can configure:

Of course, don’t forget to test your mailflow is working correctly before you finish! So after all of that, I would be interested to hear your take on this “new”-ly released Server Role – are you thinking of using this or will you go with one of the many alternatives?