A first look into Exchange 2013

In this post I will be taking an initial look into Exchange 2013, the next release of Microsoft Exchange scheduled for release later this year.  This post contains only information which is publicly available.  Exchange 2013 is the biggest architectural change in Exchange server since Exchange 2007.

Exchange 2013 is a new generation of Exchange, let me explain what I mean by the new generation.

Exchange 5.5 and below is generation 1 of the product, the initial build of Exchange before Active Directory came into play.

Exchange 2000-2003 is generation 2 of the product, in which significant changes to the product were made.  From Exchange 2000 upwards, Exchange began storing majority of its configuration within Active Directory.

Exchange 2007-2010 is generation 3 of the product where we saw a huge architectural changes such as the concept of 5 Exchange server roles.

Exchange 2013, also known as Exchange build 15 is generation 4 of the product.  In Exchange 2013 we have now consolidated majority of the roles back to a single role much like it was in Exchange 2013.

When Exchange 2013 is released as RTM there will be a total of 2 roles.  These roles will consist of:

• The mailbox server role (formally known as a back-end server in Exchange 2003)
•  The client access server role (formally known as a front-end server in Exchange 2003)

If you have a long working history with Exchange server, think of Exchange 2013 architecture as it was in Exchange 2000/2003.  Client access servers proxy the connections, the mailbox servers do all the work.

Exchange 2013 Client Access Server

The Exchange 2013 client access server proxies connections to Exchange 2013 mailbox servers such as Microsoft Office Outlook, Outlook Web App, Mobile Devices, POP, and SMTP.  Client access servers can still be organised into CAS Arrays like they were in Exchange 2010.  Client Access servers perform authentication, redirection, and proxy services; it doesn't perform any data rendering utilizing internet information services (IIS).  All Exchange Web Service virtual directories exist in the Exchange 2013 mailbox servers just like they did in Exchange 2003.  The client access server merely proxies the connection to the correct mailbox server which is now responsible for processing the request.

Because all data rendering for web services is now performed on the Exchange 2013 mailbox servers, all connections to the Client Access server are stateless which means that there is no need to maintain affinity between a client and an individual Client Access server for subsequent connections because all data processing and transformation occurs on the Mailbox server.  This architecture change means simple "stupid" load balances can be used with no affinity or affiliation required.  In majority of cases Microsoft Network Load Balancing (NLB) with all its weaknesses is more then enough to load balance Exchange 2013 client access.

One big change in Exchange 2013 is all client access connectivity to Exchange 2013 must come in through HTTPS.  The MAPI protocol is now just a back end protocol for the mailbox servers.  Outlook must connect through RPC over HTTP(s) both internally and externally.

Whenever you deploy an Exchange 2013 client access server in an Active Directory site, you must also deploy an Exchange 2013 mailbox server in the same Active Directory site.

Exchange 2013 Client Access Architecture

When you deploy an Exchange 2013 client access server array, there are two components

• Client Access service
• Front End Transport service

The Client Access service provides the following services:

• Provides a unified namespace, authentication, and network security.
• Handles all client requests for Exchange.
• Routes requests to the correct Mailbox server.
• Proxies or redirects client requests for legacy servers, such as Exchange 2007 and Exchange 2010 Client Access.
• Enables the use of layer 4 (TCP affinity) routing... i.e. stupid load balances with no affinity.

The Front End Transport service provides the following services:

• Protocol level filtering   Performs connection, recipient, sender, and protocol filtering
• Network protection   Centralized, load-balanced egress and ingress point for the organization.
• Mailbox locator   Avoids unnecessary hops by determining the best Mailbox server to deliver the message to.
• Load-balances client and application SMTP requests.

The Front End Transport service can't inspect message content, but it has complete access to the SMTP protocol conversation, so it can filter messages based on connections, domains, senders, and recipients.  There is no queue on the Front End Transport service, mail is simply proxied directly to a mailbox server.  Because the Front End Transport service is aware of TCP connections you can configure some spam filtering however such as RBL providers such as Spamhaus.  For content filtering such as Exchange intelligent message filter (IMF), you guessed it, this needs to be performed on the  mailbox servers unless you have a smart host in play.

Exchange 2013 Mailbox Server

Just like in Exchange 2003, the Exchange 2013 Mailbox Server is once again the work horse of Microsoft Exchange.  The Exchange 2013 Mailbox Server has taken on tasks from many of the roles such as client access services, hub transport services and unified messaging services.  For example:

• All Outlook Web App, Active Sync and Outlook Anywhere (RPC over HTTP) sessions are processed on the Exchange 2013 mailbox servers
• The message queue and mail routing is performed on the mailbox servers (which the exception of the mailbox locator service on the client access which provides the ability to always deliver inbound mail to the correct mailbox server in the same AD site)
• Provides Unified Messaging services
• And of course it acts as a mailbox server providing companies enhanced Database Availability Groups (DAGs) which are improved over Exchange 2010.

