With the Exchange 2013 release, Microsoft consolidated its previous Exchange server role architecture from five roles down to two. While the re-architecture may seem drastic, it should prove a positive change for admins in the long run.
Exchange Server 2007 introduced the concept of five distinct server roles, presented as specific subsets of functionality that were assigned to individual Exchange servers. Many IT pros groused that individual server roles made things more complicated; they now had to think about which role assignments they would give what servers.
Of course there were several long-term payoffs: more efficient use of existing hardware, a more responsive Exchange Server setup and more granular management. It required a bit of settling in, but once admins understood why it was done, it made more sense.
In Exchange 2013, those five Exchange server roles -- the client access server, unified messaging, mailbox server, edge transport server and hub transport server -- have been consolidated down to the client access server (CAS) role and the mailbox server role.
All five roles now exist as subsets of the CAS and mailbox server roles, with some role functionality split as services. The CAS works only as an access proxy and an authentication layer, while the mailbox server does all message rendering.
So why did Microsoft go this route? Apart from the fact that it was a good way to satisfy the grumblings of many IT folks who disliked the proliferation of Exchange roles, it's a reflection of the changes that have taken place in the server market the last few years.
More Exchange infrastructures are hosted in virtualized environments. This is a direct reflection of the general increase in server power and capacity. What would have previously taken four systems now takes two, or only one. This reassignment of roles mirrors that notion. In many ways, it echoes a return to the Exchange of the past, where you only had front- and back-end servers.
I've compiled key points regarding the Exchange 2013 server role changes that are worth keeping in mind as you prepare to migrate an existing Exchange organization to Exchange Server 2013:
1. Exchange 2013 server role communication is now done entirely through HTTPS.
Aside from the fact that network admins now only have one protocol to deal with, client traffic is also that much simpler. Any RPC calls -- such as MAPI traffic from Outlook -- is wrapped in HTTPS and sent thusly.
This means that front- and back-end servers can reside in entirely different Active Directory sites. Prior to Exchange 2013, they were essentially forced to live in the same site. This also means RPC endpoints (in the CAS array) don't exist anymore either. This is one less mapping to keep track of.
2. Exchange 2013 load balancing should be easier to set up.
This is another nice consequence of the change to how the front- and back-end communicate with each other. Since all connections are now made via HTTPS -- and are therefore stateless -- you can perform load balancing at the transport layer (Layer 4, TCP/UDP).
This also allows for a broader range of solutions. Exchange pro Michael Van Horenbeeck suggests that when it comes to load balancing that DNS round-robin could do the trick. This sounds like a solid, inexpensive place to start for those with relatively modest Exchange setups; for example those with three to four total servers.
3. Exchange 2010 legacy edge transports can be used with Exchange 2013.
Because the Exchange 2007 and Exchange 2010 edge transport role doesn't exist in Exchange 2013, a certain degree of legacy compatibility must exist between the two systems, and it does.
You just need to hook the edge transport servers in question to your mailbox servers. This is where the hub transport service now resides.
4. Unified messaging is now a component, not a server role.
Many aspects that were formerly implemented through unified messaging are now divided between the CAS and mailbox roles. Voicemail via session initiation protocol, for example, is now handled through the CAS. Results are relayed to mailbox servers as needed.
It should go without saying that you will still have a substantial set of servers to handle unified messaging.
If you're using Lync Server 2013 in conjunction with Exchange, Microsoft notes that using DNS load balancing -- while possible with Lync -- can cause loss of failover in certain scenarios. Hardware balancing seems to be preferred here.
The reduction of five explicit Exchange server roles to two should make for a simpler Exchange 2013 management experience. If you're just now settling into the Exchange 2007 and Exchange 2010 multi-role methodology, the change may prove jarring. But in the long run, it means that a lot of the side effects of having numerous roles will be put to rest.
About the author:
Serdar Yegulalp has been writing about personal computing and IT for more than 15 years for a variety of publications, including Windows Magazine, InformationWeek and the TechTarget family of sites.