Microsoft greatly improved Exchange 2013 to better support millions of mailboxes that Microsoft hosts for Office 365, and the benefits of the enhancements are received by us all even when we put Exchange 2013 on-premise. As much as most organizations will not have “millions” of mailboxes for their on-premise Exchange, the fact that a single Exchange server can now host thousands of mailboxes (instead of hundreds of mailboxes) means fewer (MUCH FEWER) mailbox servers are needed in an organization. Also, Microsoft did away with the Hub Transport role that was in Exchange 2007 and 2010, thus decreasing the number of servers needed for an Exchange environment. Additionally, Exchange 2013 can now be completely virtualized, again decreasing the number of physical servers and ultimately the cost of Exchange to implement and support.
Microsoft also eliminated a couple Exchange server “Roles” (the Hub Transport and Unified Messaging roles) that have been embedded into the Exchange Mailbox Server role now as “services” (so Hub Transport Service, and Unified Messaging Service). So now in an environment, the organization may have an Edge Server (doing spam filtering or the like) and they’ll have just Client Access Servers (CAS) and Mailbox Servers (MB). With the elimination of roles, there are now WAY fewer servers in the organization, and from a high availability and disaster recovery standpoint, fewer servers means failover is a LOT easier to manage. Now when a Mailbox server needs to failover to a disaster recovery site, it’s just the CAS and MB servers that need to failover. All voicemail functions automatically failover since they sit on the Mailbox server now anyway.
Additionally, the CAS server is focused primarily on endpoint connection, so HTTP, POP3, IMAP, ActiveSync connections AND no longer establishes an exclusive connection of the endpoint to the Mailbox server. Load Balancing in Exchange 2013 no longer requires Session Affinity (Layer 7) load balancers! This is huge as one of the biggest challenges in migrating to Exchange 2010 when you look at Web queries and migration challenges typically are around failed load balancing, challenges getting F5 load balancers working with Exchange 2010 CAS Arrays, failover between CAS servers within an array, and failover across sites. Now with Exchange 2013 and the simplified CAS servers, basic network load balancing is designed to work with Layer 4 (TCP Affinity) load balancing. AND because the CAS server and Mailbox server are communicating higher in the stack, there are NO dependencies on CAS Servers and Mailbox servers to be patched and updated SIMULTANEOUSLY! That has been one of the biggest challenges with Exchange over the past decade is that the frontend (CAS) and backend (MB) servers had to be patched and rev’d with the exact same release, otherwise odd things happen, and usually not good. For early adopter environments with dozens of servers, if it takes 2-3 days to patch systems, it has NOT made any difference, the organization just upgrades the Exchange CAS and MB servers in any order and sequence, Exchange continues to operate!!!
Note: In the initial release of Exchange 2013, the Edge Server role is still an Exchange 2010 Edge Server system. Microsoft has not updated the Edge Server role to a 2013 server, however Edge 2010 servers are fully compatible with Exchange 2013 and serve the same function and purpose.
With Exchange 2013, the Database Availabiliity Group concept and configuration hasn’t changed, you can still create databases, replicate them to other servers as 2nd, 3rd, 4th, etc copies of the DB, you can lag the replication so that the target is delayed by a period of time (potentially to prevent corruption or allow recovery of accidental data problems on an upstream server). DAGs continue to be automatically defragmented and data continues to be sequentially stored to disk virtually eliminating the need to run ESEUtil and ISInteg database repair utilities as it is rare if not unseen anymore to have database corruption as was a couple generations ago with Exchange. Database replicas are not bit level mirrors of data, but rather log shipped data that is “built” on the target server, thus corruption on one server is not replicated to other servers. The architecture for DAGs remains similar to how databases were architected in Exchange 2010.
As a final note on Exchange 2013 Architecture, because there is parity between Exchange 2013 on-premise and Office 365 in the cloud running Exchange 2013, organizations can administer and manage databases, mailboxes, mail routes, transport policies, mailbox moves, and the like from the common Exchange Admin Center console regardless of whether the data and routes are on-premise or in the cloud. This has greatly simplified architecture of Exchange 2013 from the number of servers, server roles, connectors, disaster recovery processes, and the like. This allows Exchange architects to spend more time focusing on things that are important to organizations such as mailbox policies, multi-platform endpoint support, email retention, email archiving, data leakage protection, and the like that are all the “value add” functions that have been enhanced in Exchange 2013 that make Exchange 2013 on premise or in the cloud a valuable solution for organizations to implement!
Several other postings I’ve done on Exchange 2013, just click the Next Article or Previous Article buttons on this blog post to get to other articles I’ve covered, or http://www.networkworld.com/community/morimoto to see a listing of all of the various blog posts I’ve done over the years. Hopefully this information is helpful!
Rand Morimoto is the President of Convergent Computing (http://www.cco.com) an early adopter partner of Microsoft that put Exchange 2013 in production environments months before the product release. Rand is also the author of the book “Exchange 2013 Unleashed” by Sams Publishing that was available worldwide in November 2012 based on real world implementation and migrations to Exchange 2013 involving thousands of user mailboxes.