Microsoft Exchange Server 2013 - Sizing, Designing and Configuration: A Practical Look

Records

Chapter 1

Exchange 2013 Architecture Introduction

Introduction

Microsoft introduced Exchange server during the late 1980s with Microsoft Mail, after which it has never turned back. Microsoft’s continuous improvement and evolution of the product has helped to change the way the world looks at the messaging system. Initially it was just an application; limited to only a few people, a few organizations, and IT teams. Hardware was expensive, and designing and implementation was complex, too; but this is not the case anymore.

Now everyone in the organization needs a mailbox, and typically has more than one device to access their mailbox. Users continually access their e-mail round the clock. The first important thing that anyone does in the office is to check their e-mails. It is considered as one of the best and lowest cost modes of business communication and it is also used for keeping records.

History

Microsoft’s mailing solution has been around for a while now, and there have been a number of architectural modifications and design changes. It has evolved and adapted in order to meet all the necessary requirements of modern business communication. Given below is a history of the Exchange server, highlighting some of its features.

Microsoft Mail

Microsoft Mail was first mail product introduced by Microsoft in 1991, on the basis of Network Courier. There have been a few versions of Microsoft Mail, and the last version available to the market was Microsoft Mail 3.5.

Microsoft Exchange Server 4.0

Microsoft Exchange Server 4.0 was designed to replace and upgrade Microsoft Mail 3.5. Officially this was the first version of Exchange. The RTM version released in April 1996 was a new X.400 client server mail system with a single database, and supported X.500 directory service.

Microsoft Exchange Server 5.0

Microsoft Exchange server 5.0 was released on May 23, 1997, with the new Exchange Administrator console. It had a code name of Osmium (aka Oz). It had a new web interface to access e-mail called Exchange Web Access, which was later renamed Outlook Web Access, complete with calendar support. It also introduced support for IMAP4 and deleted item recovery features.

Microsoft Exchange Server 5.5

Microsoft Exchange Server 5.5 was released on Feb 3, 1998. It was just a year after releasing the previous version, Exchange 5.0. It was a promising product that increased the popularity to a great extent, and organizations started adopting Exchange into their environment. This was the last server to have a separate directory, SMTP, and NNTP service. It also supported high availability through clustering solutions on Windows NT using the Enterprise version of Exchange server, but not through the standard version.

Microsoft Exchange Server 2000

Microsoft Exchange Server 2000 was released on November 29, 2000. It was code-named Platinum and was introduced to overcome some of the limitations of Exchange 5.5. The major breakthrough was, it had no built-in directory service, and had to depend on Active Directory. It also provided the high availability through windows clustering, and the number of nodes in the cluster were increased from two to four. Running on the Microsoft Windows 2000 server, it had some new concepts, like administrative groups, which logically grouped Microsoft Exchange 2000 servers and routing groups, providing an option to connect the Exchange 2000 servers and allow them to communicate.

Microsoft Exchange Server 2003

Microsoft Exchange Server 2003 was released on September 28, 2003, and was code-named Titanium. It was designed to provide communication more effectively, and offered rich access of e-mail through desktop, remote, and mobile devices with state-of-the-art security and privacy. It provided high reliability and better performance over previous versions of Exchange. It has support for up to 8 nodes clusters, and allows the maximum database size of up to 16 TB, while supporting up to 4 storage groups with 5 databases per storage group, with a total of 20 databases per server.

Microsoft Exchange Server 2007

Microsoft Exchange Server 2007 was released on March 8, 2007, and had a new architecture, with five different server roles: Mailbox, Client Access, Hub Transport, Edge Transport, and Unified Messaging. It provided new high availability and DR solutions through Support for LCR (Local Continuous Replication), SCR (Standby Continuous Replication), SCC (Single Copy Clustering), and CCR (Clustered Continuous Replication). It can have up to 50 databases and 50 storage groups.

Microsoft Exchange Server 2010

Microsoft Exchange Server 2010 was released on November 9, 2009. Exchange 2007 high availability and disaster recovery (DR) solutions were complex. With Exchange 2010, the database availability group was introduced. It made this process simpler and easier. Now Exchange databases were no longer belongs to specific servers, and copies could be hosted on multiple servers. In the event of failure, it could automatically mount the best available database on any server. It provided options like database level failover, server level failover, site failover, new retention policies, and role-based access control to provide more granular permission to the administrators, etc. It also had the option of legal hold and eDiscovery (multi mailbox search) to meet legal and compliance requirements.

