Exchange, Firewalls, and Support… Oh, my!

Published Feb 18 2013 06:00 AM 230K Views

Over the years Exchange Server architecture has gone through a number of changes. As a product matures over time you may see us change what is supported as we react to changes in the product architecture, the state of technology as a whole, or major support issues we see come in through our support infrastructure.

Over the years a large volume of support calls have ended up being caused by communication issues between Exchange servers or between Exchange servers and domain controllers. Often times this results from a network device between the servers not allowing some port or protocol to communicate to the other servers.

I tried to get Harrison Ford to co-write this article with me given his specific talents, but alas he was busy and regretfully couldn’t partake. Please allow me to start with the short version up front so there is no confusion about what we currently DO and DO NOT support before I lose some of you to;

Image Courtesy of:

Starting with Exchange Server 2007 and current as of Exchange Server 2013, having network devices blocking ports/protocols between Exchange servers within a single organization or between Exchange servers and domain controllers in an organization is not supported. A network device may sit in the communication path between the servers, but a rule allowing “ANY/ANY” port and protocol communication must be in place allowing free communication between Exchange servers as well as between Exchange servers and domain controllers.

For Exchange Server 2010 this is already articulated at under Client Access Server Connectivity in the Client Access Server section in the following paragraph.

“In addition to having a Client Access server in every Active Directory site that contains a Mailbox server, it’s important to avoid restricting traffic between Exchange servers. Make sure that all defined ports that are used by Exchange are open in both directions between all source and destination servers. The installation of a firewall between Exchange servers or between an Exchange 2010 Mailbox or Client Access server and Active Directory isn’t supported. However, you can install a network device if traffic isn’t restricted and all available ports are open between the various Exchange servers and Active Directory.”

Why has this seemingly simple support statement become so muddied and confusing over the years? Maybe we didn’t make it blunt enough to start with, but there could be some other compounding points adding to the confusion.

Confusion point #1…

Exchange Server 2003 was the last version of Exchange Server to allow deploying (at the time) a Front-End server in a perimeter network (aka DMZ) while locating the Back-End server in the intranet. While this could be made to work it required a specialized set of rules that essentially turned your perimeter network security model into the following:

Image Courtesy of: The Internet

During the time of Exchange Server 2003 adoption of reverse proxies within perimeter networks was on the rise. Reverse proxies allowed customers to more securely publish Exchange Server for remote access while only allowing a single port and protocol to traverse from the Internet to the perimeter network, and then a single port and protocol to traverse from the perimeter network to the intranet.

You could go from something complicated like this with endless port and protocol requirements….

Figure 1: Legacy Exchange 2003 deployment with Front-End server in a perimeter network. What a mess. Who’s hungry?

To something simple like this…

Figure 2: Reverse proxy in the perimeter network and all Exchange servers within the intranet. Simplicity at its best!

The resulting increase in simplicity as well as the drop in support cases was strong enough for Microsoft to determine during the lifecycle of the next major version of Exchange Server, 2007, that we would no longer support deploying what is now the Client Access Server role in a perimeter network. From that time on all Exchange servers, except for Edge Transport Server role, were to be deployed on the intranet with unfettered access to each other. We do have this documented in

Confusion point #2…

TechNet includes a number of articles that document many if not all of the ports and protocols Exchange Server utilizes during the course of normal operation. These documents are often misunderstood as “configure your firewall this way” articles. The information is only being provided for educational purposes on the inner-workings of Exchange Server, or to aid with the configuration of load balancing or service monitoring mechanisms which often require specific port/protocol definitions to perform their functions correctly. In case you come across them in the future, here is a list of most of those articles.

Exchange Network Port References

Understanding Protocols, Ports, and Services in Unified Messaging

I don’t trust my clients and I like restricting their access. Is that supported?

This is a different story and yes there are things you can do here to remain supported. Exchange Server has for a number of revisions supported configuring static client communication ports for Windows based Outlook clients. After the client contacts the endpoint mapper service running on Windows under TCP Port 135 it will be handed back the static TCP port you have chosen to use in your environment. For Exchange Server 2010 you may be familiar with the following article describing how to configure static client communication ports for the Address Book Service and the RPC Client Access Service, thereby leaving you with 4 ports required for clients to operate in MAPI/RPC mode.

  • TCP 135 for the Endpoint Mapper
  • TCP 443 for Autodiscover/EWS/ECP
  • TCP <your choice #1> for the Address Book service
  • TCP <your choice #2> for the RPC Client Access service
  • UDP ANY from CAS to the Outlook 2003 client if you’re in online mode and utilizing UDP notifications.

TechNet also has resources for versions prior to Exchange Server 2010:

