Microsoft Exchange Server

How does Exchange Server work?

Exchange Server is an enterprise-class collaboration product that primarily focuses on sending, receiving and storing email messages. In addition to managing messaging traffic, Exchange Server provides several other collaboration features, like calendaring, and tight integration with other Microsoft Office applications.

Exchange Server is known for its high availability (HA) features that ensure continued service in different outage scenarios. This includes design paths that can ensure service during single-server failures or data center outages.

Exchange Server 2019 features

The 2019 release provides significantly faster and more reliable failover between servers. It was designed to improve overall performance and take advantage of the latest storage hardware, including larger disks and solid-state drives (SSDs).

Additional features in Exchange server 2019 include the following:

• provides support for up to 256 GB of memory and 48 CPU cores;
• enables installations on Windows Server Core;
• enables external access to Exchange admin center (EAC) and the Exchange Management Shell to be blocked natively;
• employs dynamic memory cache allocation to optimize memory usage for active databases;
• prevents attendees from forwarding meeting invitations;
• provides end users with additional Out of Office options;
• enables administrators to cancel meetings that were organized by a user who has left the company;
• enables administrators to assign delegate permissions; and
• enables email addresses that contain non-English characters to be routed and delivered natively.

Exchange Server 2019 logo

Along with these additional features in Exchange 2019, the Unified Messaging (UM) role and all associated functionality have been removed from Exchange 2019. A Sept. 16, 2019, blog on the Exchange Team site indicated Microsoft would push the extended support of Exchange Server 2010 from Jan. 14, 2020, to Oct. 13, 2020, to give Exchange Server 2010 customers more time to complete their migrations.

Administrators who run Exchange Server 2010 workloads on Windows Server 2008 will need to make adjustments due to the Jan. 14, 2020, end of life for that server OS.

Exchange Server 2019 requirements

The following requirements must be met to install Exchange 2019:

• Exchange 2019 can be installed in Active Directory (AD) forests with existing Exchange 2016 and/or 2013 servers. No earlier versions of Exchange may be installed in the same forest as Exchange 2019.
• All domain controllers (DCs) in the AD forest must be running Windows Server 2019 Standard or Datacenter, Windows Server 2016 Standard or Datacenter, or Windows Server 2012 R2 Standard or Datacenter.
• The AD forest function level must be Windows Server 2012 R2 or higher.
• The server hosting Exchange 2019 must use a 64-bit processor.
• The server hosting Exchange 2019 should have between 128 and 256 gigabytes (GB) of random access memory (RAM).
• New Technology File System (NTFS) is required on all disk partitions containing the system partition, Exchange binaries, diagnostic logs and transport database. Resilient File System (ReFS) may be used on partitions containing mailbox databases and transaction logs.

Exchange Server high availability

Exchange Server has several important features to maintain resilience and HA. The mailbox server components of Exchange rely on database availability groups (DAGs). Client access server components rely on load balancing.

Database availability groups

The DAG is the fundamental Exchange subsystem for ensuring HA. The DAG was first introduced in Exchange 2010 and quickly became one of the most important subsystems within Exchange.

The DAG is a group of up to 16 Exchange servers that automatically copies databases between members to provide redundancy in the event of a failure at either the database or the server level. Any member server of a DAG can host a copy of a database from any other member server of the DAG. Once a copy of a database is added to another server, that copy is automatically kept up to date and ready to activate at any time.

The DAG is based on Windows Clustering and not technology that is specific to the Exchange Team itself. This can mean that, sometimes, features and bugs in Windows Server can have a significant impact on how Exchange functions.

Active Manager

Active Manager (AM) is the Exchange component that is responsible for managing failover events within an Exchange environment. AM runs in Microsoft Exchange Replication Service on all Exchange 2016 servers. When an Exchange server is joined to a DAG, two AM roles are run on that server: Primary Active Manager (PAM) and Standby Active Manager (SAM).

