Many years ago, Microsoft came down from the mount and proclaimed the goodness of individual server roles. We were told that installing just the code necessary for a server to do its job was a “very good thing” and made the server “more secure” by reducing the “attack surface” exposed to hackers. Of course, this was all back in the days when Microsoft had struggled to make Exchange 2003 more flexible in a world where demands changed quickly. Exchange 2007 provided the answer by providing the option to separate out the mailbox, client access, hub transport, edge, and unified messaging server roles. All was well, even if a profusion of installation options sometimes caused furrowed brows.
That was then and we live in a different world. Now we find that Exchange 2013 simplifies the choice of server roles to just two – mailbox and client access server (CAS). The mailbox role is where most of the action happens as the CAS has been reduced to a shadow of its former self (not glory, because the CAS was never glorious) and is now essentially the traffic policeman of Exchange, busily waving connections to the right place without really doing much else.
Of course, you can argue that putting everything into the mailbox role is not simplification because that server role has so much more to do, such as all the rendering previously performed by the CAS, plus most of transport and all of unified messaging. Sounds complicated. But in fact, it’s a moot point because the vast majority of the known world ignores the presence of individual worlds and clicks through in the setup program to select the option to install multirole servers, which is what we had before in Exchange 2003. The circle of Exchange life is complete and you can throw away all those PowerPoint decks that explain at length why individual server roles are so good.
Given the propensity of administrators for multirole servers, does anyone install individual server roles now? I’m sure that quite a few do, but only in the more complex and complicated deployments where a good case can be made to deploy specialized servers. Office 365 is perhaps the best example as it uses scads of mailbox servers behind lots of client access servers.
But Exchange Online is not a good proof point for anything, unless you’re in the business (and have the money) of deploying a massive multi-tenant messaging environment. Instead, the vast majority of us will be very happy to keep on deploying multirole servers. Not, of course, because we’re lazy and can’t be bothered to contemplate the additional design issues that individual server roles bring. No, because we are IT professionals, we know that multirole servers make better use of available server hardware resources and provide better resilience against failure. More importantly, the elephant sage (Greg Taylor of Microsoft) says so, and he must be right. Greg has been making this point for months (a sad indication of the fact that I have seen him at many conferences) and now Microsoft has issued the advice in their edict on "the preferred architecture for Exchange 2013." Greg must be very happy that Ross Smith IV agrees with him. Or maybe not.
Seriously, there is something comforting in the fact that a multirole server will master most workloads that are asked of it while delivering a more robust environment. Take the example of a design where a messaging architect decides (probably after consulting various sizing tools) that ten mailbox servers and four CAS are required to handle a specific workload. In all likelihood, because the CAS requires fewer hardware resources than the mailbox role, twelve multirole servers can very probably handle the same workload. The advantage is immediately apparent for both roles. You now spread load across twelve mailbox servers (hopefully in a DAG) and have twelve CAS to handle client connections. If one server fails, you only lose 8.33% of available resources. With the other design, losing a mailbox server reduces capacity by 10%. More importantly, if you lose a CAS, 25% available capacity to handle inbound client connections is now offline.
As the preferred architecture says:
"By deploying multi-role servers, the architecture is simplified as all servers have the same hardware, installation process, and configuration options. Consistency across servers also simplifies administration. Multi-role servers provide more efficient use of server resources by distributing the Client Access and Mailbox resources across a larger pool of servers. Client Access and Database Availability Group (DAG) resiliency is also increased, as there are more servers available for the load-balanced pool and for the DAG."
The bottom line is that the default choice should always be to deploy multirole Exchange 2013 servers. Don’t complicate life when you don’t need to.
Follow Tony @12Knocksinna