The below diagram shows a high level overview of the Exchange 2013 architecture inside a single Active Directory site.

Why the big change?

Now why did Microsoft make such significant changes to the Architecture in Exchange 2013?  When Exchange 2007 released the concept of a multi-role servers, processing power was significantly less then what it is today.  Large scale deployments of Exchange 2003 which extended into the hundreds of thousands of users faced significant resource limitations due to hardware back in the day.  Microsoft needed to address this to allow Exchange to extend into larger scale deployments and as a result separate the server roles.

Due to a lot of smart people doing a lot of smart things over the years, today's servers have so much grunt we are virtualising to try and make use of it all.  This architecture of multi-role servers no longer makes sense!  In fact for large scale deployments of Exchange, as of Ex2010 SP1, Microsoft started recommending building all Exchange 2010 servers as multi-role servers and simply adding an additional server when required as a simple unit of scaling out.  The recommendations for multi-role Exchange servers can be found here:

http://technet.microsoft.com/en-us/library/dd298121.aspx

Now the problem here is the Exchange 2010 roles have been designed to run on separate servers and when all installed on the same server they still follow the same processes to communicate with one another through a TCP network call on localhost.  This creates inefficiencies as separate roles are all operating on the same server when the roles could be more incorporated to work more as one to provide better performance.  In fact this is one of the selling points behind Exchange 2013 from Microsoft:

"been re-written in managed code to improve performance in additional IO reduction and reliability."

Requirements

First of all what operating systems are supported to install Exchange Server 2013?  Easy one:

• Windows Server 2008 R2 Standard, Enterprise and Datacenter Editions or higher.  Make sure it is R2 as 2008 is not supported.
• Windows Server 2012 

What about migrating to Exchange 2013?  Migrating to Exchange 2013 is only supported from:

• Exchange 2007
• Exchange 2010

Despite all the noise I made whilst in Seattle earlier this year, the Exchange product team will not be supporting Exchange 2003 co-existence even though there are still many customers running Exchange 2003. I guess this just means the uptake to Exchange 2013 will not be as fast as those customers will need to perform a step migration through either Exchange 2007 or Exchange 2010.

Whilst Exchange 2013 now has greater support for IPv6 such as Unified Messaging now supporting IPv6, a pure IPv6 environment isn't supported.  IPv6 is only supported when IPv4 is also used.

Active Directory requirements are that of 2003 Forest Functional Level (FFL) and 2003 Domain Functional Level (DFL) or higher.  Schema master must run on Server 2003 SP2 or higher.

At this stage Exchange 2013 only supports the following clients:

• Outlook 2013 Preview
• Outlook 2010 SP1 with April 2012 Cumulative Update 
• Outlook 2007 SP3 with July 2012 Cumulative Update
• Entourage 2008 for Mac, Web Services Edition
• Outlook for Mac 2011

Multi-Role Servers

Can you install the Exchange 2013 Client Access Role and the Exchange 2013 Mailbox Role on the same server?

The answer is Yes.

Edge Transport Role

Currently there is no Edge Transport role for Exchange 2013.  Microsoft are advising customers to use Exchange 2010 SP2 Edge Transport with Exchange 2013 for now.  Due to a tight product release time frame the Exchange product team have not had time to develop the Exchange 2013 edge transport role however this role will be released in the future through a service pack.

A New Management Interface

The popular Exchange Management Console (EMC) which was used by for managing Exchange 2007/2010 has been removed from Exchange 2013.  Administrators are provided two methods for maintaining an Exchange 2013 environment:

• Exchange Management Shell (EMS) - also available in Exchange 2007/2010
• Exchange Administration Center (EAC) - new in Exchange 2013.

Exchange Administration Center is a web based administration console for Exchange.  Personally I don't agree with this decision as Microsoft has produced Microsoft Management Console (MMC) to be the standard for managing a windows network - this diverts away from the standard.

The main reason why Microsoft moved towards a web based interface for managing Exchange is due to Role Based Access Control (RBAC).  RBAC provides a granular method for delegating control to administrators.  With Exchange Management Console in Exchange 2010, when an administrator delegates a service desk operator to perform basic tasks such as create and manage recipient mailboxes, the service operator is able to perform his duty however is able to view all other features and functionality normally presented in EMC.  With EAC in Exchange 2013, the web console hides all administrative features and functionality except for the areas the user has been delegated access to.  With MMC hiding features is a difficult task which I believe is the prime reason Exchange management has been moved to a web interface.

There are also other benefits to having a web based management tools which EAC provides.  Administrators can now maintain Exchange environments from any PC with a web browser.  Yes - EAC does provide multi-browser support including all the major web browsers such as Chrome, Firefox, Safari and of course Internet Explorer.