The DAG member server that owns the cluster quorum resource will hold the PAM role. If the DAG node holding the quorum resource fails, the PAM role will move to the server that takes ownership of the quorum resource.

The SAM is responsible for providing information to the other Exchange components that are running AM clients about which database copy is currently active. The SAM detects when a database fails and asks the PAM to initiate the failover event. The SAM is not responsible for selecting which copy of the database is activated after a failure. That process is called best copy and server selection (BCSS).

Best copy selection

When a database failure is detected, AM takes steps to recover from the failure by selecting the best copy of the effected database to activate. The BCSS process goes like this:

1. A failure is detected by AM or by Managed Availability. This process can also be started by an administrator who initiates a targetless switchover.
2. The PAM starts the BCSS internal algorithm.
3. The attempt copy last logs (ACLL) subprocess tries to copy any missing log files from the server that last hosted the active copy of the database.
4. When the ACLL process completes, an AutoDatabaseMountDial value is checked for servers hosting copies of the database and is compared to the copy queue length of the database being activated. If the number of missing log files is less than or equal to the value of AutoDatabaseMountDial, AM moves on to step five. If not, AM will start this process over at step two.
5. The PAM issues a mount request to the information store. If the database does not mount, AM goes back to step two.

There is some additional logic in this process if the failover event is trigged by a monitoring event. The additional logic will ensure that the server taking over the active database is in better health than the server it came from.

DAG quorum modes

A DAG is a specific implementation of a Windows Server Cluster. The Exchange components of DAGs rely on the underlying Windows Server Cluster technology to work. The concept of quorum is essential to understanding how to implement and manage DAGs.

Quorum is the idea that, in the event of a failure of some DAG members, there are rules to govern what resources the remaining members can provide. These quorum rule sets exist to provide consistent operation of a DAG and act as a tiebreaker in situations where DAG nodes lose communication with each other.

When a DAG has an even number of nodes, it uses Node & File Share Majority quorum mode. In this mode, an external witness server acts as the tiebreaker. When running in this mode, each DAG node member gets a single vote, but the witness server gives one of the DAG nodes an additional vote. The cluster quorum data is stored on each member's local system disk, but the witness server has a separate file that points to one DAG member as the most updated copy of the DAG cluster quorum data.

When a DAG has an odd number of members, it uses Node Majority quorum mode. In this mode, each DAG member gets a vote, and each member's local system disk is used to store cluster quorum data.

It is possible to manually assign specific DAG members with weighted quorum votes. Doing so is not recommended in most circumstances and should only be done after direct consultation with Microsoft support.

Datacenter Activation Coordination mode

Datacenter Activation Coordination (DAC) mode is a feature of DAGs that is designed to prevent situations in which an outage causes two copies of a database to be live on two different servers. DAC mode requires manual intervention when the server hosting the database cannot reach a majority of the DAG member servers.

Microsoft best practices call for DAC mode to be activated on any DAG that has two or more members and uses continual replication. The only cases where DAC mode for a DAG is not recommended would be if the administrator was using a third-party replication tool.

When DAC is active, there is additional communication between DAG nodes at startup that use the DAC Protocol (DACP). DACP is set to 0 on startup. If the DACP bit remains at 0, AM will not attempt to start any databases on that node. The DACP bit may also be set to 1 if another DAG member has its DACP bit set to 1 or when a DAG node can contact all servers on its DAG membership list.

DAC mode is useful when a primary data center fails completely and a backup data center is activated. When power returns and servers come up before the wide area network (WAN) connection is back online, DAC mode prevents different copies of the same databases from ending up active in both data centers.

For a DAG with two nodes, DAC mode uses a comparison of the boot time of the alternate witness server and the time the DACP bit was set to 1 to determine if it can mount databases. If the DACP bit was set to 1 earlier than the boot time of the alternate witness server, the system assumes that the two servers were rebooted at the same time -- possibly because of a power failure at the primary data center -- and the DAG member is not allowed to mount databases. If the DACP bit was set to 1 after the boot time of the alternate witness server, the system assumes it is safe to mount databases.