Starting in Exchange Server 2013 the only protocol supported for Windows Outlook clients is RPC over HTTPS. This architectural change reduces your required port count to one, TCP 443 for HTTPS, to be utilized by Autodiscover, Exchange Web Services, and RPC over HTTPS (aka Outlook Anywhere). This is going to make your life easy, but don’t tell your boss as they’ll expect you to start doing other things as well. It’ll be our secret. Promise. I’ll go through some examples of supported deployments, but will keep it easy and only use Outlook clients. The same ideas apply to other POP/IMAP/EAS clients as well, just don’t restrict Exchange servers from talking to each other. A setup like the following Outlook 2010 / Exchange 2010 diagram would be entirely supported where we have a firewall between the clients and the servers. In all of the following examples I have chosen static TCP port 59531 for my RPC Client Access Service on CAS and Mailbox, and static TCP port 59532 for my Address Book Service on CAS. UDP notifications are also thrown in for fun for those of you running Outlook 2003 in Online Mode, which I hope is very few and far between these days. Domain controllers were left out of these diagrams to focus on communication directly between clients and Exchange, and load balancers were also kept out for simplicity.

Figure 3: Firewall between clients and all Exchange servers. Supported if firewall is configured correctly to allow all necessary client access. AD not shown.

However, if you attempted to do something naughty like the following diagram and for reasons unknown to us put a firewall between CAS and Mailbox then there had better be ANY/ANY rules in place allowing conversations to originate from either side between Exchange servers.

Figure 4: Firewall between CAS and other Exchange servers. Supported only if the firewall is configured for unfettered access between Exchange servers, and Exchange servers and AD. AD not shown.

Well what if you have multiple datacenters with Exchange and want to firewall everything everywhere because you believe that as the number of firewalls goes up your security must exponentially increase? We’ve got you covered there too, deploy it like this where you’ll see both MAPI/RPC and RPC/HTTPS user examples. I didn’t bother putting load balancers or Domain Controllers into any of these diagrams by the way. I’m putting faith in all of you that you know where those go.

Figure 5: Firewalls between users and Exchange servers as well as between datacenters. Supported if the firewalls are configured to allow unfettered access between Exchange servers, between Exchange servers and AD, and appropriate client rules. AD not shown.

Boy this is going to be easy when all of you migrate to Exchange Server 2013 and are only dealing with RPC/HTTPS connections from clients and SMTP or HTTPS between servers. Except for maybe those pesky POP/IMAP/UM clients…

Figure 6 below depicts what Exchange 2013 network conversations may look like at a high level. A load balancer and additional CAS were introduced to show we don’t care what CAS a client’s traffic goes through as they all end up at the same Mailbox Server anyways where the user’s database is mounted. You may have read previously Exchange Server 2013 does not require affinity for client traffic and hopefully this visual helps show why.

The one tricky bit to consider if placing a firewall in between clients and Exchange Server 2013 would be UM traffic as it is not all client to CAS in nature. In Exchange Server 2013 a telephony device first makes a SIP connection through CAS (orange arrows) which after speaking with the UM Service on Mailbox Server will redirect the client so it may establish a direct SIP+RTP session (blue arrow) to the Mailbox Server holding the user’s active database copy for the RTP connection.

Blog - Exchange and Firewalls - 2013
Figure 6: Showing at a high level SMTP, Windows Outlook Client, and UM traffic with a firewall between users and Exchange Server 2013.

So, Microsoft, if you’re saying this should be simple then what can I do and remain in a supported state?

The key here is to not block traffic between Exchange servers, or between Exchange servers and Domain Controllers. As long no traffic blocking is performed between these servers you will be in a fully supported deployment and will not have to waste time with our support staff proving you really do have all necessary communications open before you can start to troubleshoot an issue. We know many customers will continue to test the boundaries of supportability regardless, but be aware this may drag out your troubleshooting experience and possibly extend an active outage. We prefer to help our customers resolve any and all issues as fast as possible. Staying within support guidelines does in fact help us help you as expeditiously as possible, and in the end will save you time, support costs, labor costs, and last but not least aggravation.

Brian Day
Program Manager
Exchange Customer Experience

Not applicable

Thank you Brian. This will help to shorten further discussions.

Not applicable

Interesting article, should help explain clients some misunderstanding. Thanks

Not applicable

Have you ever though about writing simple ResKit tool which you could run (no installation, just running .exe). Then the program reads from AD all required information and verify all required the connectivities, speed and aveilability.

....or even better, if the Exchange can do regular health checks by itself and report to results to administrators.

Not applicable

Dear Brian,

Great post! that's exactly what I needed today!