Microsoft Exchange Server 2013

Microsoft Exchange Server 2013 was released on December 3, 2012. It has new optimized architecture to overcome some of the limitations and complexities of Exchange 2007, Exchange 2010, and other previous versions of Exchange. Since Memory and CPU cost have significantly reduced over a period of time, Microsoft has considered this factor while designing Exchange 2013, and scaled and utilized hardware to a great extent.

Exchange 2013 has reduced the number of server roles to two: The Client Access server role, and the Mailbox server role. With Exchange 2013 Sp1, the Edge Transport server role has been introduced. The Hub Transport server role, which was present in the previous versions of Exchange like Exchange 2007/2010, has been removed, and its features have been clubbed with the Client Access server Role and Mailbox server Role.

Client Access Server (CAS) Role

Like the previous versions of Exchange, the Client Access server role offers the client connection to it through various protocols like HTTP, POP, IMAP, SMTP, and SIP. It performs authentication, redirection, and proxy services. The Client Access server does not perform any data rendering. Now, it is just a thin and stateless server, and no emails queues on it. The Client Access server handles client connection and authentication; and then it sends the authentication data to the Mailbox server. The Client Access server pools the connection to the Mailbox server and reduces the number of proxy requests to the Mailbox server; this improves the efficiency and end-to-end latency.

Given below is a picture that represents the client communication with the Client Access servers. The Client Access server accepts the connection through various protocols like HTTP, POP, IMAP, SMTP, and SIP. Then it establishes the communication, with the appropriate protocol, on the Mailbox server. All the communication between these two server protocols is completely encrypted.

Figure 1.1 Communication between Clients, Client Access, and Mailbox Server

Mailbox Server Role

Since an Exchange 2013 Client Access server just performs authentication, redirection, and proxy, the Exchange 2013 Mailbox server hosts most of the features when compared with previous versions of Exchange servers (2007 and 2010). It includes some of the Client Access server, transport service, mailbox, database, and unified messaging features.

These role changes have brought about a new way of inter-server communication in Exchange 2013. In Exchange 2010, Client Access server protocol of one server in an AD site could talk to the Mailbox server from a different AD site. In Exchange 2013, inter-server communication has completely changed. Protocol from one server can always talk to protocol on the other server from the same or different AD site. For example, Transport/EWS protocol on the Client Access server can only communicate with the transport/EWS protocol on the other Client Access server in the same or different AD site.

Figure 1.2 Protocol Communication between the Exchange 2013 Servers

Change in Exchange Server 2013

Exchange Server 2013 has brought some rich changes, which make designing much simpler and easier. Let us talk about some of the important features that impact the design and performance of the Exchange organization.

Name Space Reduction

Exchange 2010, with its site resiliency environment, has multiple name spaces and can have up to eight different name spaces. They are for Outlook CAS Array, Autodiscover, OWA internal user, External OWA, and other client namespaces, SMTP, and some co-existing namespaces.

New designing in Exchange 2013 just has a few name spaces in its site-resiliency environment, and can be just three or four. One each for client protocol to allow different clients to connect, Autodiscover, SMTP namespace, and finally one for the Exchange 2013 to coexist with Exchange 2007. Legacy namespace is only required when coexisting with Exchange 2007, and not while coexisting with Exchange 2010.

Since Exchange 2013 can proxy to the Exchange 2010 directly without depending on legacy namespace, this also reduces the number of Subject Alternate Name (SAN) in the certificate that is installed on the CAS. The reduced number of SANs reduces the cost/year on the certificates.

Witness Server

Mailbox servers are added to the DAG, and these nodes are considered the votes when there are even number of DAG members. To maintain a quorum, we need an odd number of nodes in the DAG. DAGs with an even number of nodes will use a witness server as an additional vote to maintain the cluster quorum. The witness server can be an Exchange server and/or any domain-joined member server in the organization.

However, if the witness server is not an Exchange server, then it must be added to the Exchange Trusted Subsystem group in Active Directory, and must be added to the local administrators group, and File server features (only on Windows Server 2012) must be installed.

