When deploying new Exchange servers it is a best practice to deploy multi-role servers.
The term multi-role may cause confusion for some people, so to be clear:
- For Exchange Server 2016, multi-role is enforced because the previously separate Client Access and Mailbox server roles have been consolidated to a single “Mailbox” server role.
- For Exchange Server 2013, multi-role means both Client Access and Mailbox server roles are installed.
- For Exchange Server 2010, multi-role means Client Access, Hub Transport, Mailbox, and (optionally) Unified Messaging roles are installed. Unified Messaging is optional because not all organizations will deploy UM, as it is not a mandatory role. Furthermore, some organizations will separate UM due to the scale of their deployment.
- For Exchange Server 2007, I hope you’re not deploying new servers today. However if you are, the same applies as with Exchange 2010.
In all of the above server versions the Edge Transport role is an exception. Edge Transport is always required to be deployed on a separate server.
The best practice to deploy multi-role servers has existed since shortly after the release of Exchange Server 2010. Today, the Preferred Architecture published by Microsoft for both Exchange 2013 and Exchange 2016 recommends multi-role servers (and, as mentioned, Exchange 2016 enforces this).
Why Do Separate Server Roles Exist if they Shouldn’t Be Deployed Separately?
The history of the server roles architecture is neatly summarised by Microsoft’s Ross Smith IV in this blog post:
In 2005, we set out developing Exchange 2007. During the preliminary planning of Exchange 2007, we realized that the server architecture model had to evolve to deal with hardware constraints, like CPU, that existed at the time and would exist for a good portion of the lifecycle of the product. The architectural change resulted in five server roles, three of which were core to the product. Our goal was to make these server roles autonomous units. Unfortunately, that goal did not materialize in either Exchange 2007 or Exchange 2010.
It certainly made sense in the days of Exchange 2007 to deploy separate server roles for mid- to large-scale customers. Often it was necessary due to incompatibility between server roles in high availability deployments. For example, when deploying an Exchange 2007 CCR cluster for high availability, the Client Access and Hub Transport roles could not co-exist with the special, clustered installation of Exchange 2007 that ran the Mailbox server role. Typically this meant deploying some servers as CAS+Hub, and some as clustered Mailbox servers. A 2+2 server deployment was quite common.
Another example is the unsupported scenario of mixing Windows Network Load Balancing (NLB) with Exchange 2010/2013 database availability group members. If a customer chose to use NLB for their load balancing, then they needed to separate the CAS role from the DAG members. Again, this often meant a 2+2 server deployment, with 2x CAS+Hub and 2x DAG members.
However, NLB is not recommended for Exchange load balancing. Although it provides a “free” load balancing option, you end up deploying more Exchange servers to align with supportability requirements, and NLB itself is a poor load balancer for Exchange due to its lack of application awareness.
So I Can Still Deploy Separate Servers if I Want To?
Sure, you can deploy separate server roles if you really want to. But all you end up with is more servers to manage. The simplest high availability deployment for Exchange is two multi-role servers in a DAG, with either a load balancer or DNS round robin for CAS high availability (DNS RR is not recommended for Exchange 2010 though).
If you chose to deploy separate roles instead, you will need at least four servers instead of two. This doubles the administrative effort to monitor, maintain and support your Exchange hosts. It also complicates troubleshooting scenarios.
Someone Told Me to Deploy Separate Server Roles?
I would question anybody who gave that advice. I’m not saying it is entirely incorrect, there may be a valid reason for that recommendation. But I would question it, and ask them to walk you through the reasons that they are deviating from best practices. If they can’t clearly explain it, ask for a second opinion from another consultant or from Microsoft.
What if I Want to Change to Multi-Role Servers?
I would deploy new multi-role servers and migrate services and data to them.
Further Reading
- Exchange 2013 Server Roles Architecture
- The Preferred Architecture (Exchange 2013)
- The Preferred Architecture (Exchange 2016)
- Why installing a multi-role Exchange 2013 server is the best option
- Robert’s Rules of Exchange: Multi-Role Servers
This article Exchange Best Practices: Deploying Multi-Role Servers is © 2016 ExchangeServerPro.com
Get more Exchange Server tips at ExchangeServerPro.com