DatabaseAvailabilityGroup cmdlets and split-brain conditions

Split brain is a situation where two different copies of the same database become active at the same time in different data centers. When this happens, the two different copies of the database diverge, causing the potential loss of user data when the two different copies attempt to reconcile.

In addition to preventing split-brain conditions, DAC mode enables DatabaseAvailabilityGroup cmdlets to be started, stopped and restored. These cmdlets are used to perform manual data center switchovers. When DAC mode is not active, the process of a manual data center is complex and involves both Exchange tools and a cluster manager.

Imagine a situation where an Exchange environment consists of four servers, each having a copy of the same database. Two of these servers are in data center A and two are in data center B. A network failure occurs in the link between the two data centers. Without DAC mode enabled, it would be possible for servers in each data center to think they needed to activate a copy of the database.

DAC mode prevents this split-brain scenario by requiring node majority before a database can be activated. Node majority means that most of the nodes in the cluster -- or DAG in this case -- need to be online and reachable for a DAG node to be able to activate a database copy. If there are an even number of nodes in the DAG, then the file share witness will also work as a voting member to determine node majority.

In the case described above with a four-node cluster and two nodes in each data center, only the Exchange servers in the data center with the file share witness would be able to activate databases. The DAG nodes in the other data center would be prevented from activating any databases until they were able to contact all servers that are listed as members of the DAG.

Third-site witness

A feature added to Exchange in the 2013 era was support for a third-site witness, which has the power to bring all resources online without administrator intervention. When each site has an independent network path to the third-site witness, the nodes at one site can maintain quorum using the witness server. The downside to using a third-site witness is that Exchange administrators need to take the necessary time to dig in and thoroughly understand their network behavior.

Load balancing

Load balancing is a way for administrators to manage what network traffic ends up being directed to each Exchange server within a network. Usually, it is desirable to manage the distribution of incoming client connections among Exchange 2016 servers for two reasons:

1. To distribute the workload. If someone is going to go to the trouble of setting up and maintaining multiple Exchange servers, it's a good idea to have all those Exchange servers do some work on a regular basis.
2. To reduce the impact of a failure. When something goes wrong, it's nice to have a redundant system to take over the workload of the failed system.

Load balancing complements DAGs. The job of a DAG is: (1) to ensure that there are multiple copies of each mailbox ready to be activated and (2) to accept client requests in case the active copy becomes unavailable. Load balancing works much the same way; its job is to make sure there are other places to send client traffic should one place become unavailable.

Load balancing can span between two or more Exchange servers in a single site, or it can span multiple sites. A Preferred Architecture (PA) Exchange deployment would include four Exchange servers distributed across two separate AD sites. Current versions of Exchange support Layer 4, Layer 7 and domain name system (DNS) round-robin load balancing.

Exchange Preferred Architecture

Exchange PA is the ideal Exchange deployment, as envisioned by the Exchange Team at Microsoft. The PA is developed with total cost of ownership (TCO), HA, resiliency, redundancy and recovery in mind. The PA is not intended to be used as a maturity model; it was designed to be used as inspiration.

Exchange Server clients

Exchange users access and interact with messages through an email client. Microsoft Outlook is the most common client. Exchange Server 2016 also supports the following:

• Outlook 2016
• Outlook 2013
• Outlook 2010 Service Pack 2 (SP2)
• Outlook for Mac for Office 365
• Outlook for Mac 2011

Outlook is also available as a web-based application, called Outlook on the web -- formerly Outlook Web App and commonly abbreviated to OWA -- for users to access and interact with messages from many different web browsers. Outlook on the web lets users link and share documents stored in OneDrive for Business in an on-premises SharePoint server. This creates a simpler and more direct way for end users to save and attach files to emails.

Pros and cons of Exchange Server

While it is easy to talk about the pros of using Microsoft Exchange, it can be difficult to identify any cons, besides licensing costs. Right now, there are few -- if any -- true competitors to Exchange.

