Understanding Exchange Server 2013–Part1 (Role Architecture Changes) #Microsoft #msexchange

Today the Exchange server 2013 technical preview has been announced, it was a long waited version that will take the Microsoft communication and messaging platform to the new level, with the new version there are a lot of changes in how things work internally and in architecture in general, in these blog series we will explore the new architectural changes in details, this the first part we will speak on the new role architecture changes.

Old Architecture:

in Exchange 2007, Microsoft did a dramatic change in server role architecture by splitting the functionality into HUB, CAS, UM, Edge and Mailbox, this was huge change from the old Backend/Frontend architecture in Exchange 2003, the new architecture was the same in Exchange 2010.

Behind the scene:

Behind the scene, Microsoft saw a limiting boundary in hardware expansion from Memory and Disk perspective and saw that CPU power is increasing over time; additionally current server roles architecture and binaries doesn’t make full use of the current CPU cores capabilities which introduce a potential for server role consolidation ; and that was the major drive for the new architecture change.

New Exchange server 2013 Architecture:

in Exchange Server 2013, the architecture has been changed to consolidate all the roles to the following:

• Client Access Server Role: The Role proxies and handles all client connectivity protocols including HTTPs/POP3 and SMTP, you will have to note that in Exchange server 2013 all client to server traffic is done over HTTPs so no RPC traffic any more.
• Mailbox Server Role: this role does all Mailbox functionality, UM functionality.

The driver behind the new architecture that more roles can be combined in a single box offering less server roles and higher hardware utilization and better capacity also since roles are combined they can communicate internally using RPC thus eliminating the need to support RPC protocol outside a single box and making communication between Mailbox and CAS servers only over HTTPs or SMTP.

with the new architecture; the CAS does its role differently by doing pure proxy’ing for connections that he handles thus offering simplified deployment for 2 reasons:

• Since all traffic is proxied there is no need for advanced Layer 7 load balancers, because everything is stateless it just takes the connections and forward it to the appropriate mailbox or backend server so all what you need is a layer 4 TCP with source IP load balancer to do the job, this means that if a CAS server failed there is no problem in forwarding the session to another client access server because there is no session affinity to maintain.
• since CAS server is now doing proxy there are no need for different types of stickiness or session affinity configuration needed in previous versions, which has been simplified by using a simple single namespace to o all of the work.

CAS servers also now handle SMTP connection, the sole service responsible for that is the Frontend transport services which does all of the SMTP related functionality including recipient/sender filtering, protocol logging…etc.

there is no Edge Server 2013 specific version, you can use the Exchange 2010 Edge server along with your Exchange server 2013 deployment, there might be change in this regard in later service packs.

in part 2 we will explore the new features in mailbox servers and how it differs from its predecessors.

About these ads