My customer (<1000users) also insist that separating Exchange roles will improve security, could you clarify this please.


Not applicable

Just to double-check, does the "don't block traffic" rule also apply when you have an edge transport server in your DMZ? That would seem to defeat the purpose of separating that server in the first place.

Not applicable

@John, Edge Transport would be the exception to the rule here as it is expected there will be filtering due to it living in the perimeter network. Maybe we'll update the article with a better ET graphic as well depicting EdgeSync, Mailflow, etc...

Not applicable

Excellent article Brian, pity that we cannot tell our customers to "just put a TMG in the DMZ" which is how I've always resolved any debates regarding secure client access.  Those were the days ...

Not applicable

Thanks for this great article. Helped me to solve a lot of issues in a multi site enviroment.

[OFF] Loved the picture with cheese and spaghetti [/OFF]

Not applicable

Great post Brian :)

Not applicable

With the retirement of TMG last year, what are we to do now for secure outside client access?

Not applicable

@Kevin, there are still options each customer can consider based on their individual needs. As far as Microsoft based solutions if you already own TMG then absolutely keep using it as it is supported through April 14th 2020. You may also consider Microsoft UAG, Direct Access, or other third party solutions. It will all depend on what client types you need to support and if you do/don't want to utilize features such as but not limited to pre-authentication, Certificate Based Authentication, or other feautres.

Not applicable

How does this come into play if you use client based firewalls? What is the support statement around firewalls on Exchange servers? If the rule set is in compliance does that work?

Not applicable

@James, the concept is the same if it is a software firewall or a hardware firewall intercepting/inspecting the traffic. You'll also notice we require the Windows Firewall Service to be running on the sever where you install Exchange so we can set the proper exceptions. You may have the Windows firewall disabled if you so choose (I see less and less of that happening now), but the service itself must be running for installation to succeed.

Not applicable

Thanks Brain - The Cat reminded me of Ross Smith as he wrote earlier RPC cross-site and later at the end realized its you in this one.

This article has refreshed me and again Thanks for your consolidated references(It is informative). Exchange is improving better over the years.

Not applicable

Awesome post Brian.

Not applicable

Hello Brian,

thanks for this great post!

I'd have two more detailled questions for which I don't find a specific answer in your post, it would be great if you could answer these:

First: Is the "ANY to ANY between Exchange and DC" rule sufficient if implemented for all DCs of the AD site where the Exchange server is assigned to, or does it need this rule to all DCs of his AD domain, regardless of the site? What about a root domain in a forest, or DC's with forest-wide FSMO roles in another domain as the Exchange Server - Exchange 2003 also wanted some ports open to these?

Second: Is the "ANY to ANY between Exchange server" needed for all Exchange servers between all AD sites? I do understand that it is needed between all Exchange servers in one AD site, and between all CAS-Servers (regardless of site) and between all HUB-Servers (regardless of site). But are connections between Mailbox role servers in different sites (and different DAGs) really needed? Which communication happens there? And between CAS Servers or HUB Servers of one site and Mailbox role servers of another site (when the CAS is not in an CAS array responsible for the Mailbox server, and the HUB is not configured to serve the databases of the Mailbox server)?

Thanks for a short answer for these questions (or pointing me to where I missed the answers)

(sorry if I sent this two times, but the browser lost connection when sending it the first time and I'm not sure now if it is sent)

Not applicable

@Florian, the short answer is "everywhere". Exchange has the capability of reaching outside of its own AD site and its own domain to contact resources if necessary and you don't want things that normally work suddenly go *boom* when it hits a situation requiring out-of-site or out-of-domain resources. I'm making some assumption in my next sentence that may not apply to everyone. If you can, the best thing you can do is create an "Exchange Servers" resource group and a "Domain Controllers" (which includes GCs) resource group in your firewall central management software. Once the groups are created push out a rule so those resource groups can ANY/ANY each other. As you add new servers to the environment you include a step in your server provisioning process to add them to the appropriate FW resource group. I know some of you will read this and try to be tricky and do something like create rules for the local AD site and AD sites once removed via AD site link, but do me a favor and don't. :)

Not applicable

Hi Brian,

thanks for yor answer - I hope I can convince my colleagues from the firewall and the AD team ;)

Not applicable

Is there anyway of putting "only" OWA in the DMZ zone - Exchange 2010?  If so does anyone have procedures for this?

Not applicable

Thanks for update Brain , seriously its very helpul document.  

Not applicable

Any update on an available Exchange Network Port Reference for Exchange Server 2013?

Not applicable

@Mitchell: We're working on it, will announce when it's released.

Occasional Visitor


Version history
Last update:
‎Jul 01 2019 04:11 PM
Updated by: