Don’t put CAS in the Perimeter network!

We sometimes hear customers talking about locating Exchange 2007 or Exchange 2010 Client Access Servers (CAS) on the perimeter network (also known as the “DMZ” – Demilitarized Zone). A perimeter network is a network zone many companies deploy between the Internet and their intranet as defense-in-depth. The idea behind a perimeter network is to add additional steps to what a hacker would have to do to get access to any intranet resources. To add as strong defense-in-depth as possible, you want to put only servers you trust to withstand Internet attacks in the perimeter, and then you should assume they can be broken into anyway.

With Exchange 2000/2003, it was supported and there was documentation explaining how to put an Exchange 2000/2003 Front-End (FE) server into the perimeter network, with a firewall between the FE and the Back-End (BE) servers it accessed. This leads some customers who upgrade from Exchange 2000/E2003 to expect the same deployment pattern with Exchange 2007/2010.

As you start planning for deploying an Exchange 2007/2010 CAS server in the perimeter network, you quickly notice that there’s no documentation for how to do this though. You’ll probably even find the TechNet documentation which explains this is explicitly not supported by Microsoft. Microsoft doesn’t test or support any topologies which put firewalls between a CAS and a Mailbox (MBX) server. The only Exchange 2007/2010 role which is supported for deployment in a perimeter network, and with a firewall server separating it from other Exchange server it talks to, is the Edge Transport server role. This is true for Exchange servers talking to one another within and between Active Directory Sites.

The fact that there is no support for using firewalls between Exchange servers (except for the Edge Transport server role) sometimes causes confusion for how to use the Windows Server Firewall with Advanced Security on Exchange 2007/2007 servers. It’s supported to have the Windows OS firewall turned on for Exchange servers. In fact, we strongly recommend you leave the Windows OS firewall turned on as a defense-in-depth measure. Exchange 2010 setup is smart enough to configure the Windows OS firewall so it’ll let through all Exchange traffic appropriately. Note, for Exchange 2007 you need to run the Security Configuration Wizard and apply the Exchange 2007 role-based template. Detailed instructions can be found in Using the Security Configuration Wizard (SCW) to Secure Windows for Exchange Server Roles in Exchange 2007 docs.

Note: In Exchange 2010, it’s not required to use the Security Configuration Wizard to open the necessary ports for the Exchange 2010 server role and services running on a server. The configuration steps are included in Exchange 2010 Setup, and we don’t ship any SCW templates for Exchange 2010.

Understanding the reasons why we don’t support CAS in the perimeter

When discussing the fact that it’s not supported to put CAS in the perimeter network, the next question is obviously “why?”. If this was supported and documented for Exchange 2000/2003 Front-End servers, why not for Exchange 2007/2010 CAS?

The most important reason why customers wanted to install Exchange FE servers in the perimeter network was to block any unauthenticated traffic from reaching servers on the intranet. This is a good practice, but as you’ll see below doing this with Exchange FE/CAS servers is no longer the best way to accomplish this goal.

It is important to understand that the CAS role in Exchange 2007/2010 is significantly different from the FE server in Exchange 2000/2003.

The Exchange 2000/E2003 FE servers were there to authenticate users and proxy traffic to the BE server where the traffic was actually interpreted and responded to. For example, the FE servers in Exchange 2000/2003 don’t do any Outlook Web Access (OWA) rendering. That all takes place on the BE servers. The Exchange 2007/E2010 CAS role on the other hand contains all middle-tier logic and rendering code for processes like OWA, Exchange ActiveSync (EAS), Exchange Web Services (EWS), and more.

In the same timeframe as Exchange 2007 was available, enough customers had also started using reverse proxies (e.g. Internet Security and Acceleration server (ISA) 2000 FP1, 2004 or 2006) with functionality like pre-authentication. This meant there was now a good way to do authentication of Exchange traffic before it reached the Exchange servers. The role the Exchange 2000/E2003 FE server had played for defense-in-depth by pre-authenticating traffic before it reached servers, which included a lot of Exchange business logic, could now be better handled by these new reverse proxies. The reasons a reverse proxy like this does a better job than an Exchange FE or CAS server for this defense-in-depth role are:

  • Exchange CAS servers require full access to all mailboxes in an AD Site, and significant access rights to the AD. That’s a level of access privileged which you should avoid having in the perimeter network.
  • The Exchange FE executed a little bit of Exchange business logic, and the Exchange CAS executes a lot of Exchange business logic. The more business logic you expose in the perimeter network, the more risk you’re taking that something in that logic can be hacked. For servers you put in the perimeter network, you want to minimize the logic/code surface area they run and which is exposed to attack from the outside. Reverse Proxies are built with the primary purpose of withstanding Internet attacks like that. Although Exchange servers are also hardened from a security perspective, they run much more logic than a reverse proxy, which increases the risk.
  • Reverse Proxies are built to be put in the perimeter network or at the edge of the network. They include many security features and flexibility for customers to determine the level of defense-in-depth which is right in any particular environment. Some of these defense-in-depth features are easy to just turn on (e.g. using pre-authentication while your reverse proxy is an Active Directory domain member; or avoiding Active Directory domain membership and limiting pre-authentication capabilities), whereas other defense-in-depth features take more work (e.g. using pre-authentication without domain membership by using RADIUS). But the important distinction between the reverse proxies and the CAS is that the reverse proxies have many more defense-in-depth features and deployment models available than Exchange CAS.