Exchange on-premises -- all versions counted together -- probably has the largest active user base, but Microsoft does not publicly release numbers about the number of active users either in Exchange on-premises or Exchange Online. Outlook.com now runs on Exchange, so Exchange on-premises, Exchange Online and Outlook.com probably have more total users (business and personal) than Gmail (business and personal). Any other competing messaging platform after Microsoft's and Google's offerings have comparatively small business user bases.

After Microsoft's and Google's business messaging platforms, the largest solution in terms of installed user base is probably Lotus Notes. Comparisons between Notes and Exchange are difficult because Notes is not primarily a messaging solution. Lotus Notes is a database solution that includes messaging functionality. Furthermore, as of June 30, 2019, IBM has sold ownership of Lotus Notes to HCL and will no longer be updating that product.

Zimbra is the largest Linux-based messaging solution. There are both on-premises and Serial-Attached SCSI (SAS)-based Zimbra solutions available. There are open source versions of Zimbra available, which include different licensing options.

All the different messaging solutions with different features and focuses make a straight pro and con comparison difficult. Below are some high-level pro and con comparisons. These lists are not intended to be definitive.

Exchange on-premises vs. Exchange Online

The most common choice for businesses looking for a messaging solution will be between Exchange on-premises and Exchange Online.

Exchange Online vs. Gmail

Microsoft Exchange Online

Microsoft offers Exchange as a SaaS offering called Exchange Online. It is available as a stand-alone service or as part of the Office 365 suite. End users connect to Exchange Online through the Outlook client or Outlook on the web. Administrators with Office 365 administrative permissions configure and manage the service. Microsoft offers Exchange as a hosted service to reduce the administrative work involved with Exchange on-premises deployments.

Exchange Server pricing

Exchange Server pricing can vary widely based on how it is purchased and which version is being purchased.

Exchange on-premises is sold on a per-server basis. Additionally, a Client Access License (CAL) is required for each user accessing Exchange. Exchange Server must be installed on a server running the Windows Server OS, which also must be licensed with a per-server plus CAL model. The server must be installed in an AD forest with at least one DC.

Exchange Server itself comes in two license levels: Standard and Enterprise. Exchange CALs also come in Standard and Enterprise. Each user must have a Windows Server Standard CAL and may have an Enterprise CAL for additional functionality. Both the Standard and Enterprise CALs can be used with either server edition.

Exchange Online is sold on a per-user, per-month basis either as a stand-alone offering or as part of an Office 365 bundle. There are two stand-alone plans. Exchange Online Plan 1 -- $4 per user, per month -- offers secure and available business email, with a 50 GB mailbox per user. Exchange Online Plan 2 -- $8 per user, per month -- builds on Plan 1 and includes unlimited storage, hosted voicemail and data loss prevention (DLP) functionality.

History of Exchange Server

Exchange Server was first released in a private preview in 1993. In 1996, the first publicly available version of Exchange Server was released as Exchange 4.0. The 4.0 version number in the first release of Exchange was meant to signify it was the upgrade from Microsoft Mail 3.5, but these were two drastically different programs. Exchange 4.0 used the X.500 protocol for directory services and mail delivery.

In 1997, Exchange 5.0 was released. This was the first version of Exchange to feature Simple Mail Transfer Protocol (SMTP) as the mail server delivery protocol. SMTP made Exchange 5.0 the first version able to communicate with other messaging platforms across the internet. Exchange 5.0 also introduced OWA in Exchange 5.0 in a post-release service pack.

Exchange 5.5 was released less than a year after Exchange 5.0 and was the first version of Exchange to come in Standard and Enterprise editions. Exchange 5.5 also included the introduction of recovery for deleted items and support for Internet Message Access Protocol 4 (IMAP4) and Lightweight Directory Access Protocol (LDAP) v3 clients.

