Why installing a multirole Exchange 2013 server is the best option

Simplification is usually a good thing. Following this role, choosing to install the simplest server configuration is usually a good thing for an Exchange deployment. Exchange 2013 only has two server roles and the best and simplest approach is to elect to install a multirole server. Why? Because it's simplest (and more resilient).

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

Discuss this Blog Entry 1

on May 2, 2014

Tony, thank you for sharing this information. You see, it is not immediately obvious what the preferred architecture is for each Exchange Server version. Your blog post, Ross Smith IV's blog post and Greg Taylor spell out what the preferred architecture is for each Exchange Server 2013.

In the past and in the future, things may not be like that (we know that for certain as far as the past is concerned). Ross Smith IV's blog post reaches the conclusion for Exchange Server 2013 after analyzing the following areas: Simplicity, Namespace Design, Site Resilient Datacenter Pair Design, Server Design, Database Availability Group Design (with its subcategories: DAG Configuration, DAG Network Design, Witness Server Placement, Data Resiliency).

Let me be more simplistic. There have been (and will be ?) times when the preferred architecture will be single-role Exchange servers. This is because the Exchange team may produce a design where the components of one role compete for resources with the components of another role. Or because it will help in the design or security of the network. Or, for other reasons that may come up. There have been (and will be ?) times when the preferred architecture will be multi-role Exchange servers, as we have now.

But Microsoft should always spell out for us each time what the preferred architecture for Exchange Server is. Microsoft should never leave this out for us to guess.

Please or Register to post comments.

What's Tony Redmond's Exchange Unwashed Blog?

On-premises and cloud-based Microsoft Exchange Server and all the associated technology that runs alongside Microsoft's enterprise messaging server.

Contributors

Tony Redmond

Tony Redmond is a senior contributing editor for Windows IT Pro and the author of Microsoft Exchange Server 2010 Inside Out (Microsoft Press) and Microsoft Exchange Server 2013 Inside Out: Mailbox...
Blog Archive

Sponsored Introduction Continue on to (or wait seconds) ×