In addition to these reasons why a reverse proxy does a better job in the perimeter network than an Exchange FE/CAS does, there’s also a problem with FE/CAS in the perimeter which goes away when using a reverse proxy there instead:

  • Deploying an E2000/E2003 FE server in the Perimeter network was difficult. The port settings and other internal firewall configuration required was complicated and many customers ran into problems setting this up correctly. Different types of internal firewalls required different configuration and the symptoms experienced by Internet clients when something was misconfigured weren’t always easy to diagnose. This complexity and the errors it caused was a problem for Exchange customers. The internal firewall configuration required when using a reverse proxy in the perimeter is much simpler. This is why we don’t offer “CAS in the perimeter network” as a supported solution even for customers who want to take the security risks listed above: people accidentally end up shooting themselves in the foot when trying to configure things for a FE/CAS to work in a perimeter network.

    If you are curious, the ports used between server roles by E2007 are listed in Exchange Network Port Reference.


The best way to deploy Exchange CAS with respect to a perimeter network is to put a reverse proxy you trust in the perimeter, configure the firewall between the perimeter and the intranet to be as restrictive as possible and to host the CAS server on the intranet. This will get traffic inspection and other reverse proxy security filtering in place in the perimeter.
As extra defense, you can also configure pre-authentication to be done on the reverse proxy. This might not be possible for all Exchange protocols if you want to expose some advanced functionality like Exchange 2010 Federated Free/Busy and Calendar Sharing to the Internet (see Understanding Federation and Understanding Federated Delegation for details about these features). But you can configure the pre-authentication for as many clients and protocols as is supported by the reverse proxy and the scenarios you want to enable.


Kristian Andaker, Jason Henderson

Comments (12)
  1. Keosaki says:

    Great and informative post !! and thanks a lot

    I have one concern though. I have worked with many exchange 2007 server installs and troubleshooting.

    I remember many issues that got resolved by  putting the Windows firewall off (both public and private profile).

    In the above article it is mentioned that it is recommended to keep the windows firewall on.

    I think in theory its a good a idea to consider keeping the windows firewall on but i think there are still some bugs in exchange 2007 code which gets resolved by disabling the windows firewall.


  2. Jeff Guillet says:

    Good article!  I had to make the same arguments for not putting the CAS in the DMZ for a customer last week.  I backed up my arguments with

  3. I agree with Keosaki. Many errors on E2K7 CCR with Windows Firewall on. Especially when performing a cluster failover: I think the cluster service wants to dynamically map RPC ports which are being blocked by Windows Firewall.

    "The fact that there is no support for using firewalls between Exchange servers (except for the Edge role) sometimes causes confusion for how to use the Windows OS firewall on Exchange. It is supported to have the Windows OS firewall turned on for Exchange servers.": Sure, there are differences between a hardware FW and Windows FW but their functionality is the same. Is there documentation on how to configure E2K7 CCR with Windows FW on while performing a failover without errors?

    Regards, Martijn

  4. Vivian says:

    The fact that there is no support for using firewalls between Exchange servers (except for the Edge role) sometimes causes confusion for how to use the Windows OS firewall on Exchange. It is supported to have the Windows OS firewall turned on for Exchange servers.": Sure, there are differences between a hardware FW and Windows FW but their functionality is the same. Is there documentation on how to configure E2K7 CCR with Windows FW on while performing a failover without errors?

  5. Chris Lehr says:

    Pingback from:

    Great information and talking points.  I have a few customers really sticking to their guns on DMZ CAS.

  6. John says:

    Pingback from:

    Another GREAT post!  Good info that needs to be shared and understood.

  7. Mikael says:

    This is not true – The HMC 4.5 implementation states the use of Zones and places the CAS and MBX in different zones.

  8. Brian says:

    This entry should definitely have been titled "Don’t put baby in the corner!"

  9. Kristian Andaker says:

    Thanks for all the comments!

    Keosaki, Martijn and Vivian: I know there have been issues challenges using the Windows on-box Firewall with some E2007 scenarios. Although our ambition has been to allow customers to keep the Windows Firewall running, I know there are cases when it was just simplest to turn it off.

    We have made improvements in this area in E2010. So I hope you’ll no longer see a need to turn off the Windows Firewall.

    Mikael: HMC supports a subset of E2007 scenarios, and adds some more scenarios to the HMC-specific supported list. Although HMC may support the scenario above, the same is not true for non-HMC deployments of E2007 or E2010.

    For those who wonder what "HMC" ("Hosted Messaging and Collaboration") is, it’s a special set of Microsoft product SKUs used by companies who host our products (e.g. Exchange) for use by other end-customers. For instance, a telecom operator might host Exchange to provide email service to their telephony end customers.


  10. sdukart says:

    With E2K7 is there anything documented in regards to best practices based on the following setup:

    Firewall: Hardware/Appliance

    Server 1: DMZ – Edge Transport

    Server 2: Inside – CAS/Hub Transport

    Server 3: DC/GC

    *All Servers are running Windows Server 2008 64bit.

    *Connector from HT to ET to Internet and Internet to ET to HT for mail delivery.


    1. Based on the mentioned Connector information/email flow, is this still best practice where port is only opened to DMZ (Internet/ET/HT : HT/ET/Internet) or is it now recommended to punch a hole through the Firewall straight to the HT internally and sent from the HT externally (Internet/HT : HT/Internet)?

    2. Where does Forefront GTM fit into this picture (add to DMZ – Edge Transport server or setup on separate server e.g. Server 4: DMZ – Forefront GTM)?  Publish E2K7 with FfGTM to allow for OWA or is it not recommended to allow OWA externally anymore and only use Outlook Anywhere via the ET?


  11. Joshua Goodin says:

    Does the Edge server funnel CAS traffic through it?  Does it act as a front end for all exchange related services?  We already have an ironport in the DMZ, but my manager wants to put an edge server in the DMZ as well since he doesn’t want our CAS server to be internet-facing.  

Comments are closed.