Exchange Server 2000 was released two years later to coincide with the release of AD. Exchange 2000 included an Instant Messaging feature that was later spun off to Office Communications Server. Exchange Server 2000 was not widely adopted.

Exchange Server 2003 was a huge step forward for Exchange, both in functionality and adoption. Exchange Server 2003 started the trend of differentiating different Exchange servers to meet different functions. While the same software was installed on all Exchange servers, 2003 did support the idea of designating some servers as front-end servers to host client connections. Exchange 2003 also made migrations from previous versions of Exchange much easier by enabling the coexistence of 2003 servers in organizations that were still running previous versions.

Exchange Server 2007 was another major version that included a lot of new functionality. At release, Exchange 2007 did not support public folders, but that support was returned with Service Pack 1 (SP1) after customer complaints. Exchange 2007 was the first major Microsoft product to fully embrace PowerShell. For the first time, all functionality of Exchange was available as PowerShell commands, although some functionality did not have graphical user interface (GUI) controls.

Exchange 2007 also introduced the concept of fully separate Exchange Server roles. 2007 included five different Exchange Server roles that had separate software installed on the physical server. Four of those roles could be installed on a single physical server if desired, but each role could be installed on its own physical server as well.

Exchange 2007 also introduced UM to provide telephony services "after the call is answered" and included multiple database HA options. These options, which included multiple ways to build a database cluster, ended up being complicated and confusing to deploy and maintain.

Exchange 2010 was a minor release of Exchange Server. The major change in Exchange Server 2010 was the introduction of the DAG and the deprecation of the complicated clustering options from Exchange 2007. Exchange 2010 included and improved upon the server role separation from Exchange 2007, and it improved on the available load-balancing options for better Client Access availability. Office 365 was first released during the Exchange 2010 time frame, and Exchange 2010 included the first Exchange hybrid functionality between Exchange on-premises and Exchange Online.

Exchange 2013 was released on Oct. 11, 2012, alongside new versions of SharePoint and Skype for Business. This release signified Microsoft's intention to create tighter integration among the three Office server products and their Office 365 online versions. Site mailboxes were introduced in Exchange 2013 and included functionality that enabled access to Exchange mailboxes and SharePoint content together.

Exchange 2013 included a significant change to public folders called modern public folders. While the basic functionality of public folders remained the same, the behind-the-scenes architecture was changed to include public folders in the same mailbox databases as user mailboxes. During the lifecycle of Exchange 2013, Microsoft customers started to wonder if Microsoft would continue to develop new versions of Exchange on-premises or would only support Exchange Online. The speculation occurred primarily because new Exchange features started to show up in Exchange Online first, and then they would make it into on-premises versions of the software.

Exchange 2016 removed the ability to install separate Exchange Server roles on separate physical servers except for the Edge Transport role.

Exchange Server 2019 included the ability to install Exchange Server on Windows Server Core. This was the first version of Exchange that could be run and managed with a GUI. All UM features were removed from Exchange 2019 in this release, and new features for Exchange 2019 were added.

Exchange Server versions

The following list shows the version progression of Exchange Server with the corresponding release date and software build:

• Exchange Server 4.0 Standard Edition was first released June 11, 1996, as build 4.0.837.
• Exchange Server 5.0 was first released May 23, 1997, as build 5.0.1457.
• Exchange Server 5.5 was first released Feb. 3, 1998, as build 5.5.1960.
• Exchange 2000 Server was first released Nov. 29, 2000, as build 6.0.4417.
• Exchange Server 2003 was first released Sept. 28, 2003, as build 6.5.6944.
• Exchange Server 2007 was first released March 8, 2007, as build 8.0.685.25.
• Exchange Server 2010 was first released Nov. 9, 2009, as build 14.00.0639.021.
• Exchange Server 2013 was first released Dec. 3, 2012, as build 15.00.0516.032.
• Exchange Server 2016 was first released Oct. 1, 2015, as build 15.01.0225.042.
• Exchange Server 2019 was first released Oct. 14, 2018, as build 15.2.221.12.