1.    In a single AD site with a single DAG or multiple DAG environment: It is recommended to install the witness server on the same datacenter as DAG members.

2.    In a two-AD site with a single DAG or multiple DAG environment: It is recommended to configure the witness server in the primary datacenter.

3.    In a multi-AD site environment with a single DAG or multiple DAG environment: The witness server could be installed on the third datacenter. The requirement is to have the network well connected between three datacenters, and the third datacenter, where the witness server is placed, should not have any network failure that could affect the DAG.

Figure 1.3 Exchange 2013 DAG with Witness Server in the Third Datacenter

Load Balancer Requirement

Exchange 2007/2010 had the requirement to have a load balancer configured with session affinity with various Exchange protocols for client communication. It can have performance and connectivity issues if affinity is misconfigured. Some of the protocols that need affinity are OWA, EWS, Outlook Anywhere, ActiveSync, Address Book Service, and Outlook RPC over TCP etc.

Exchange 2103 does not require session affinity for load balancing various Exchange protocol request from the clients. Load balancing can be configured to at Layer 4 which works on IP address and ports (443). With this architecture changes, load balancer does not understand the target contents. To overcome this complexity, Exchange 2013 has feature of heath check probing. Load balancer can make use of inbuilt monitoring feature, known as Managed Availability. It generates the file healthcheck.htm in memory for each of the Exchange 2013 virtual directories. Load balancer can read the status of these healthcheck.htm file to determine the health of each virtual directory in the server. If the status code is 200 returned then load balancer routes the traffic to the protocol, else the client protocol request are not routed to failed protocol on the server.

Managed Store

The Exchange 2013 Information Store process is now called Managed Store, and is completely written in C# to provide better performance and stability in the Mailbox store. It works closely with Microsoft Exchange Replication Service to manage the Mailbox database to provide the best database performance, and also provide faster failover when storage or server failure happens. Managed store also offers single store service controller process for each mounted database. New process are dynamically created and removed whenever a new database is mounted or dismounted and it also has one process for store service process controller to manage all process for each mounted database.

Multiple Database per Disk

Now low-cost SATA disks are available with up to 8 TB of space, and the size of the disk is increasing with no difference in the speed without impact of the user performance experience. To make the best use of these large disks, Exchange 2013 supports multiple databases on a single disk with the combination of different active and passive database copies.

Lagged Database Copy Changes

A lagged database is the passive copies of the database that is configured to hold the replay of the transaction logs to the database. It helps to protect the database from any kind of logical corruption caused due to Exchange or any client, and gets replicated to other database copies. The lag/internal time has to be configured, and it replays the transitional logs once the lag internal is reached. Lag internal can be configured to retain logs up to 14 days. Depending on the requirement and configuration, necessary disk space must be configured to retain the log files for the longer duration.

A lagged database can protect itself when low disk limits are reached. It has the inbuilt mechanism to replay the logs when a low disk space threshold is reached. It can also replay the transaction logs when the system detects that page patching is required. Page patching is an interesting concept; when a checksum check on a page fails then, it needs to be replaced with a new copy from the other nodes that has a clean copy of the transaction logs.

DAG Network Auto-configuration

Exchange 2013 allows the DAG network to configure automatically, and can identify the configuration and determine the MAPI and replication network and configure itself automatically.

This step was manually performed in Exchange 2010 and it adds more complexity and confusion when there are multiple replication network with an additional backup network.

Automatic Reseed

Auto reseeding is a great new feature to provide high availability in a database availability group when disk failures occur on the Exchange Mailbox servers. This feature needs to be pre-configured with the pool of spare disk volumes.

When disk failure occurs, then the spared disk will be configured, and the failed database will be reseeded. It reduces the administrator efforts and allow him to take some time to procure the new disk to replace, reconfigure the failed disk, and finally reseed the database. Given below are the high-level steps to understand on how the auto reseed works:

1.    When any disk failure occurs that contains an active database, then the active database will be automatically mounted on the different server.

2.    Database status on the failed server changes from mounted to Failedandsuspended state.

3.    Exchange replication service periodically scans for the database with a Failedandsuspended state and tries to reseed the database for three times.

4.    If the above process fails, then it