Exchange 2010 to Exchange 2016 RTM-Architectures
Today, CPU horsepower is significantly less expensive and is no longer a constraining factor. With that constraint lifted, the primary design goal for Exchange 2016 is for simplicity of scale, hardware utilization, and failure isolation. With Exchange 2016, we reduced the number of server roles to two: the Mailbox and Edge Transport server roles.
The Mailbox server in Exchange 2016 includes all of the server components from the Exchange 2013 Mailbox and Client Access server roles:
- Client Access services provide authentication, limited redirection, and proxy services. Client Access services don’t do any data rendering and offer all the usual client access protocols: HTTP, POP and IMAP, and SMTP.
- Mailbox services include all the traditional server components found in the Exchange 2013 Mailbox server role: the backend client access protocols, Transport service, Mailbox databases, and Unified Messaging. The Mailbox server handles all activity for the active mailboxes on that server.
The Edge Transport role is typically deployed in your perimeter network, outside your internal Active Directory forest, and is designed to minimize the attack surface of your Exchange deployment. By handling all Internet-facing mail flow, it also adds additional layers of message protection and security against viruses and spam, and can apply mail flow rules (also known as transport rules) to control message flow.
The Exchange 2016 architecture offers the following advantages:
- Version upgrades facility and flexibility No more rigid upgrade needs. Mailbox servers are allowed to be upgraded independently and in any order in context to other Mailbox servers.
- Session indifference and variation With Exchange 2010, session affinity to the Client Access server functional role was needed for various protocols. In Exchange 2016, the client access and mailbox components underlie and reside on the same Mailbox server. No session affinity is needed among Mailbox servers, Edge Transport servers, or mail servers over the Internet. This permits inbound client connections to Mailbox servers to be properly balanced using techniques offered by load-balancing technology like least connection or round-robin.
- Deployment simplicity and ease With an Exchange 2010 site-resilient design, you required up to eight variant namespaces: two for Outlook Web App fallback, two Internet Protocol namespaces, two for RPC Client Access, one for Autodiscover and one for SMTP. With Exchange 2016, the most organizations require ONLY two namespaces for the sake of coexistence with Exchange 2010: one for client protocols and one for Autodiscover. Based on how you setup and configure your mail routing, you may also require an additional namespace for SMTP routing.
Along with the new Mailbox role, Exchange 2016 now allows you to proxy traffic from Exchange 2013 Client Access servers to Exchange 2016 mailboxes. This new flexibility gives you more control in how you move to Exchange 2016 without having to worry about deploying enough front-end capacity to service new Exchange 2016 servers.