Living on the Edge: 6 options for connecting Exchange to the Internet

coyoteedgeWhen it comes to designing an Exchange 2010 infrastructure, one of the key design decisions you have to make is “how will the system connect to the Internet?” Microsoft has separated out the Internet connected parts of Exchange into what it calls the Edge Transport role, but you do have other options.

This post will discuss six options for deploying your edge connectivity and integrating it into your Exchange 2010 infrastructure, and include some pros and cons for each. Knowing what your options are will help you to determine what the best solution is for your system.

1. Deploy the edge transport role in the DMZ

If you follow Microsoft’s own recommendations for deploying Exchange 2010, you will build a DMZ server that does not belong to your domain, deploy it into a screened subnet/DMZ, and install the Edge Transport role. You can still manage this server’s Exchange components by subscribing it to your Exchange organization using the Edge Subscription service, but otherwise it runs as a bastion host in your DMZ.


  • This is Microsoft’s recommended solution.
  • You can still manage the server as part of your Exchange organization.


  • This requires an additional server license as well as an Exchange license.
  • If you deploy this the Microsoft way, as a DMZ server in workgroup mode, you must maintain the operating system separate from your domain.

2. Deploy the edge transport role on a TMG server

If you already have Microsoft Forefront Threat Management Gateway deployed, you can install the Edge Transport role onto your TMG server(s.) This option lets you leverage your existing TMG server(s) and also strengthens Exchange’s own defenses with Forefront TMG’s.


  • By leveraging your existing TMG server(s,) you have less operating system licenses to purchase.
  • You can still manage Exchange using the Edge Subscription.


  • If your TMG admins are not also the Exchange admins, they may not wish to do this, and it will add complexity to managing the TMG servers.
  • If you have deployed your TMG servers in a cluster, you should install Exchange Edge Transport role on both, which will require two licenses. Of course, you probably want fault tolerance with this anyway, so this may not be a big an issue.
  • Your TMG servers will require more RAM and consume more CPU resources than without Exchange.

3. Publish the edge transport role using TMG

In an ideal world without hardware or budget constraints, I would lean towards this design. You will still deploy the Edge Transport Role, but you will publish the mail protocols through your TMG infrastructure.


  • This follows Microsoft’s recommendations for dedicated Edge servers, and adds additional security by publishing them through the TMG.
  • Separates the management of TMG from Exchange, while still leveraging both.


  • This does require more hardware, and more operating system licenses than any other option.
  • When troubleshooting mail flow, there is an additional step all mail must take.

4. Deploy an mail screening appliance in the DMZ

There are lots of mail appliances on the market today, offering anti-spam, anti-malware, content inspection, logging, archiving, and more. Appliances are typically hardened, purpose-built solutions, that do what they are built to do very well.


  • You can get the best ‘bang for the buck’ from these solutions, as they are built specifically to do mail screening.
  • Appliances typically require less maintenance and administration than server based solutions.


  • These can be expensive, both to acquire and for the annual subscriptions that most require.
  • They can also require some expertise to deploy, though most vendors are happy to sell you professional services to get up and running.
  • When troubleshooting, these can be a ‘black-box.’ Make sure you look at their logging and reporting capabilities and are comfortable with that.

5. Deploy a mail screening server in the DMZ

Like an appliance, this option uses an application installed on top of a server to perform anti-spam, anti-malware, content inspection, logging, archiving and more.


  • While the cost of the server and operating system may equal or exceed appliances, the servers will generally be easier to deal with for your administrators, and could be leveraged for other services if they have capacity.
  • Windows-based applications are often more transparent, and easier to troubleshoot.


  • As a server, it needs as much maintenance as any other.
  • They also require annual subscriptions that can be costly to maintain.

6. Deploy a cloud based solution

Whether you call it Software as a Service, an outsourced solution, or a cloud based service, you are moving your mail screening offsite; having mail flow through a service provider for anti-spam, anti-malware, content inspection, logging, archiving, and more, and then delivering only clean mail to your Exchange infrastructure. This is how I do things now, augmenting my TMG services with GFI’s Max MailEdge.


  • By filtering mail before it hits your pipe, you are not worried about spam consuming bandwidth, CPU, or disk on your system.
  • These cloud providers are generally better able to screen mail at scale, making them a very cost effective solution.


  • Because content is being screened (and potentially blocked) off site, your ability to immediately check to see if an important mail has been blocked, and to release it, may be limited. While most of these service providers have options for reporting and releasing email, they are an external service. You cannot just log onto the server and check the queue.
  • Not all services offer the same degree of flexibility and customization as an in-house solution.

When it comes to your edge services for Exchange, it’s good to know that you have options. Go through an exercise to define what your minimum requirements are for your content screening solution, and then investigate each of the possibilities based on budget, flexibility, and administrative overhead, to find the one that fits for you.

Written by Ed Fisher

An InfoTech professional, aficionado of capsaicin, and Coffea canephora (but not together,) I’ve been getting my geek on full-time since 1993, and have worked with information technology in some capacity since 1986. Stated simply, if you need to get information securely from a to b, I’m your guy. I’m like "The Transporter," but for data, and without the car. And with a little more hair.


  1. david_harkler · October 18, 2011

    From a security standpoint and viewing client connectivity none of these are good.

    You have clients directly accessing internal network.

    This is a big NO-NO for every other application / service / whatever for the last 10 years or more.

    What was Microsoft thinking ?

  2. Casper Manes · October 19, 2011

    Hi David,
    Thanks for commenting, but sorry, what? This article is for connecting Exchange to the Internet, where it’s only talking about SMTP server to server connections. The author never mentioned anything having to do with clients. Let’s look again.
    1. the DMZ
    2. TMG server, which is in the DMZ and proxies connections into the internal network.
    3. TMG again
    4. …in the DMZ
    5. …in the DMZ
    6. cloud based
    How exactly do you see clients directly accessing internal network in any of these solutions? I agree that allowing Internet traffic directly into the internal network is a big NO-NO, but I don’t understand how you think that applies here. Care to elaborate?

Leave A Reply