Does anyone care that the Exchange 2013 Edge Transport server role came back?

When Microsoft shipped Exchange 2013 RTM, they forgot to include the Edge Transport (ET) role in the set available for deployment. Or maybe they omitted the Edge Transport role on purpose. In any case, customers were instructed that they could continue to use Exchange 2010 Edge Transport servers and all would be well. And it was. That is, if you ignore the complaints.

Well, Exchange 2013 SP1 brought the Edge Transport server role back to life. Apart from losing anti-virus checking, the new version basically provides the same functionality as its Exchange 2010 counterpart using the Exchange 2013 code base. Anti-virus checking is now performed on the Exchange 2013 mailbox server. However, the single-engined anti-malware capabilities bundled into the mailbox server might not be sufficient to meet your requirements. In this case, you can look at deploying an anti-virus appliance or running the inbound mail stream through a cloud anti-spam service.

The big difference that everyone seems to be focused on is that the newly-revitalized server has no graphic interface (see this blog post by MVP Jaap Wesselius for more information on how to configure an Exchange 2013 Edge Transport server). Management must be performed through PowerShell, a development that has caused apoplexy for some. Nothing has happened in the three cumulative updates since to provide a GUI, so command-line is the way forward for the Edge.

It  seems clear that the delay in shipping Exchange 2013 Edge Transport is down to two things. First, Microsoft had to figure out whether anyone wanted to use the blessed thing. Second, they had to figure out how to replace the MMC-based Exchange Management Console (EMC) used by Exchange 2010 without using all the IIS bits that are needed to make the Exchange 2013 Administration Center (EAC) work. You don’t want IIS all tarted up and fully functional on a server that’s going to live outside the DMZ, do you? Or perhaps you like exposing a full attack surface to potential hackers.

So Exchange 2013 ET behaves like an appliance and requires you to get down and dirty with PowerShell to configure the connection between it and the Exchange organization with which it will communicate. I’ve heard people say that administrators don’t like PowerShell but regard this as so much old rubbish. If people working with Exchange can’t open up PowerShell and hold their noses while they type out some commands, then they should probably be strongly considering a new career choice. Perhaps they can go work on Office 365 migrations as I hear that this is a strong area of growth these days.

Yes, PowerShell syntax is sometimes esoteric not to say downright strange. Yes, it’s a throwback to a time when command-line management interfaces were all the rage. And no, you can’t pick up odd Linux-type diseases if you go too close to PowerShell. A good shower will restore you to a fine state of health. Besides, setting up Egde Transport servers is pretty much a one-time operation that should take no more than an hour, including creating the Edgesync subscription. I think pretty well everyone can cope with an hour’s exposure to PowerShell.

The hoo-hah about the lack of a GUI is pretty much hot air when it comes to considering what’s important about the Exchange 2013 ET. I think that asking whether this server role is still required is a lot more important. And as it turns out, I think that Edge Transport is still needed in some situations.

The most obvious reason is that having an Exchange 2013 Edge Transport allows an organization to run the same version of Exchange across all server roles. This isn’t terrifically important, but it is usually better when the same version of any software is used everywhere.

Another is that some get a warm feeling of contentment knowing that all of their email system comes from a single source. Given the use of hardware appliances (like load balancers) with Exchange today this shouldn’t be a huge factor, but it’s surprising that it is in some places.

The third is that some companies use Edge Transport servers between their Exchange servers and other mail servers in the organization, including in a hybrid organization where mail flows to Office 365.

Another is that the Edge Transport role has good recipient filtering capabilities that leverages the information about users contained in Active Directory and synchronized to the Edge server through its subscription to an Exchange organization. 

These are probably the most common reasons but I am sure there are others. In fact, I’m sure that I will be told. 

But any of these reasons fail if Microsoft cannot deliver an Edge Transport server that contains the capabilities required by customers.  Given the step back in Microsoft’s commitment to on-premises security products with the cutting of TMG and UAG to focus on cloud-based security offerings such as Exchange Online Protection (EOP – which they need for Office 365), a certain suspicion exists that the late appearance of the Exchange 2013 Edge Transport is just another sign that this is another security product that might be strategically discontinued. I’m not saying that this will happen, just that I have heard people saying that they think it will be. It’s definitely not information of a sufficient quality and reliability to make a bet upon.

What’s probably more pertinent is whether better alternatives exist. Vendors who specialize in email hygiene appliances like those made by Cisco IronPort or Barracuda will make the case that they do a better and more cost-effective job of cleansing an inbound mail stream, albeit without the synchronization of Active Directory and safelist information that is done by ET. I see lots of value in these products and they are certainly worth considering as bastion servers.

By this time you might wonder why you would ever want to upgrade Exchange 2010 Edge Transport servers. After all, these servers work perfectly happily with Exchange 2013. One answer is that the Exchange 2013 variant shares the same code base as the other Exchange 2013 server roles. More importantly, you can install the Exchange 2013 Edge Transport on Windows 2012 R2. And because it is recent software, Microsoft will support it longer. I admit that collectively these reasons do not make a compelling argument.

Note that you can use Exchange 2013 Edge Transport servers with an Exchange 2010 infrastructure - as long as the Exchange 2010 servers are running SP3 RU5 (or later).

The Exchange 2013 Edge Transport does the job that Microsoft has designed it for, which is not to be the primary line of defense against viruses and other malware (spam is blocked, however). It's worth pointing out that only the Exchange 2013 mailbox role includes an anti-malware engine, limited as it is. Even so, the features delivered by the latest ET just might match your requirements and if so, you’ll be happy that Exchange 2013 SP1 has brought the role back. On the other hand, alternatives exist, so look around before you make your mind up.

Follow Tony @12Knocksinna