One of the biggest changes Microsoft made in Exchange Server 2013 was to consolidate the server role architecture...
from five roles to two. When I first heard about this change, I was curious about what it meant for potential Exchange 2013 migrations. If you're wondering the same thing, this tip will clear up any confusion regarding how the new Exchange 2013 server role architecture will -- or won't -- affect Exchange 2013 migrations.
Supported migrations and requirements
As with previous versions, migrating to Exchange 2013 means you'll have to go through a coexistence period between the old and the new versions. Also, Exchange 2013 coexistence is only supported with Exchange 2007 and Exchange 2010. Therefore organizations that currently run Exchange 2003 must perform a multistep migration where they migrate first to Exchange 2007 or Exchange 2010, then to Exchange 2013.
Note: You'll need Exchange 2010 SP3 to coexist with Exchange 2013.
Surprisingly, Active Directory requirements have not changed since Exchange Server 2010. The forest-functional level must be set at Windows Server 2003 or higher, and the Schema Master must run Windows Server 2003 with SP2 or higher.
As for the server operating system, Exchange 2013 will run on Windows Server 2008 R2, but not on Windows Server 2008. Presumably, Windows Server 2012 will also be supported.
Exchange 2013 server role basics
The only server roles that exist in Exchange Server 2013 are the client access server (CAS) and mailbox server roles. This is similar to the Exchange 2003 architecture, which consisted of a front-end server and a back-end mailbox server. However, the new architecture actually has more in common with Exchange 2010 than with Exchange 2003.
Even though Exchange 2013 only offers two server roles, Microsoft has not completely abandoned the other three roles (hub transport, edge transport and unified messaging). The functionality found in those roles has actually been integrated into the CAS and mailbox server roles.
With the server role re-architecture, many are wondering if the two roles are mandatory. The answer is yes: Every Exchange 2013 organization requires at least one CAS and at least one mailbox server.
Additionally, some are curious about whether both roles can be installed onto a single server. The answer is, again, yes, they can. Larger organizations should certainly isolate the server roles, but smaller organizations can definitely get away with deploying both roles onto a single server.
Exchange 2013 server role responsibilities
Similar to Exchange Server 2003, the mailbox server does most of the heavy lifting. The mailbox server hosts mailbox and public folder databases and manages database availability groups.
Surprisingly, many of the functions that the CAS handled in Exchange Server 2010 are now a function of the mailbox server. For example, the mailbox server is now responsible for Outlook Web App, Outlook Anywhere and Exchange ActiveSync.
The mailbox server role handles much of the functionality that was previously associated with the hub transport server. It is also now responsible for message routing and queuing. Unified messaging functionality has been rolled into the mailbox server role.
What about the CAS role? As in Exchange Server 2010, the CAS handles all inbound client requests for Exchange 2013. When the CAS receives a request, it wraps that request to the appropriate mailbox server.
The CAS will also redirect client requests to legacy Exchange 2007 and Exchange 2010 servers. Additionally, it is responsible for Exchange Server-related authentication and network security.
So what does this all mean? According to Microsoft, an Exchange 2013 migration should be relatively simple, because Exchange servers that performed dedicated roles can now be replaced with multipurpose Exchange 2013 servers. The role consolidation will greatly simplify the Exchange Server architecture, not to mention Exchange 2013 administration.
About the author
Brien Posey is an eight-time Microsoft MVP with two decades of IT experience. Before becoming a freelance technical writer, Brien worked as a chief information officer at a national chain of hospitals and health care facilities. He has also served as a network administrator for some of the nation's largest insurance companies and for the Department of Defense at Fort Knox.