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.
Hi Paul,
Great article as always!
I currently use 6 servers in my exchange 2010 environment in Active/Passive 3-Node DAG Datacenter Model configuration with Shared Name Space spread across 2 sites (main site and DRP site):
Main Site (4servers): 2 Mailbox Servers members of a DAG and 2 HUB/CAS servers using Windows NLB for the CAS roles
DRP Site (2 servers): 1 Mailbox Server (also member of the DAG) and 1 HUB/CAS Server
Here is my question:
I need to use the Windows Server license of one of the Exchange servers in the DRP site so I’m considering installing the CAS and HUB roles in the existing Mailbox server of the DRP site so I can re-purpose the Windows server license of the current HUB/CAS server in DRP. As far as I understand it, I can setup Mailbox, HUB and CAS to co-exist as long as NLB is not being used. Since I’m not using NLB on the DRP site, I’m thinking I should be able to deploy the HUB and CAS role in the DRP mailbox server. Do you see any issue with that?
My plan is:
1. Suspend DB replication from Main Site to DRP site
2. Install the HUB/CAS roles on existing Mailbox server of the DRP site
3. Check to make sure that Mailbox server in DRP is listed as member or DRP site CAS Array
4. Update DNS with DRP mailbox server IP for the DRP CAS array
5. Power Off DRP HUB/CAS server since these roles are now installed on the DRP Mailbox server
6. Install SSL cert on DRP Mailbox server (now hosting the HUB/CAS roles)
7. Resume DB replication
I would appreciate if you guys could tell me whether I’m going in the right direction with this. Thanks in advance!
Best Regards,
FT
Nice write-up, Paul.
Even though the CAS & Mailbox are consolidated into the Mailbox role, you can theoretically stand-up a 2016 “CAS” by simply not hosting mailbox databases on a 2016 server and having your load balanced namespace connect to those servers.
Have you had any customers/clients require that sort of configuration yet? I have not, but more organizations are looking to it now (thanks to CU1), and I have heard a number of people fret on the Internet (big surprise) about the demise of CAS as a separate role. Most of these people have some sort of security requirement (which I argue can be resolved by using the security features of their HLB).
Just curious what you’ve experienced so far and what you have recommended.
Thanks.
The Real Person!
The Real Person!
I have no idea why someone would want to do that, I don’t know what possible benefit it would achieve. No customer has suggested it to me, and I suspect any security requirement they think they’re meeting with that approach is based on misunderstand or mistaken assumptions.
The “Pointy-haired security manager”. 😛
What about the simple idea that you don’t want unsolicited TCP requests to be able to touch a server that’s hosting a mailbox database? So that if there is a compromise of that server, the database isn’t stored locally right there.
It’s the same idea as putting the database of a web application on a server that’s behind the public-facing web server. Same idea we used in Exchange Server 2003 to put non-domain joined front end servers outside the firewall, and the domain-joined mailbox servers behind the firewall.
The Real Person!
The Real Person!
You can use a reverse proxy or application firewall between the internet and your Exchange servers if you want. But there’s no Exchange architecture that supports separation of front end and backend in that manner.
Thank you for such a quick response on a two-year-old post. You must be very well organized, considering how many websites host your work! I’ve admired and benefited from your writings for many years.
Great article!
If you would go back to multirole and deploy a new multirole like said above, does the CU version matter for the last deployed server? Let’s say your CAS and MBX are still on CU3 and your new multirole would be on CU11. Will it affect anything?
And also what would best practice to leverage of the old role (CAS+MBX) servers after having moved everything to the new multirole?
Never mind the CU difference question.. Found it in a old article you posted.
https://www.practical365.com/exchange-2013-installing-cumulative-updates/
“Although this is expected and supported, it is not supported to stay in that state for a long period of time.”
So the only thing I would want to know is how to leverage of the old role servers after having moved everything to the new multi role server.