Microsoft Exchange 2013

Instructors Notes
.

Lee Morris
Eastern College Moncton
January 2016

11

Contents
Deploying and Managing Microsoft Exchange Server 2013........................................5
Exchange Server 2013 and AD DS Partitions Integration........................................5
Forests.................................................................................................................. 5
Schema Partition.................................................................................................. 5
Configuration Partition......................................................................................... 6
Domain Partition.................................................................................................. 6
Global Catalog......................................................................................................... 6
DNS Server Requirements for Exchange Server 2013.............................................6
SRV Resource Records.......................................................................................... 7
Host Records........................................................................................................ 7
MX Records.......................................................................................................... 7
Software Requirements for Exchange Server 2013.................................................8
Infrastructure Requirements for Exchange Server 2013..........................................8
AD DS Requirements............................................................................................... 9
DNS Requirements.................................................................................................. 9
Preparing AD DS for Exchange Server 2013 Deployment........................................9
Exchange Server Role Architecture in Exchange Server 2013...............................12
Server Roles in Exchange Server 2013..................................................................12
Client Access Server........................................................................................... 13
Mailbox Server................................................................................................... 13
Deployment Options for Exchange Server 2013....................................................14
Exchange Server 2013 Hybrid Deployment with Office 365..................................15
Upgrade and Migration Options............................................................................. 16
Configuring Mailbox Servers in Exchange 2013........................................................17
How the Mailbox Server Role Interacts with Clients and the Client Access Server 18
The Mailbox Store in Exchange Server 2013.........................................................19
Mailbox Store in Exchange 2013........................................................................19
Database Log File Considerations..........................................................................20
Database Log Considerations.............................................................................21
How Are Mailbox Databases Updated?..................................................................22
How are Mailbox Databases Updated.................................................................22
Storage Options for the Exchange Server 2013 Mailbox Server Role....................22

11

DAS.................................................................................................................... 23
SAN.................................................................................................................... 23
RAID................................................................................................................... 24
Importing and Exporting Data from a Mailbox Database.......................................25
Managing Recipient Objects in Microsoft Exchange Server 2013.............................25
Managing Exchange Server 2013 Mailboxes.........................................................25
Types of Exchange Server Recipients....................................................................26
Managing Mailboxes.............................................................................................. 27
Creating Mailboxes............................................................................................. 27
What Are Resource Mailboxes?...........................................................................27
Configuring Resource Booking Settings..............................................................28
What Are Site Mailboxes?...................................................................................28
Configuring Site Mailboxes.................................................................................29
Managing Site Mailboxes with Policies................................................................29
Managing Compliance........................................................................................... 30
What Is a Shared Mailbox?.................................................................................30
Planning and Deploying Client Access Servers in Microsoft Exchange Server 2013. 31
What Is the Client Access Server Role?.................................................................31
Hardware and Software Requirements for the Client Access Server.....................32
Planning Client Access Server Deployment...........................................................33
Requirements for Client Access Server Deployment..........................................33
Options for Client Access Server Deployment....................................................33
How Does a Client Access Server Work?............................................................33
How Does a Client Access Server Work with Multiple Sites?..............................35
Planning and Implementing High Availability in Microsoft Exchange Server 2013....36
What Is a Database Availability Group?.................................................................37
Understanding How Database Availability Groups.............................................38
Understanding How High Availability Works with Client Access Servers...............38
Understanding How Transport High Availability Works..........................................40
Shadow Redundancy.......................................................................................... 40
What Is Site Resilience?..................................................................................... 42
Configuring Highly Available Mailbox Databases................................................43
What Is a Quorum?............................................................................................. 43
Continuous Replication File Mode.....................................................................46

12

11

Deploying and Managing Microsoft Exchange Server 2013

Exchange Server 2013 is the current version of Microsofts email and collaboration suite. It is a
successor to Microsoft Exchange Server 2010. Exchange Server 2013 offers many
enhancements in architecture, functionality, and features for both administrators and end users.
To successfully implement Exchange Server 2013, you should know its prerequisites, as well as
how to deploy it in your existing infrastructure. This post examines how to deploy and manage
Exchange Server 2013.

Exchange Server 2013 and AD DS Partitions Integration

To ensure proper placement of Active Directory components in relation to computers that are
running Exchange Server, you must understand how Exchange Server 2013 communicates with
AD DS and uses Active Directory information to function. AD DS stores most Exchange Server
2013 configuration information.

AD Exchange 2013 Integration

Forests
An Exchange Server organization and an Active Directory forest have a one-to-one relationship.
You cannot have an Exchange Server organization that spans multiple Active Directory forests.
You also cannot have multiple Exchange Server organizations within a single Active Directory
forest.
Note: In Exchange Server 2013, you can also add Office 365 domain to the Exchange
Administration Center (EAC) console. This enables you to manage multiple organizations from
a single management console.
Schema Partition
The Exchange Server 2013 installation process modifies the schema partition to enable the
creation of Exchange Server-specific objects. The installation process also adds Exchange
Server-specific attributes to existing objects. For example, the installation process updates user
objects with additional attributes to describe storage quotas and mailbox features.

12

Configuration Partition
The configuration partition stores configuration information for the Exchange Server 2013
organization. Because AD DS replicates the configuration partition among all domain controllers
in the forest, configuration of the Exchange Server 2013 organization replicates throughout the
forest. The configuration partition includes Exchange Server configuration objects, such as
global settings, email address policies, transport rules, and address lists.
Domain Partition
The domain partition holds information about recipient objects. This includes mailbox-enabled
users, and mail-enabled users, groups, and contacts. Objects that are mailbox-enabled or mailenabled have preconfigured attributes, such as email addresses.

Global Catalog
When you install Exchange Server 2013, the email attributes for mail-enabled and mailboxenabled objects replicate to the global catalog. In the context of Exchange Server, global catalog
is used for the following: The global address list (GAL) is generated from the recipients list in an
Active Directory forests global catalog.
Exchange Server 2013 transport service access the global catalog to find the location of a
recipient mailbox when delivering messages.
Client Access servers access the global catalog server to locate the user Mailbox server and to
display the global address list to Microsoft Office Outlook, Microsoft Outlook Web App, or
Exchange ActiveSync clients.
Note: Because of the importance of the global catalog in an Exchange Server organization,
you must deploy at least one global catalog server in each Active Directory site that contains
an Exchange 2013 server. You must deploy enough global catalog servers to ensure adequate
performance. Exchange Server 2013 does not use Read-Only Domain Controllers(RODCs)
or RODCs that you configure as global catalog servers (ROGC). This means that you
should not deploy an Exchange 2013 server in any site that contains only RODCs or
ROGCs.

DNS Server Requirements for Exchange Server 2013

Each computer that is running Exchange Server must use DNS to locate AD DS and the global
catalog servers. As a site-aware application, Exchange Server 2013 prefers to communicate
with domain controllers that are located in the same site as the computer that is running
Exchange Server. Exchange Server services use DNS to locate a valid domain controller or
global catalog. By default, each time a domain controller starts the Netlogon service, it updates
Domain Name System(DNS) with service (SRV) records that describe the server as a domain
controller and global catalog server, if applicable. To ensure that the domain controller updates
DNS records properly, it is essential that all domain controllers use an internal DNS server that
supports dynamic updates. After DNS records are registered, computers that are running
Exchange Server can use DNS to find domain controllers and global catalog servers.

11

SRV Resource Records

SRV resource records are DNS records that identify servers that provide specific services on the
network. For example, an SRV resource record can contain information to help clients locate a
domain controller in a specific domain or site.
All SRV resource records use a standard format, which consists of several fields that contain
information that AD DS uses to map a service back to the computer that provides the service.
The SRV records for domain controllers and global catalog servers are registered with different
variations to allow locating domain controllers and global catalog servers in several different
ways.
One option is to register DNS records by site name, which enables computers that are running
Exchange Server to find domain controllers and global catalog servers in the local Active
Directory site. Exchange Server always performs DNS resource queries for the local Active
Directory site first.
SRV resource records use the following format:
_Service_.Protocol.Name Ttl Class SRV Priority Weight Port Target
When a computer that is running Exchange Server is a member server, Exchange Server
configures it dynamically with its site each time it authenticates to AD DS. As part of the
authentication process, the registry stores the site name. When the Exchange Server queries DNS
for domain controller or global catalog server records, the Exchange Server always attempts to
connect to domain controllers that have the same site attribute as the Exchange Server.
Host Records
Host records provide host name to IP address mapping. Host records are required for each
domain controller and other hosts that need to be accessible to Exchange Servers or client
computers. Host records can use Internet Protocol version 4 (IPv4), which are A records; or
Internet Protocol version 6 (IPv6) records, which are AAAA records.
MX Records
A Mail Exchanger (MX) record is a resource record that allows servers to locate other servers to
deliver Internet email by using the Simple Mail Transfer Protocol (SMTP). An MX record
identifies the SMTP server that will accept inbound messages for a specific DNS domain. Each
MX record contains a host name and a preference value. When you deploy multiple SMTP
servers that are accessible from the Internet, you can assign equal preference values to each MX
record to enable load balancing between the SMTP servers.
You also can specify a lower preference value for one of the MX records. All messages are
routed through the SMTP server that has the lower preference value MX record, unless that
server is not available.
Note: In addition to SRV, Host, and MX records, you also might need to configure
Sender Policy Framework (SPF) records to support Sender ID spam filtering. In addition, some
organizations use reverse lookups as an option for spam filtering, so you should consider adding
reverse lookup records for all SMTP servers that send your organizations email.

12

Software Requirements for Exchange Server 2013

Exchange Server 2013 requires that some software be preinstalled before you start the
deployment process. First, you should plan for the operating system platforms that will be used
for Exchange Server 2013. The following operating systems are supported for installation of
Exchange Server 2013 roles:
Windows Server 2012 Standard or Datacenter
Windows Server 2008 R2 Standard with Service Pack 1 (SP1)
Windows Server 2008 R2 Enterprise with SP1
Windows Server 2008 R2 Datacenter RTM or newer
Note: Server Core installation option is not a supported operating system option for Exchange
Server 2013 installation. In addition, Windows Server 2008 R2 Standard does not support
failover clustering and cannot use database availability groups (DAGs) in Exchange Server for
high availability. You cannot upgrade Windows Server after you have installed
Exchange.Depending on which Exchange Server role is installed, different Windows components
can be installed on a server. However, you do not need to install these roles and features prior to
Exchange Server installation because the installation process can install the necessary roles and
features automatically.
However, there are additional components that you should install manually. These components,
freely available to download from Microsoft, include:
Microsoft .NET Framework 4.5 (only for Windows Server 2008 and 2008 R2).
Windows Management Framework 3.0 (already included with Windows Server 2012).
Remote Server Administration Tools (RSAT) for AD DS (can be installed with Server
Manager).
Microsoft Unified Communications Managed API 4.0, Core Runtime 64-bit.
Microsoft Office 2010 Filter Pack SP1 64-bit or Microsoft Office 2013 Filter Pack.
Exchange Server Updates for Knowledge Base articles KB974405, KB2619234, and
KB2533623 when installing Exchange Server 2013 on Windows Server 2008 R2.
You also should ensure that the Task Scheduler service is enabled and running on the server
where you plan to install Exchange Server 2013.

Infrastructure Requirements for Exchange Server 2013

Before you deploy Exchange Server 2013 in your organization, you need to ensure that your
organization meets AD DS and DNS requirements.

11

infrastructure requirement for Exchange 2013

AD DS Requirements
You must meet the following AD DS requirements before you can install Exchange Server 2013:
The domain controller that is the schema master must have Windows Server 2012,
Windows Server 2008 R2, Windows Server 2008, or Windows Server 2003 with Service
Pack 2 (SP2). By default, the schema master runs on the first Windows domain controller
installed in a forest.
In each of the sites where you deploy Exchange Server 2013, at least one global catalog server
must be installed and must run Windows Server 2012, Windows Server 2008, Windows Server
2008 R2, or Windows Server 2003 SP2.
In each site where you plan to install Exchange Server 2013, you must have at least one
writable domain controller running Windows Server 2012, Windows Server 2008, or Windows
Server 2008 R2.
The Active Directory domain and forest functional levels must run Windows Server 2003, at
the minimum, or newer versions.

DNS Requirements
Before you install Exchange Server 2013, you must configure DNS correctly in your Active
Directory forest. All servers that run Exchange Server 2013 must be able to locate Active
Directory domain controllers, global catalog servers, and other Exchange Servers.

Preparing AD DS for Exchange Server 2013 Deployment

Before implementing Exchange Server 2013 in your environment, you must prepare AD DS.
AD DS, by default, does not have necessary classes, objects, and attributes defined for the
Exchange Server. By preparing AD DS, you extend the AD DS schema, and also modify
configuration and domain partitions of AD DS. In addition, Exchange Server requires several
groups and special permissions in AD DS; these are also configured during AD DS preparation.

12

You can prepare your AD DS by running the Exchange Sever 2013 Setup Wizard with a
user account that has the permissions required to prepare Active Directory and the domain. To
prepare the AD DS schema and configuration partition, you must use an account that is a
member of the Schema Admins and Enterprise Admins groups. By using this type of account, the
wizard automatically prepares Active Directory and the domain.
Alternatively, you can also prepare AD DS for Exchange Server by running the Exchange Server
2013 setup utility from the command line. If you want to prepare the AD DS schema, and
upgrade it to a version supported by Exchange Server 2013, you should run either of the
following setup commands:
setup /PrepareSchema or setup /ps. To execute this command, you must also be a member in the
Enterprise Admins or Schema Admins groups.
This command performs the following tasks:
Connect the Exchange Server to the schema master domain controller.
Import LDAP Data Interchange Format (LDIF) files to update the schema with Exchange
Server 2013 specific attributes.
Set the schema version (ms-Exch-Schema-Version-Pt) to 15132.
Note: You can also prepare the schema as a part of the PrepareAD procedure, which is
described below.
To prepare AD DS objects and the AD DS configuration partition for Exchange Server 2013, you
should run setup with the /PrepareAD switch, by executing the following command:
Setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms /OrganizationName:Name of
Organization
This command performs the following tasks:
Creates the Microsoft Exchange container if it does not exist; the container is created under
CN=Services,CN=Configuration,DC=<root domain>.
Verifies that the schema has been updated, and that the organization is up to date, by checking
the objectVersion property in Active Directory. The objectVersion property is in the CN=<your
organization>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<domain>
container. The objectVersion value for Exchange Server 2013 is 15448.
Creates all necessary objects and containers needed for Exchange Server 2013, under
CN=<Organization Name>,CN=Microsoft
Exchange,CN=Services,CN=Configuration,DC=<root
domain>.
Creates the default Accepted Domains entry if it does not exist, based on the forest root
namespace, under CN=Transport Settings,CN=<Organization Name>,CN=Microsoft

11

Exchange,CN=Services,CN=Configuration,DC=<root domain>.
Assigns specific permissions throughout the configuration partition.
Imports the Rights.ldf file. This adds the extended rights required for Exchange to install into
Active Directory.
Creates the Microsoft Exchange Security Groups OU in the root domain of the forest, and
assigns specific permissions to this OU.
Creates the management role groups within the Microsoft Exchange Security Groups OU.
Adds the new universal security groups (USGs) that are within the Microsoft Exchange
Security Groups OU to the otherWellKnownObjects attribute stored on the CN=Microsoft
Exchange,CN=Services,CN=Configuration,DC=<root domain> container.
Creates the Unified Messaging Voice Originator contact in the Microsoft Exchange System
Objects container of the root domain.
Prepares the local domain for Exchange Server 2013.
To perform this command, you must be a member of Enterprise Admins security group, and you
must run this command on the computer that is in the same domain as the schema master domain
controller.
If you have more than one domain, you should wait for a period of time after running this
command, so that changes performed to AD DS are replicated to all other domains and domain
controllers.At the end of this process, you should execute the setup /PrepareDomain command in
each domain where Exchange recipients will be located. You do not need to run this command in
a domain where you ran setup /PrepareAD.
Alternatively, you can also run setup /PrepareDomain:<FQDN of domain you want to prepare>
to prepare a specific domain, or you can run setup /PrepareAllDomains or setup /pad to prepare
all domains in your organization.
This command performs the following tasks:
Creates the Microsoft Exchange System Objects container in the root domain partition in AD
DS, and sets permissions on this container for the Exchange Servers, Exchange Organization
Administrators, and Authenticated Users groups.
Sets the objectVersion property in the Microsoft Exchange System Objects container under
DC=<root domain>. This objectVersion property contains the version of domain preparation.
The version for Exchange Server 2013 is 13236.
Creates a domain global group called Exchange Install Domain Servers in the current domain.
Assigns permissions at the domain level for the Exchange Servers USG and the Organization
Management USG.
After all of these commands are successfully completed, your AD DS is ready for Exchange
Server 2013 installation. You can check if preparation went well, by performing the following
tasks: In the Schema naming context, verify that the rangeUpper property on ms-Exch-SchemaVersion-Pt is set to 15132.
In the Configuration naming context, verify that the objectVersion property in the CN=<your
organization>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<domain>
container is set to 15448.
In the Default naming context, verify that the objectVersion property in the Microsoft Exchange
System Objects container under DC=<root domain is set to 13236.
******

12

Exchange Server Role Architecture in Exchange Server 2013

In Exchange Server 2013, Microsoft made major changes in the server role architecture. In
Exchange Server 2007 and Exchange Server 2010, there were five server roles hosting various
functionalities, including:
Mailbox Server role
Client Access role
Hub Transport role
Edge Transport role
Unified Messaging role
In Exchange Server 2013, the number of server roles is greatly reduced, to only these two roles:
Mailbox Server role
Client Access server role
All other roles, except the Edge Transport role (which does not exist in Exchange Server 2013),
are integrated within these two roles.

Server Roles in Exchange Server 2013

Unlike Microsoft Exchange Server 2010, in which the Mailbox Server role hosted only mailbox
and public folder databases and provided email storage, in Exchange Server 2013, the Mailbox
Server role also includes Client Access protocols, Hub Transport service, mailbox databases, and
Unified Messaging components. This means that the functionality of three roles in Exchange
Server 2010 (Mailbox, Hub Transport, and Unified Messaging) is now integrated in only one role
in Exchange Server 2013.
The Client Access Server role has changed in Exchange Server 2013. The Client Access server is
now basically a proxy server that handles all client connections, by admitting all client requests
and routing them to the correct active Mailbox database. It provides authentication, redirection,
and proxy services, and offers support for the following client access protocols: HTTP, POP and
IMAP, and SMTP.
Also unchanged is the fact that the Client Access server does not store any user data on itself; nor
does it do any message queuing. The Client Access server role also provides some security
functionality, by enforcing SSL in communication with clients. In some scenarios where the
Exchange Server is deployed in multiple sites within one organization, the Client Access server
also can redirect the request to a more suitable Client Access server or proxies the connection to
the right Mailbox server.

11

Note: The Edge Transport role is not included in Exchange Server 2013. However, you can
use the Exchange Server 2010 Edge Transport server with Exchange Server 2013 servers.
Client Access Server
The Client Access Server in Exchange Server 2013 provides the following features:
Stateless server. In Exchange Server 2007 and 2010, most of the protocols on the Client Access
server required session affinity in scenarios where the Client Access server was in a loadbalancing cluster. That meant that all requests from a single Outlook Web App client had to be
handled during an entire session by a specific Client Access server within a load-balanced array
of Client Access servers.
In Exchange Server 2013, this is no longer the case, and the Client Access server is now
stateless. All processing for the mailbox now happens on the Mailbox server, so it does not
matter which Client Access server in an array of Client Access servers receives each individual
client request. By implementing this, you can use Layer 4 load balancing instead of the more
expensive Layer 7 load balancing. This allows hardware load balancing devices to support
significantly more concurrent connections.
Connection pooling. As in previous releases of Exchange, the Client Access Server manages
client authentication for client connections and sends AuthN data to the Mailbox server role. The
connection between the Client Access Server and Mailbox server is established by using a
privileged account that is a member of the Exchange Servers group. This allows the Client
Access servers to effectively pool connections to the Mailbox servers. With this technology, a
Client Access array can handle millions of client connections from the Internet or internal
network, but uses many fewer connections to proxy the requests to the Mailbox servers than in
previous versions of Exchange.
Mailbox Server
In Exchange Server 2013, the Mailbox Server role provides much more functionality than in
previous Exchange Server versions. This includes integration of the Hub Transport service
(previously known as the Hub Transport server role) and Unified Messaging service (previously
known as the Unified Messaging server role). This is the key role for storing mailbox and public
folders data, as well as for Unified Messaging functionality and message queuing.
The Mailbox Server role also interacts with the Client Access server, as well as with AD DS
domain controllers and global catalogs. The Mailbox Server role never communicates with
clients directly, as it did in previous versions of Exchange Server. All client-based
communication is performed through the Client Access server role.
Client and Server Communication in Exchange Server 2013
Because of the modifications that were made to the Exchange Server 2013 architecture, changes
were also made to the way in which clients communicate with the Exchange Server, and how
Exchange Server 2013 roles communicate with each other and with AD DS components.
From the client perspective, the most important connectivity change is that remote procedure call
(RPC) is no longer supported as a direct client access protocol. In previous Exchange versions,
Outlook clients from an internal network were connecting to Exchange Server by using RPC (or
MAPI). In Exchange Server
2013, all client connections are established by using RPC over HTTPS. This means that all
clients are connecting by using the Outlook Anywhere service. This eliminates the need to have

12

the RPC service running on the Client Access server. In addition, you will have one fewer FQDN
to manage, because all clients will be using a new connection point made up of the users
mailbox GUID + @ + UPN suffix. As a result of these changes, only Outlook 2007 and newer
clients support connection to Exchange Server 2013.

Deployment Options for Exchange Server 2013

When you plan an Exchange Server 2013 installation, you must decide how you will
organize server roles, and you must choose the appropriate Exchange Server 2013 version.

Exchange Server 2013 is available in both the Standard Edition and Enterprise Edition. The
Standard Edition should meet the messaging needs of most small and medium corporations,
but it also may be suitable for specific server roles or branch offices. The Enterprise Edition,
designed for large enterprise corporations, enables you to create additional databases, and
includes other advanced features. The main difference between Standard and Enterprise versions
is that Enterprise version supports up to 50 mailbox databases while with Standard version you
can create up to five databases. The version used is determined by product key that you enter
when activating your Exchange installation. You should also make sure that you select the
appropriate version of client access license (CAL) from the following options:
Exchange Server Standard CAL. This license provides access to email, shared calendaring,
Outlook Web App, and ActiveSync.
Exchange Server Enterprise CAL. This license requires a standard CAL, and provides access to
additional features such as unified messaging, per-user and per-distribution-list journaling,
managed custom email folders, and Microsoft Forefront Endpoint Protection for Exchange
Server. In general, there are three deployment scenarios that you can choose from, including:
Single server deployment. In this scenario, you deploy both Exchange Server roles on a single
server. This scenario is appropriate for small organizations with limited resources. Deploying all
Exchange Server services on a single server has several drawbacks. These include having a
single point of failure for your whole messaging system, and not having any high-availability
options. If you choose to have a single-server Exchange deployment, it is recommended that you
deploy Exchange Server inside a virtual machine, and that you keep that virtual machine highly
available or at least replicated to another Hyper-V in Windows Server 2012 host. This will
provide you with high availability and redundancy for critical Exchange services.
Multiple server deployment. In the multiple-server deployment scenario, you usually install the
Client Access Server role and the Mailbox server role on separate servers, or you install more

11

than one server with both roles installed. This requires that you provide at least two virtual or
physical machines for the Exchange Server deployment. In scenarios where you also want to
provide high availability, you should add more machines to build the Client Access load
balancing cluster and DAGs. You cannot use DAGs and network load balancing (NLB) on the
same set of machines. To achieve full redundancy for Exchange Server, you need at least four
servers for Exchange, and at least two domain controllers.
Hybrid deployment. A hybrid deployment provides the ability to extend on-premises Exchange
Server functionality to the cloud. In this scenario, you connect your AD DS and Exchange Server
with Microsoft Office 365. This allows you to move some of your Exchange resources to Office
365. A hybrid deployment also can serve as an intermediate step prior to moving completely to
an Exchange Online organization.

Exchange Server 2013 Hybrid Deployment with Office 365

Office 365 is a suite of four Microsoft services that are now available in an online version:
Exchange Online, Lync Online, SharePoint Online, and Office Professional Plus. It is a
subscription-based service that features various pricing options.

Exchange Online provides Exchange Server with email, calendar, and contacts in addition
to antivirus and anti-spam protection. You can connect your existing Exchange Server 2013
organization to Exchange Online to provide rich coexistence for users. In Exchange Server 2013,
it is possible to create a hybrid deployment between
on-premises Exchange Server and Exchange Online from Microsoft Office 365. A hybrid
deployment offers organizations the ability to extend the user experience and administrative
control that they have with their existing on-premises Microsoft Exchange organization to the
Office 365 cloud. A hybrid deployment provides you with a view of a single Exchange
organization between an on-premises organization and a cloud-based organization. In addition, a
hybrid deployment can serve as an intermediate step to moving completely to a cloud-based
Exchange organization.A hybrid deployment of Exchange Server and Office 365 provides the
following features:
Mail routing with a shared domain namespace. For example, both on-premises and cloud-based
organizations use the @adatum.com SMTP domain.
A unified global address list, also called a shared address book. With this address list, users can
view all contacts from both on-premises Exchange and Office 365.
Free/busy and calendar sharing between on-premises and cloud-based organizations.
Centralized control of mail flow. The on-premises organization can control mail flow for the

12

onpremises and cloud-based organizations.

A single Outlook Web App URL for both the on-premises and cloud-based organizations.
The ability to move existing on-premises mailboxes to the cloud-based organization.
Centralized mailbox management using the on-premises Exchange Management Console.
Message tracking, MailTips, and multi-mailbox search between on-premises and cloud-based
organizations.
Cloud-based message archiving for on-premises Exchange mailboxes. Exchange Online
Archiving can be used with a hybrid deployment.
If you want to implement Exchange Server 2013 in a hybrid deployment scenario, you must
configure two very important components to connect your on-premises AD DS and Exchange
infrastructure and Office 365. These include:
Microsoft Federation Gateway. The Microsoft Federation Gateway is a free service that
provides a trust connection between your Exchange Server (installed on premises) and Exchange
Online (as a part of Office 365). It is mandatory that your on-premises Exchange organization
trusts Microsoft Federation Gateway. You can configure this trust relationship manually, or it can
be created automatically as part of configuring a hybrid deployment with the Hybrid
Configuration Wizard. A federation trust with the Microsoft Federation Gateway for your Office
365 tenant is automatically configured when you activate your Office 365 service account.
Active Directory synchronization. If you want to provide services from Exchange Online to
your local users, you must synchronize information from your AD DS to Exchange Online.
Active Directory synchronization replicates on-premises AD DS information for mail-enabled
objects to the Office 365 organization, to support the unified GAL. Organizations that configure
a hybrid deployment must deploy Active Directory synchronization on a separate on-premises
server.

Upgrade and Migration Options

To upgrade your existing Exchange organization to Exchange Server 2013, you cannot directly
upgrade your current Exchange Server byinstalling Exchange Server 2013 over a previous
version. This procedure, which is known as an inplace upgrade, is not supported for Exchange
Server 2013. Instead, you can only upgrade your existing Exchange organization Exchange
Server by installing Exchange Server 2013 on a new
server, and then you can migrate all resources from your previous Exchange Server to Exchange
Server 2013. Once the migration is complete, you can decommission your old Exchange Server.

11

Coexistence of Exchange Server 2013 and earlier versions of Exchange Server is described in
following table:
Exchange version Exchange organization coexistence
Exchange Server 2003 and earlier versions Not supported
Exchange 2007 Supported
Exchange 2010 Supported

Configuring Mailbox Servers in Exchange 2013

The key component of the Microsoft Exchange Server 2013 infrastructure is the Mailbox
server, which hosts mailbox databases and addresses books, handles message transport and
routing, and provides unified messaging services. When you plan an Exchange Server 2013
deployment, it is very important to consider all aspects of your deployment that can affect the
Mailbox server role design. In this post , we will talk about planning and configuring of the
Mailbox server role.
The Mailbox Server Role in Exchange Server 2013 In Exchange Server 2013, the Mailbox server
does much more than it did in Microsoft Exchange Server 2010. In Exchange Server 2010, the
Mailbox server hosts databases and provides email storage. In Exchange Server 2013, the
Mailbox server also hosts Client Access protocols, Transport service components, mailbox
databases, and Unified Messaging components. Although clients never communicate
directly with the Mailbox server, this server interacts actively with the Active Directory
Domain
Services (AD DS) components and Client Access server. It uses the Lightweight Directory
Access Protocol (LDAP) to locate and access information about recipients, servers, and
organization configuration information that is stored in AD DS.
The Mailbox server also participates in high-availability configurations through Database
Availability Groups (DAGs). This concept provides high availability at a database level by
implementing multiple copies on the same database over different mailbox servers. A DAG is a
group of up to 16 Mailbox servers that hosts a set of databases and provides automatic databaselevel recovery from failures that affect individual servers or databases.
Most of the functionality for internal message transport and routing, previously hosted on the
Hub Transport server, is now located on the Mailbox server role. The Hub Transport service,
running on the Mailbox server role, handles all internal Simple Mail Transfer Protocol (SMTP)
mail flow, and performs message categorization and content inspection. In addition to this

12

service, there are two more transport services that run on the Mailbox server role: Mailbox
Transport Submission and Mailbox Transport Delivery. These two services communicate with
the Hub Transport service to send messages to other servers, and also with the mailbox database
to retrieve or submit data to the database. The Unified Messaging server role, which previously
existed as a separate server role, is now also integrated with the Mailbox server role.
Note: The Mailbox server role in Exchange Server 2013 also hosts public folder mailboxes.
Unlike in Exchange Server 2010, public folders do not use separate databases or a separate
replication mechanism.
The Mailbox server role in Exchange Server2013 includes the following new features:
In an evolution of the Exchange Server 2010 DAG, the transaction log code has been refactored
for fast failover, with deep checkpoints on passive database copies.
Servers can be in different locations to support enhanced site resiliency.
Exchange Server 2013 now hosts some Client Access components, including the transport
components and the Unified Messaging components.
The Exchange store has been rewritten in managed code to improve performance in additional
I/O reduction and reliability.
Each Exchange Server 2013 database now runs under its own process.

How the Mailbox Server Role Interacts with Clients and the
Client Access Server
In addition to its communication with AD DS, the Mailbox server role communicates intensively
with the Client Access server. This communication always takes the same paths, even when the
Client Access server role is installed on the same server as the Mailbox server role.

How the Mailbox Server Role Interacts with Clients and the Client Access Server
Because the clients never communicate directly with the Mailbox server, the Client Access server
accepts client requests and sends them to the Mailbox server. The Front End Transport service,
which runs on the Client Access server, accepts and sends messages from the Internet, and then
forwards them to the Hub Transport service running on the Mailbox server.

11

The Client Access server also returns the data (content of the client mailbox) from the Mailbox
server to the clients. In addition, the Client Access server uses NETBIOS file sharing to access
the offline address book (OAB) data from the Mailbox server role. This data is then served to the
clients through the OAB virtual directory on the Client Access server. The Client Access server
also sends messages, free/busy data, and client profile settings between the client server and the
Mailbox server. In previous Exchange Server versions, such as Microsoft Exchange Server 2007
and Exchange Server 2010, internal clients had a direct Messaging Application Program
Interface (MAPI) communication with the Mailbox Server role in some scenarios.
For example, when the client was accessing public folders in Exchange Server 2010, it was
communicating directly with the Mailbox server role. In Exchange Server 2007, the internal
clients were directly communicating with the Mailbox server role, by using MAPI, for all
scenarios.
In Exchange Server 2013, clients no longer communicate directly with the Mailbox server role;
therefore, both internal and external client communication is proxied through the Client Access
server. The Client Access server uses LDAP or the Name Service Provider Interface (NSPI) to
contact the Active Directory server and retrieve the users Active Directory information.

The Mailbox Store in Exchange Server 2013

In Exchange Server 2013, the primary component of the mailbox store is the mailbox database.
Unlike in previous Exchange server versions, in which public folder databases were also present,
Exchange Server 2013 works only with the mailbox databases.

Mailbox Store in Exchange 2013

Mailbox databases contain the data, data definitions, indexes, checksums, flags, and
other information that constitute mailboxes in Exchange Server 2013. Mailbox databases hold
data that is private to an individual user, and contain mailbox folders generated when a mailbox
is created for that user. The mailbox database can be hosted on a single server, or it can be
distributed across multiple Mailbox servers if DAGs are deployed.
The mailbox database is stored in a database file, also known as an Exchange database (.edb)
file. However, this is not the only file that is related to the mailbox database. Exchange Server
2013 uses a set of data files to host and maintain the mailbox database.
These files are:

12

Mailbox database (.edb file). This is the main repository for mailbox data. This file is directly
accessed by the Extensible Storage Engine (ESE). It has a B-tree structure that helps to provide
quick access and enables users to access data on any page within just one input-output cycle.
Transaction log (.log file). Each operation that should be performed on a database, such as
sending or receiving a message, is recorded in the transaction log file. These operations are
called transactions. Operations that are committed to the transaction log are later written to the
database itself (in an .edb file). Until the transaction is committed to the mailbox database, the
only existence of this data is in the RAM memory and in the transaction logs. All transactions,
complete or incomplete, are logged to maintain data integrity in case of a service interruption.
Each database has its own set of transaction logs.
Checkpoint file (.chk). Checkpoint files store data that indicate when a transaction is
successfully committed to the database. The purpose of the checkpoint file is to help the ESE to
replay log files on an inconsistent database in case of database recovery. By using information
from the checkpoint file, the ESE will start with the transaction that is present in the log file, but
is not yet written to checkpoint file. Each databases log prefix determines its checkpoint file
name. For example, the checkpoint file name for a database with the prefix E00 would be
E00.chk. This checkpoint file is several kilobytes in size and does not grow.
Temporary file (Tmp.edb). This is a temporary location used for processing transactions.
Tmp.edb contains temporary information that is deleted when all stores in the storage group are
dismounted or the Exchange Information Store service is stopped. This file does not exceed 1
MB.
Reserve log files (E##res0001.jrs E##res000A.log per database, where ## is the log prefix).
These files are used to reserve space for additional log files if the disk that stores log files
becomes full.
Exchange Server 2013 only uses these files as emergency storage when the disk becomes full,
and it cannot write new transactions to disk. When Exchange Server 2013 runs out of disk space,
it writes the current transaction to disk, using up the space reserved by the 10 reserve transaction
logs, and then dismounts the database. The reserved transaction logs ensure minimal loss of data
that is in transit to the database. The reserved transaction logs are always 1 MB each. Although it
is important to understand the purpose of each mailbox database file, you will interact directly
with these files only rarely. Exchange Server automatically manages these files, so they do not
require administrator intervention, except in cases of database backup and restore.

Database Log File Considerations

Each change that is performed on an Exchange Server mailbox database must be logged in a
transaction log file prior to modification of the database. After each transaction is logged to the
transaction log file, it can be written to the .edb file. To enhance performance, changes performed
on the database are usually available to users right after they are recorded to the transaction log
file.

11

Database Log Considerations

Exchange Server also caches transactions in RAM memory. This is done for both redundancy
and performance reasons. If the database stops, or if the server crashes or experiences any other
system outage, Exchange Server scans the log files and reconstructs and applies any changes not
yet written to the database file. This process is referred to as replaying log files.
The transaction log is not just one file, but instead is a series of log files. Each transaction log file
is exactly 1,024 KB in size. After a transaction log file becomes full, ESE closes it, renames it,
and opens a new transaction log file.
The naming syntax for the transaction log file is Enn0000000x.log, where nn refers to a two-digit
number known as the base name or log prefix, and x is the sequential number of the log file. It is
important to know that log files are numbered in a hexadecimal system, not in a decimal system.
For example, the log file that comes after E0000000009.log is not E0000000010.log, but
E000000000A.log. Transaction log files are not deleted automatically. Usually, when a database
is backed up, the backup software deletes the transaction log files. Because a mailbox database
cannot be backed up in the way other files can, it is very important to have Exchange-aware
backup software that will properly handle transaction log files when performing backup and
restore operations. If the transaction log files are not deleted regularly, they can fill up the disk
space, which can cause Exchange services to stop working. We do not recommend manually
deleting transaction log files, because that approach can interfere with your regular backup
procedure. You can configure Exchange Server to perform circular logging. When the circular
logging option is enabled, transaction log files will be overwritten after the transactions from the
log file are committed to the mailbox database. However, this approach is not recommended in a
production environment, because it affects the ability to back up and restore to the mailbox
database. For example, if you have circular logging enabled, you can recover data only up to the
time when you performed the last full backup of your database.
If you do not use circular logging, then you are able to use incremental backups, and you
also have the ability to restore the database from the incremental backup. By default, circular
logging is disabled.
To properly maintain transaction logs as well as the mailbox database, we recommend that you
follow these guidelines:
Regularly perform Exchange Server backups with Exchange-aware backup software.

12

Move transaction logs to a dedicated drive that supports heavy write load.
Place transaction log files on a redundant disk array, using redundant array of independent disks
(RAID) technology. We recommend that you use a RAID 1 volume. However, if you protect
your mailbox databases with a DAG, it might be unnecessary to use a dedicated storage for the
transaction log files.
Ensure that the volume that hosts the transaction log files has enough free disk space to store all
files created between two backup cycles.
Do not use compression on drives that store transaction log files.
Do not use circular logging, except in a test environment.

How Are Mailbox Databases Updated?

Although database modification is an automated process, it is not directly visible to
the administrator or the end user. It is important that you understand how the database is being
modified during normal operations.

How are Mailbox Databases Updated

The following process takes place when a Mailbox server receives a message:
1. The Mailbox server receives the message. This occurs when the Hub Transport service
on the Mailbox server accepts the message from the Front End Transport service that is
running on the Client Access server. After the Hub Transport service accepts the message, it is
passed to the Mailbox Transport service.
2. Before the message is written to the databases, the Mailbox server writes the message to the
current transaction log and the memory cache simultaneously.
3. The Mailbox server writes the transaction from the memory cache to the appropriate database.
4. The Mailbox server updates the checkpoint file to indicate that the transaction was committed
successfully to the database.
5. Client Servers can access and read the message in the database.

Storage Options for the Exchange Server 2013 Mailbox

Server Role
Exchange Server 2013 supports various hardware technologies for disk storage, including Serial
Advanced Technology Attachment (SATA), Solid-state drive (SSD), and Serial Attached small

11

computer system interface (SCSI), known as SAS (Serial Attached SCSI) or iSCSI drivers.
When
selecting which storage solution to use, the goal is to ensure that the storage will provide the
performance that your environment requires. In Exchange Server 2013, disk I/O is further
reduced compared to previous versions of Exchange Server. This enables you to use less
expensive, slower disks and storage systems without any significant decrease in performance.
When choosing a storage technology for Exchange Server, the most common choices are, DAS,
SAN, or RAID.
DAS
Direct attached storage (DAS) is any disk system that is physically connected to your server.
This includes hard disks inside the server or those that are connected by using an external
enclosure. Some external enclosures include hardware-based RAID. For example, external disk
enclosures can combine multiple disks in a RAID 5 set that appear to the server as a single large
disk. In general, DAS provides good performance, but it provides limited scalability because of
the units physical size. You must manage direct attached storage on a server-by-server basis.
Exchange Server 2013 performs well with the scalability and performance characteristics of
DAS.
DAS provides the following benefits:
Lower-cost Exchange Server solution. Direct attached storage usually provides a substantially
lower purchase cost than other technologies.
Easy implementation. Direct attached storage typically is easy to manage, and requires very
little training.
Distributed failure points. Each Exchange server has separate disk systems, so the failure of a
single system does not affect the entire Exchange messaging system negatively, assuming that
you configure your Exchange servers for high availability.
SAN
A storage area network (SAN) is a network dedicated to providing servers with access to storage
devices. A SAN provides advanced storage and management capabilities, such as data snapshots
and high performance. SANs use either Fibre Channel switching or Internet SCSI (iSCSI) to
provide fast and reliable connectivity between storage and applications. Fibre Channel switching
or iSCSI allows many servers to connect to a single SAN.
Fibre Channel is a standard SAN architecture that runs on fiber optic cabling. Most SANs use it
because Fibre Channel is used specifically for SANs, and it is the fastest architecture available.
SANs are complex and require specialized knowledge to design, operate, and maintain. Most
SANs also are more expensive than DAS options.
SANs provide the following benefits:
A large RAM cache that keeps disk access from becoming a bottleneck. The reduced I/O
requirements of Exchange Server 2013 make it more likely that an iSCSI-based SAN will meet
your requirements in small and medium-sized deployments. However, you should test all
hardware configurations thoroughly before deployment to ensure that they meet your
organizations required performance characteristics.

12

Highly scalable storage solutions. Messaging systems are growing continually and require
larger storage over time. As your needs expand, a SAN allows you to add disks to your storage.
Most SANs incorporate storage virtualization, which allows you to add disks and allocate the
new disks to your Exchange server.
Multiple servers attached to a single SAN. If you use a SAN, you can connect multiple
computers that are running Exchange Server, and then divide the storage among them.
Enhanced backup, recovery, and availability. SANs use volume-mirroring and snapshot
backups. Because SANs allow multiple connections, you can connect high-performance backup
devices to the SAN. SANs also allow you to designate different RAID levels to different storage
partitions. For cost-conscious SAN implementations, iSCSI may be a viable option. An iSCSI
network encapsulates SCSI commands in TCP/IP packets over standard Ethernet cabling and
switches. You should implement this technology only on dedicated storage networks that are 1
gigabit per second (Gbps) or faster.
RAID
To provide redundancy on any storage options, you have to use RAID technology. RAID can be
used to provide better disk performance or fault tolerance. The most common RAID options are:
RAID 0 (striping). Increases read and write performance by spreading data across multiple
disks. However, it offers no fault tolerance. Performance increases as you add more disks. You
add fault tolerance by using multiple copies of the databases on separate RAID sets.
RAID 1 (mirroring). Increases fault tolerance by placing redundant copies of data on two
disks. Read performance is faster than a single disk, but write performance is slower than RAID
0. Half of the disks are used for data redundancy.
RAID 5 (striping with parity). Increases fault tolerance by spreading data and parity
information across three or more disks. If one disk fails, the missing data is calculated based on
the remaining disks. Read and write performance for RAID 5 is slower than with RAID 0. At
most, only one third of the disks are used to store parity information.
RAID 0+1 (mirrored striped sets). Increases fault tolerance by mirroring two RAID 0 sets.
This provides very fast read and write performance, and excellent fault tolerance.
RAID 6 (striping with double parity). Increases fault tolerance by spreading data and parity
information across four or more disks. If up to two disks fail, RAID 6 calculates the missing data
based on data and parity information stored on the remaining disks. Read and write performance
for RAID 6 typically is slower than RAID 0, and RAID 6 does not have a read penalty. The main
benefit of RAID 6 is the ability to rebuild missing data if you have two failures per RAID group,
and to reduce the impact of rebuilding the RAID set when a disk fails.
RAID 1+0 or RAID 10 (mirrored sets in a striped set). Provides fault tolerance and
improved
performance, but increases complexity. The difference between RAID 0+1 and RAID 1+0 is that
RAID 1+0 creates a striped set from a series of mirrored drives. In a failed-disk situation, RAID
1+0 performs better and is more fault tolerant than RAID 0+1.
Just a bunch of disks (JBOD). JBOD is a collection of disks that have no redundancy or fault
tolerance. JBOD solutions are usually lower in cost than solutions that use RAID. JBOD adds
fault tolerance by using multiple copies of the databases on separate disks, which you can use
when you protect your databases with DAGs.

11

Importing and Exporting Data from a Mailbox Database

In some scenarios, you might want to export data from the users database or import data
to the users database. For example, because of compliance or legal reasons, you may be required
to export mailbox content from a specific user to a personal storage file (.pst) file. For other
purposes, you might want to perform a snapshot of a specific mailbox.
In yet another scenario, you might want to import data from a .pst file from a legacy application
to a users mailbox on the Exchange Server. For example, if a user was using a Windows Mail
application, all of the users data was being stored in a .pst file. It is common to import data from
the users .pst file to the users new mailbox on the Exchange Server, or to the users archive
mailbox.
In Exchange Server 2013, you can use the New-MailboxImportRequest or
NewMailboxExportRequest cmdlets to import or export data from the users mailbox. Requests
for mailbox import or export must be executed from the Exchange Management Shell. After you
run one of these cmdlets, the process is completed asynchronously by the Microsoft Exchange
Mailbox Replication service. This service takes advantage of the queuing and throttling
frameworks to optimize Exchange performance during import or export operations.
Note: To use the New-MailboxImportRequest or New-MailboxExportRequest cmdlets,
the Mailbox Import Export role must be assigned to you. By default, this role is unassigned.
Exchange Server 2013 includes a personal folders file (.pst) provider, so it can natively read and
write .pst files. The .pst files can be stored locally or they can reside on a shared folder. However,
if you are using share folders as a .pst location, you must ensure that you grant read/write
permissions to the Exchange Trusted Subsystem group for the specific shared folder.
Exchange Server 2013 supports only Unicode files created by Office Outlook 2007, Outlook
2010 and newer versions. Data from a .pst file can be imported to a users mailbox or to an
online archive if it is enabled for a users mailbox. In addition, Exchange Server 2013 can import
or export multiple .pst files at the same time, which can speed up the process. However, the
import or export process can take several hours to complete, depending on the file size and
network bandwidth. Note: The maximum supported size for a .pst file is 50 gigabytes (GB). If a
mailbox that you want to export is larger than 50 GB, you can create multiple .pst files. You can
use filters to specify selected folders for export instead of the entire mailbox. You can also
include or exclude specific folders using the IncludeFolders or ExcludeFolders parameters.
When you import data from a .pst file, you must ensure that the mailbox exists prior to starting
the import process. You can import data to a different user account than the one from which it
was exported.

Managing Recipient Objects in Microsoft Exchange Server

2013

Managing Exchange Server 2013 Mailboxes

Two of the most common tasks that Exchange Server administrators perform are creating and
configuring email recipients. As organizations hire new employees, or employees change
positions within the organization, the Exchange administrators need to make sure that the users
have the messaging functionality that they require. Most users in an organization will use

12

Exchange Server mailboxes, although Exchange Server 2013 also provides various other
mailbox options that can be configured.

Types of Exchange Server Recipients

Exchange Server recipients are any objects within thethe Active Directory Domain Services (AD
DS) forest that have been configured with an email address. When AD DS objects are configured
with an email address, they appear in the Global Address List (GAL). Exchange Server 2013
supports the following recipient types:

User mailboxes. A mailbox that you assign to an individual user in your Exchange Server
organization. This is the most common type of recipient in Exchange Server 2013.
Mail contacts. Contacts that contain information about people or organizations that exist
outside an Exchange Server organization and that have an external email address. Exchange
Server routes all messages sent to the mail contact to
this external e-mail address.
Mail users. Users who have an AD DS user account but have an external email address. All
messages sent to the mail user are routed to this external email address. A mail user is similar to a
mail contact, except that a mail user has an AD DS user account with a security identifier (SID).
This allows the user account to access resources in the AD DS environment.
Resource mailboxes (room mailboxes and equipment mailboxes). A resource
mailbox is configured for objects such as meeting rooms, or resources such as a projector. You
can include resource mailboxes as resources in meeting requests, which provides a simple and
efficient way of scheduling resource usage.
Shared mailboxes. A mailbox that is used by multiple users rather than one primary user.
Organizations often use shared mailboxes to provide services such as sales, help desk, or
general information requests.
Mail-enabled security and distribution groups. You can use a mail-enabled AD DS
security group object to grant access permissions to AD DS resources, and you also can use it to
distribute messages. You can use a mail-enabled AD DS distribution group object to distribute
messages to a group of recipients.
Dynamic distribution groups. A distribution group that uses a Lightweight Directory
Access Protocol (LDAP) query with recipient filters and conditions to derive its membership at
the time messages are sent.
Linked mailboxes. Regular mailboxes that are associated with individual users in a
separate, trusted forest. When you create a linked mailbox, a disabled user account is created in
the Exchange organization, and a user account from a trusted forest is given access to the
mailbox.
Remote mailboxes. Mailboxes that are located in the Exchange Online environment. In a
hybrid Exchange Server 2013 deployment, you can create and manage remote mailboxes in the
Exchange Online environment by using the Exchange Administration Center (EAC).
Site mailboxes. Mailboxes that include both an Exchange Server mailbox and a Microsoft

11

SharePoint site. With site mailboxes, messages are stored in the mailbox, whereas documents are
stored on the SharePoint site.

Managing Mailboxes

Creating Mailboxes
Most mailboxes in an Exchange Server organization are regular mailboxes associated
with a user account in the AD DS forest. You can create these mailboxes using the EAC or
using the Exchange Management Shell. When creating a mailbox, you have the following
options: You can associate the mailbox with an existing AD DS user account, or you can
create a new AD DS account when you create the mailbox. To create a new mailbox and
user account in the Exchange Management Shell, use the New-Mailbox cmdlet. To configure an
existing user account with a mailbox, use the Enable-Mailbox cmdlet.

You can choose a specific mailbox database for the mailbox, or accept the default, which means
that Exchange will assign the mailbox to any mailbox database in the same AD DS site.
You can assign an address book view to the mailbox.
If you create or enable the user mailbox using the Exchange Management Shell, you can assign
other attributes to the mailbox.
What Are Resource Mailboxes?
Resource mailboxes are specific types of mailboxes that you can use to represent meeting
rooms or shared equipment, and you can include them as resources in meeting requests. The AD
DS user account that is associated with a resource mailbox is disabled. You can create two
different types of resource mailboxes in Exchange Server 2013:

12

Room mailboxes. Resource mailboxes that

you can assign to meeting locations, such as
conference rooms, auditoriums, and training rooms.
Equipment mailboxes. Resource mailboxes that you can assign to resources that are not
locationspecific, such as portable computer projectors, microphones, or company cars.
You can include both types of resource mailboxes as resources in meeting requests, which
provides a simple and efficient way for users to book these resources. After creating the resource
mailbox, you must configure properties such as location and size. These attributes are useful for
enabling users to search for meeting rooms that meet their requirements.

Configuring Resource Booking Settings

When you configure a resource mailbox, you can also configure settings that determine how the
resource mailbox will respond to meeting requests. You can configure resource mailboxes to
automatically process incoming meeting requests for all users, or you can restrict who can book
the meeting room. You can configure delegates who have to approve all meeting requests, and
you can also configure the resource mailbox to accept only certain types of meetings. For
example, you can configure a conference room to automatically accept incoming meeting
requests but not accept recurring meeting requests.
What Are Site Mailboxes?
One issue that users face when they work collaboratively is that information can be stored in
several different locations. Users who are working on the same project might need to exchange
emails related to the project, and they might also need to access shared documents stored on file
shares or on a SharePoint Server 2013 site. Site mailboxes in Exchange Server 2013 provide a
more integrated experience for users who need to collaborate. Site mailboxes enable users to
access both documents stored on SharePoint 2013 and email stored in an Exchange Server 2013
mailbox using the same client interface.

11

Understanding How Site Mailboxes Work

A site mailbox provides integration between a SharePoint site and an Exchange mailbox. For
example, a group of users may be working on a project that requires email communication as
well as a document review process. With site mailboxes, users can send and read email messages
in the site mailbox. Users can also post documents and review documents on the SharePoint site.
The benefit of site mailboxes is that users can access both types of content from a single
interface. Site mailboxes are available in Outlook 2013 and can be used to view both the email
messages in the mailbox and the documents stored in SharePoint. The same content can also be
accessed directly from the SharePoint site. With site mailboxes, Exchange stores the email,
providing users with the same email conversations that they use every day for their own
mailboxes. SharePoint stores the documents and provides advanced document management tools
such as version control.
Configuring Site Mailboxes
Site mailboxes are managed through SharePoint. To implement site mailboxes, you must
configure Secure Sockets Layer (SSL) and configure OAuth authorization between the
SharePoint 2013 server and the Exchange Server 2013 server.
Once the integration is configured, administrators or users with delegated permissions can create
site mailboxes on the SharePoint server by using the Site Mailbox application. Outlook users can
then add the site mailbox to their Outlook 2013 profile.
Managing Site Mailboxes with Policies
You can manage site mailboxes using both Exchange Server 2013 policies and SharePoint 2013
policies.
In Exchange, you can configure site mailbox quotas by using the SiteMailboxProvisioningPolicy
cmdlets in the Exchange Management Shell. You can configure the maximum size for the site
mailbox, and the maximum message size that can be sent to the mailbox.
In SharePoint, you can configure policies for those who can create site mailboxes, and you can
configure SharePoint Lifecycle policies to manage the lifecycle of a site mailbox. For example,
you can create a lifecycle policy in SharePoint that automatically closes all site mailboxes after
six months. When the lifecycle application in SharePoint closes a site mailbox, the site mailbox
is retained in SharePoint for a defined period of time. The mailbox can then be reactivated by the
mailbox user or by a SharePoint administrator.

12

After the retention period, the Exchange site mailbox in the mailbox database will have the
prefix MDEL: added to the mailbox name to indicate that it has been marked for deletion. The
mailboxes are not automatically removed from Exchange; you must manually remove these site
mailboxes.

Managing Compliance
Site mailboxes can be part of the In-Place eDiscovery scope in SharePoint 2013 when you
perform keyword searches against user mailboxes or site mailboxes. In addition, you can put a
site mailbox on legal hold.
Note: For detailed information on how to configure site mailboxes, see the Configure site
mailboxes in SharePoint Server 2013 page at http://go.microsoft.com/fwlink/?LinkId=290960.
What Is a Shared Mailbox?
Many organizations need to have multiple users access the same mailbox. For example,
an organization may provide an email address such as info@adatum.com on a public web site.
The organization may want to have several users monitor the mailbox associated with this
email address to ensure prompt replies to potential customers. In previous versions of
Exchange Server, you could create a mailbox for this purpose, and then give multiple users
access to this mailbox.
Exchange Server 2013 simplifies the process of creating this type of mailbox by providing
shared mailboxes. A shared mailbox is a special type of user
mailbox in which the user account associated with the mailbox is a disabled account, and other
users are granted access to the mailbox. To gain access to the mailbox, users with the required
permissions sign into their own mailboxes, and then open the shared mailbox by adding the
shared mailbox to their Outlook profile or by accessing the mailbox through Outlook Web App.
Note: When a users Outlook profile is configured in cache mode, all mailboxes to which
the user has Full Access permissions will be downloaded and cached on the local machine. This
behavior can be modified so that only the primary mailboxes and non-mail folders such as the
Calendar, Contacts, and Tasks folders for the other mailboxes are cached. You can edit the
registry or use Group Policy Objects to configure this setting.
For more information, see
http://go.microsoft.com/fwlink/?LinkId=290961 for details.
In Exchange Server 2013, creating a shared mailbox is a single-step process using the EAC or
the Exchange Management Shell. You can create a shared mailbox and grant users Full Access
and Send As mailbox permissions when you create the mailbox.
When you grant a user Full Access permission to the shared mailbox, the delegated user can log
on to the mailbox, and view and manage all messages in the mailbox. Granting Full Access
permissions does not grant the delegated user the right to send mail as the selected mailbox. To
allow a user to send mail from a delegated mailbox, you must also assign Send As permissions.
When a user with Send As permissions sends a message from the delegated mailbox, any

11

message sent from the mailbox will appear as if it were sent by the mailbox owner.
Note: You also can enable delegated users to access regular mailboxes rather than creating
shared mailboxes. When you configure delegate access to a regular mailbox, you also can grant
a Send on Behalf Of permission. This permission allows a delegated user to send messages from
the mailbox, but the From: address in any message sent by the delegate shows that the message
was sent by the delegate on behalf of the mailbox owner.

Planning and Deploying Client Access Servers in Microsoft

Exchange Server 2013
Microsoft Exchange Server 2013 provides access to user mailboxes for many different clients.
All messaging clients access Exchange Server mailboxes through a Client Access server.
Because of the importance of this server role, you must understand how to plan, deploy, and
configure it to support various client types.
The first step in deploying client access to Exchange Server mailboxes is planning the Client
Access server deployment and configuration. You must consider several factors when designing
deployment, including the hardware configuration and how you will provide access to the
services enabled on the Client Access server.

What Is the Client Access Server Role?

The Client Access server role in Exchange Server 2013 is one of two key roles for the entire
messaging infrastructure. In fact, it is a mandatory component for each Exchange Server
deployment. The primary purpose of the Client Access server role is to accept and handle client
connections and server Simple Mail Transfer Protocol(SMTP)-based connections, and proxy
these connections to the Mailbox server.

The Client Access server also authenticates client connections, and provides content from
the Mailbox server role to the clients. In Exchange Server 2013, clients cannot initiate a
connection to the Mailbox server directly, in any scenario. All connections are routed through the
Client Access Server, which provides proxy services, and in Unified Messaging (UM) scenario
redirection, to the Mailbox server role. The Client Access server accepts SMTP connections from

12

other SMTP servers on the Internet, and also establishes SMTP connections to the other SMTP
servers on the Internet. Unlike a Mailbox server, the Client Access server does not store any user
data; nor does it perform any kind of message queuing. The Client Access server sends and
accepts messages to and from the Internet by using its Front End Transport service, but it does
not have the ability to accept and store messages for later delivery. Front End Transport service
should not be confused with, or mistakenly identified as a replacement for Hub or Edge
Transport server role from previous Exchange Server versions. It is simply a proxy for both
client and server connections; actual email processing, and sending and receiving, happens on
the Mailbox server role.
The Client Access server also provides services for messaging security. For clients, it provides
Secure Sockets Layer (SSL)-based communication and authentication. The Client Access server
also provides antimalware and anti-spam functionality as SMTP traffic passes through it. The
Client Access servers Front End Transport service cannot 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. In addition, unlike Exchange Server 2010, which
did not have an integrated anti-malware solution, Exchange Server 2013 allows you to configure
anti-malware options for virus scanning. You should note that the Client Access server in
Exchange Server 2013 does not have a transport agent for connection filtering that is enabled by
default. You can create a transport agent if you need one.

Hardware and Software Requirements for the Client Access

Server
When you plan a Client Access server deployment, you should consider general Exchange
Server hardware and software requirements. If you choose to deploy a Client Access server
together with the Mailbox server role, you should follow the hardware requirements for the
Mailbox server, as it is a more resource-intensive role. If you choose to deploy the Client Access
server on a separate server, the same software requirements that are discussed in this course will
apply;
however, you should design the Client Access server and Mailbox server hardware separately.
The Client Access server does not store any user data, so you do not have to provide separate
storage for it. However, because this role is critical in an Exchange Server infrastructure, you
should make sure that the Client Access servers hard drive is redundant (for example, in mirror
configuration). We also recommend that you deploy more than one Client Access server, if
possible. If you deploy the Client Access server on the virtual machine, ensure that the machine
is highly available.
Consider the following guidelines when designing the Client Access server configuration:
There is no specific recommended processor configuration for Client Access servers. However,
we recommend that you use a minimum of two processor cores, and a maximum of 12 processor
cores.
The recommended memory configuration depends on the number of client connections and
the transaction rate for a Client Access server. The recommended random access memory (RAM)

11

for Client Access servers is 2 gigabytes (GB) of RAM per processor core, with a minimum of 8
GB of RAM.
The Client Access server is not a hard disk-intensive application, so you do not have to
implement fast and expensive hard drives for it. You should make sure that the hard drives you
select are reliable and certified to work all day, all of the time.
The Client Access server requires a fast network connection to Mailbox servers and globalcatalog servers. If you have a large number of internal Microsoft Office Outlook clients, the
network connection may become a bottleneck. To reduce network bottleneck, configure the
Client Access server with multiple 1-gigabits-per-second (Gbps) network cards.
As a general guideline, you should deploy one Client Access server for every four Mailbox
servers. However, we recommend that you have more than one Client Access server, for
redundancy and load balancing purposes.

Planning Client Access Server Deployment

When you plan your Client Access server deployment, you must meet certain requirements
to ensure a successful installation. In addition, there are options for deploying Client Access
servers in scenarios where servers require high availability, or when multiple sites are deployed.
Requirements for Client Access Server Deployment
When you deploy Client Access servers, you must meet the following requirements:
You must have one Client Access server in each Active Directory site where you have Mailbox
servers deployed.
If your Active Directory Domain Services (AD DS) forest includes multiple domains, each
site must have a Client Access server for each domain that includes Mailbox servers in that site.
Client Access servers should have a fast network connection to Mailbox servers.
Client Access servers should have a fast network connection to domain controllers and globalcatalog servers.
If users must access their mailboxes from the Internet through the Client Access server, then
the server must be accessible from the Internet using HTTPS, IMAP4, or POP3.
Note: Because the server running the Client Access server role must be a member server
in an Active Directory domain, you cannot deploy the Client Access server role in a perimeter
network. Instead, use an application layer firewall, to publish the Client Access server services to
the Internet.
Options for Client Access Server Deployment
The Client Access server role performs a critical function in your Exchange Server organization.
The following options are available when you deploy the Client Access server role:
You can deploy the Client Access server role on the same computer where the Mailbox server
role resides. Installing all server roles on a single server does not provide additional availability,
and offers only limited scalability.
You can deploy the Client Access server role on a dedicated server. This deployment provides
additional scalability and performance benefits.
You can deploy multiple servers running the Client Access server role. To provide high

12

availability for Client Access servers, you can deploy Windows Network Load Balancing (NLB)
or a hardware network load balancer to manage connections to the Client Access servers.
Note: You can install Client Access servers on Mailbox servers that are database availability
group (DAG) members. However, just adding the Client Access server to a DAG member does
not provide high availability for the Client Access server. This is because DAG uses failover
clustering, which does not work with Windows load balancing on the same machine. However,
you can use a hardware load balancer for the Client Access server in this scenario.
How Does a Client Access Server Work?
In Exchange Server 2013, all messaging clients connect to a Client Access server when accessing
an Exchange Server mailbox. The main purpose of the Client Access server is to accept,
authenticate, and proxy or redirect client connections, while also handling SMTP message traffic
with other SMTP servers. However, the Client Access server works differently in Exchange
Server 2013 compared to the same role in Microsoft Exchange Server 2007 and Exchange Server

2010.
One of the most significant changes is the way that the Client Access array communicates
with clients and the Mailbox server. In previous versions of Exchange Server, internal clients
used Messaging Application Programming Interface (MAPI) remote procedure call (RPC) to
connect to the Client Access server or Mailbox server, while external clients used the RPC over
HTTPS, HTTPS, POP3, or IMAP4 protocol.
In Exchange Server 2013, MAPI over RPC is still the protocol that Outlook uses, however it is
now, by default, packed inside HTTPS, regardless of how the client connects. The connection
from the client to the mailbox still goes through Client Access server. The Client Access server
proxies the RPC over HTTPS connection from the client to the Mailbox server.
The following image is a diagram that shows how a Client Access server works.
Note: To better understand how these connections work, you should understand the
following key components that participate in this process:
MAPI. This is the set of protocol commands that Outlook clients use to interact with the
mailbox server when it is accessing and managing mailboxes. MAPI is the language that all of
the servers talk, and it provides client access to mailboxes. MAPI commands are wrapped
within RPC.

11

RPC. This is the transport through which MAPI commands are issued to the Mailbox server.
HTTPS. This is the transport protocol, and it securely wraps MAPI/RPC commands that are
distributed between clients and servers.
On the Client Access server in Exchange Server 2010, the RPC/HTTP proxy is the Internet
Information Services (IIS) component that terminates HTTP traffic. Once the HTTP traffic is
terminated, the RPC traffic on the rest of network path is allowed. However, when the Client
Access server in Exchange Server 2013 terminates the HTTPS traffic, it decrypts it and inspects
MAPI/RPC commands. Then the traffic is reencrypted back with HTTPS, and sent to the
Mailbox server. Next, the traffic hits the RPC proxy endpoint on the Mailbox server IIS. This
endpoint component strips off the HTTPS, and then MAPI commands are executed on the
Mailbox server with a RPC. The server, based on the parameters contained within RPC
request, should find and send the correct endpoint on the Mailbox server when the client RPC
over the HTTPS connection reaches the Clients Access server.
In a manner similar to the connections from Outlook clients, POP3 and IMAP are proxied to the
appropriate services on the Mailbox server role. SMTP connections from other SMTP servers are
inspected and the Client Access Server proxies them to the Transport component on the Mailbox
server. The Client Access server UM Call Router component redirects clients to the UM
component on the Mailbox Server role only for Unified Messaging communication.
How Does a Client Access Server Work with Multiple Sites?
Deploying Client Access servers in an environment with multiple AD DS sites adds complexity
to deployment planning, particularly when you consider the options for providing Internet access
to those Client Access servers.

In a single-site scenario, the Client Access server communicates directly with Mailbox
servers. However, in multiple-site scenario, things can work differently. In previous Exchange
Server versions, such as the 2007 or 2010 versions, in a multiplesite scenario, Exchange Server
directed clients to a Client Access server located in the same site as the Mailbox server, or a
Client Access server in a remote site proxied a request to a Client Access server in the same site
as the Mailbox server. Exchange Server 2013 no longer uses FQDNs of Client Access servers or
arrays to locate user mailboxes. Instead, Client Access server uses the GUID that is assigned to
the user mailbox. When the client connects to the Client Access server and requests the mailbox
content, the Client Access server performs a query on AD DS to determine the details of the

12

client mailbox based on mailboxs GUID. These details include data about the mailbox server
that hosts the user mailbox. The Client Access server then uses RPC over HTTPS to connect to
the Mailbox server and then retrieves the users data. Because of this approach, when
configuring an Outlook profile for the user, the server name will not be Client Access server (or
Client Access server array) anymore. Instead, the connection point is the string that is a unique
identifier of the mailbox. It contains the mailbox GUID and domain name part that is the primary
domain name for the user. A unique mailbox identifier is user specific. This information uniquely
identifies the user and the mailbox. This is effectively the target for the RPC requests that the
user makes in Outlook. In addition, this information is used to enable Client Access server to find
the appropriate Mailbox server for the user at any time. From the Outlook perspective, the
unique mailbox identifier is actually the Mailbox server, because that is the endpoint for the
connection. With this approach, a Client Access server is no longer so tightly connected to a
specific Mailbox server, as it was in prior Exchange Server versions that used the
RpcClientAccessServer property. This change provides greater flexibility in deployment and
management. By switching to RPC over HTTPS connections only for the clients, the Client
Access server becomes more lightweight. It no longer must have the RPC Client Access service
installed. Benefits of this design can also be applied to site-resilience scenarios, in that
administrators no longer must handle different namespaces
when performing failover. Because the mailbox GUID and User Principal Name (UPN) is unique
through the forest, a client connection can be established without referring to a specific Client
Access server.
Note: In the case of a mixed Exchange Server environment, this connection path might not
always work the same way. For example, if you have multiple AD DS sites, where Exchange
Server 2013 is deployed in Internet-facing site while a previous version of Exchange Server
(such as 2007 or 2010) is deployed in another site, then Client Access Server 2013 will proxy the
client connection to the Client Access server in the site where the users Mailbox server resides.
In addition, using a proxy will not work for POP3 or IMAP4 messaging clients. These clients
must connect to a Client Access server in the same Active Directory site as the users Mailbox
server.
Planning Client Connectivity for Client Access Server Exchange Server 2013 supports different
types of clients, although client support has changed from the prior version. The most significant
change is that Microsoft Office Outlook 2003 is no longer supported as Exchange client
software. In addition, email clients on the Mac operating systems that require Distributed
Authoring and Versioning(DAV), such as Entourage 2008 for Mac RTM and Entourage 2004, are
not supported. In Exchange Server 2013, the following clients are supported natively:
Outlook 2013
Outlook 2010 SP1 with the April 2012 Cumulative Update
Outlook 2007 SP3 with the July 2012 Cumulative Update
Entourage 2008 for Mac, Web Services Edition
Outlook for Mac 2011
You also can connect to the Exchange Server 2013 Client Access server from email applications
that are using POP3 and IMAP4 protocols. These protocols are disabled by default, so you must

11

enable and configure them before connecting clients. However, you cannot achieve full
Exchange Server functionality with these protocols, so we recommend that you use the natively
supported clients listed above.
Clients also can connect to the Exchange Server by using the Microsoft Exchange
ActiveSync protocol. Clients that are using ActiveSync are predominantly mobile platforms,
such as Windows Phone 7 and newer clients. ActiveSync clients also use HTTPS to connect to
Client Access server, so no additional configuration is needed on the Client Access server side,
except for configuring ActiveSync policies, if needed.
Note: Mail application in Windows 8 also uses ActiveSync protocol to connect to the
Exchange Server.

Planning and Implementing High Availability in Microsoft

Exchange Server 2013
Messaging systems are considered a critical business tool in most organizations. Outages of even
a few hours reflect poorly upon the IT departments, and can result in sales losses or business
reputation damage. High availability helps ensure that messaging systems built on Microsoft
Exchange Server 2013 can survive the failure of a single server, or even multiple servers. You
can implement high availability for all the server roles in Exchange Server 2013.

What Is a Database Availability Group?

A database availability group (DAG) is a collection of servers that provides the infrastructure for
replicating and activating database copies. The DAG uses continuous replication to each of the
passive database copies within the DAG. DAGs:
Require the Windows Server 2008 R2 or Windows Server 2012 failover clustering
feature, although all installation and configuration tasks occur with the Exchange
Administration Center (EAC) or Exchange Management Shell. Even though a DAG
requires the failover clustering feature,
Exchange Server 2013 does not use Windows failover clustering to handle database failover;
instead, it uses Active Manager to control failover. Windows failover clustering is used for some
failuredetection scenarios, such as a server failure.
Use an improved version of the continuous replication technology that was introduced in
Microsoft Exchange Server 2007. The improvements support the new high-availability features,
such as database copies and database mobility.
Note: DAGs also can use third-party replication instead of continuous replication.
Allow you to add and remove Mailbox servers at any time. You do not need to decide on the
DAG membership during installation.
Because DAGs use a subset of the Windows failover clustering feature such as cluster
heartbeat, Exchange Server 2013 must be installed on Windows Server 2012 Datacenter Edition
or Standard Edition, or Windows Server 2008 R2 Enterprise Edition or Datacenter Edition.
Allow you to move a single database between servers in the DAG without affecting other
databases.

12

Allow up to 16 copies of a single database on separate servers. You can add up to 16 servers to
a DAG, which allows you to create up to 16 copies of a database. The database copies must be
stored in the same path on all servers. For example, if you store Mailbox Database 1 in
D:\Mailbox\DB\Mailbox Database 1\ on LON-MBX01, then you must also store it in
D:\Mailbox\DB\Mailbox Database 1\ on all other servers that host Mailbox Database 1 copies.
Define the boundary for replication, because only servers within the DAG can host database
copies. You cannot replicate database information to Mailbox servers outside the DAG.
Prohibit you from adding an Exchange Server 2010 to an Exchange Server 2013 DAG.
Note: In Exchange Server 2013, the basic concept of a DAG is the same as in Microsoft
Exchange Server 2010. It differs only in the way that failover times have been reduced as a result
of transaction log code improvements and a deeper checkpoint on the passive databases.
Understanding How Database Availability Groups

Work
The active database copy uses continuous replication to keep the passive copies
synchronized based on their replay lag-time setting. A DAG leverages the Windows Server
operating system failover-clustering feature. However, it relies on the Active Manager
component to maintain the status of all DAG hosted databases. The following are database
characteristics:
A single database can failover or switchover between Mailbox servers that are members of
a DAG. However, it is only active on one server at a time.
At any given time, a copy is either the replication source or the replication target, but not both.
A server may not host more than one copy of a given database.
Not all databases must have the same number of copies. In a 16-node DAG, one database can
have 16 copies, while another database is not redundant and contains only the one active copy.
Database failovers occur when failures cause the active database to go offline. Either a single
server failure or something specific to a database can cause the failure. A switchover occurs
when an administrator intentionally coordinates moving the active database from one server to
another.

11

Understanding How High Availability Works with Client

Access Servers

You configure high availability for Client Access servers by adding at least two Client
Access servers to your Active Directory site. Exchange Server 2013 Client Access servers are
now stateless. This means that a client request no longer needs to use the same Client Access
server, and can use any server. This allows you to use the following options in order to distribute
the load between the Client Access servers:
DNS round robin. To use a DNS round robin,you must configure an A record for your
client communication, and add to it all of the IP addresses of the available Client Access servers.
If you have more than one physical location where Mailbox servers are located, you should
consider implementing a Geo-DNS, so that the client servers always get the Client Access server
IP address that is located closest to it. When you consider a DNS round robin, you must consider
that the failover takes place on the client side. Therefore the client side must be aware of DNS
round robin use. This option is normally used when you cannot use Network Load Balancing
(NLB) by having a multi-role server that is part of a DAG, but you cannot afford a hardwarebased load balancer.
Network Load Balancing. Windows Server 2012 provides a feature called Network Load
Balancing (NLB) that allows you to distribute client server load to Client Access servers equally.
This is achieved by assigning a virtual IP address (VIP) in addition to the regular IP address to
every member of the NLB cluster. The NLB feature then ensures that the service is available and
will only respond when available. When a server failure occurs, the IP address will no longer
respond, and therefore the load will be distributed between the servers that are still operating
correctly. This option provides a server based fail-over because the client only will use the VIP
and will be connected to a different Client Access server automatically. This option is a good
solution if you cannot afford a hardware-based load balancer but still want to put high
availability in place.
Hardware-based load balancing. Similar to a NLB, a hardware-based load balancer uses a VIP
to which the client sends all requests. The main difference between a Windows-based NLB and
a hardware-based load balancer is that you can configure a more sophisticated hardware-based
load balancer that also can be extended beyond the Windows based NLB limit, which is 16
cluster nodes.

12

In general, the performance is much better with a Hardware-based load balancer, but this option
is associated with high costs. This is the best option to provide high-availability, but also is the
most expensive one because it requires you to purchase a hardware load balancer.
To load balance Client Access servers, you must perform the following steps:
1. Deploy multiple Client Access servers in a site.
2. Use either hardware-based or software-based Network Load Balancing (NLB) to create a
cluster.
3. Add the name for the network load-balanced cluster into DNS. For example, add a host (A)
resource record for caa1.contoso.com that points to 10.10.10.25.
Note: In Exchange Server 2010, you were required to configure a client access array in
Exchange Management Shell for each Active Directory site. In Exchange Server 2013, this
requirement is no longer needed.

11

Understanding How Transport High Availability Works

Transport high availability in Exchange Server 2013 is more than just a means of
ensuring message redundancy. Exchange Server 2013 attempts to guarantee message redundancy
by combining two features, Shadow redundancy and Safety Net (known as Transport dumpster
in Exchange Server 2010). Shadow redundancy creates a redundant copy of the message
on another server before the message is accepted or acknowledged. Safety Net stores messages
that were successfully processed by the Transport service on Mailbox servers.
Shadow Redundancy
Shadow redundancy is a feature that Exchange Server 2010 introduced that ensures a copy of a
message is available if a mailbox server crashes before messages have been committed to the
databases. Exchange Server 2013 improves this feature by automatically creating a redundant
copy of any message it receives, before it acknowledges successful receipt to the sending SMTP
server. In Exchange Server 2013, it no longer matters if a sending server supports shadow
redundancy because now a shadow copy is automatically created every time. By default, a
shadow copy of a message is removed after two days. The main goal of shadow redundancy is to
always have two copies of a message within a transport high availability boundary while the
message is in transit. This boundary is one of the following:
A DAG, for Mailbox servers that are members of a DAG. This includes a DAG that spans
multiple Active Directory sites.
An Active Directory site, for mailbox servers that do not belong to a DAG.
Where and when the redundant copy of the message is created depends on where the
message originated and where it is going. There are three major determining factors:
Messages received from outside a transport high-availability boundary.
Messages sent outside a transport high-availability boundary.
Messages received from the mailbox transport submission service from a mailbox server within
the transport high-availability boundary.
Note: Shadow redundancy never tracks shadow messages across a transport high availability
boundary.
How Shadow Redundancy Works
The following is an example of how shadow redundancy works in a DAG:
1. An SMTP server connects to the Transport service on a mailbox server where the active

12

database ofof the target recipient is mounted and transmits a message. Once the message is
received, the session stays active.
2. The transport service opens a new Simple Mail Transfer Protocol (SMTP) session to a
transport service on another mailbox server in the same DAG to create a redundant copy of the
message. If the DAG spans multiple Active Directory sites, a mailbox server in another Active
Directory site is preferred by default. The copy of the message is the shadow message, and the
mailbox server that holds it is the shadow server for the primary server. The message exists in a
shadow queue on the shadow server.
3. After the message is successfully transmitted to the shadow server, the server acknowledges
receipt of the message to the SMTP server and closes the connection.
Note: If the Mailbox server is not member of a DAG, any mailbox server in the same Active
Directory site will be used a shadow server.
When Shadow Messages are Removed
When the server successfully transmits the message to the database, the server updates the
discard status of the message when the delivery completes. The discard status is essentially a
message that contains of list of messages that are being monitored. A successfully delivered
message does not need to be kept in a shadow queue. Once the shadow server knows the primary
server has successfully transmitted the message to the next hop, the shadow server moves the
shadow message from the shadow queue into the Safety Net.

How Message Recovery Works

When a mailbox server experiences an outage due to a hardware failure, each mailbox server that
has shadow messages queued for that mailbox server will assume ownership of those messages.
When the server comes back online again, it will try to resubmit the messages. All messages are
then redelivered to their destinations. This results in duplicate delivery of the messages.
However, Exchange Server automatically detects duplicate messages and will not add them to
the database again. Only the messages that are not already in the database will be added.
Safety Net
Safety net is a special message queue available in the Transport service on every Mailbox server.
This queue stores by default up to two days of messages that were successfully delivered to a
mailbox database. Safety net protects against mailbox server failures when transaction logs have
been lost. If a failure occurs and some transaction logs are not replicated to the passive copy, you
can use safety net to redeliver messages.
Safety net is improved in Exchange Server 2013 in the following ways:
Safety net is now redundant and uses Shadow Redundancy to provide a Shadow Safety Net
queue on another server. Shadow redundancy no longer needs to keep another copy of the
message as it did in Exchange Server 2010. If the primary Safety net is unavailable for more than
12 hours, resubmit requests become shadow resubmit requests, and messages are redelivered
from the shadow safety net.
Safety net no longer requires DAGs. It essentially uses the same server that is used for shadow
redundancy to store a shadow safety net copy.

11

How Safety Net Works

Safety net works as follows when shadow redundancy is finished:
1. The transport service on the primary server processes the primary message. The Mailbox
Transport service delivers the message to the local mailbox database. The message then is moved
from the queue to the primary safety net queue.
2. The shadow server frequently polls the primary server for the discard status of the primary
message. Once the status is received, the shadow server moves the message from the shadow
queue to the shadow safety net queue.

Understanding How High Availability Works with Edge

Transport Servers

The Edge Transport server role is now available in Exchange Server 2013 SP1 . The
functionality for high availability remains the same with Exchange Server 2013 as in Exchange
Server 2007 or 2010. To make the Edge Transport server role highly available, you can install a
second Edge Transport server and configure EdgeSync. For external message delivery, no
additional configuration is required. For message reception, you must configure an additional
mail exchange (MX) record for the second Edge Transport server. If both MX records have the
same priority, then incoming messages are load balanced between the two Edge Transport
servers. To provide network redundancy for message delivery to the Internet, you can use two
Internet service providers (ISPs). Many firewalls are capable of failing over to a second Internet
connection when the primary connection fails. To receive messages on the second Internet
connection, you must create additional MX records.
If your Exchange Server organization has multiple points of contact with the Internet and
multiple locations with Edge Transport servers, this does not provide redundancy for outgoing
messages. Messages are delivered only on the lowest-cost path. If the Edge Transport servers on
the least-cost path are unavailable, the messages are queued on a Mailbox server for delivery to
the Edge Transport server. Routing paths are not recalculated based on availability.
What Is Site Resilience?
Site resilience is the ability of the messaging system to survive a site failure, and to continue

12

functioning through the use of an alternate data center. In some cases, the alternate data center
is a site that is dedicated only to disaster recovery.
In other cases, the alternate data center might be another company site that is in use, but has
sufficient capacity to handle services for the failed location.
A DAG is capable of existing across multiple subnets. This means that a DAG can exist across
multiple Active Directory sites. This is a major improvement from previous versions of
Exchange Server 2010, which required you to extend a subnet across a WAN link.
Site resilience exists only for Mailbox servers. Any other required server roles must already exist
in the site or they will not fail over. For example, Client Access servers should already exist in
the alternate data center. Other services, such as DNS, domain controllers, and global catalog
servers, also must be available in the alternate data center.
Configuring Highly Available Mailbox Databases
Historically, the Mailbox server role has been the most complex and critical component in a
highly available Exchange Server deployment. Although this remains true to some extent, in
Exchange Server 2013 the complexity of deploying a highly available mailbox server is reduced.
The DAG configuration also reduces the likelihood that administrators will configure a mailbox
server cluster improperly.
What Is a Quorum?
The quorum maintains the logic so that a cluster knows which node is active, and which nodes
are passive. In addition, the quorum decides which passive node will be activated if the active
node fails. The failover-cluster quorum configuration, as used by the Exchange Server 2013
DAG, determines the number of failed nodes, or failed storage and network components that the
cluster can sustain while it continues to function. A quorum prevents two sets of nodes
from operating simultaneously as the failover cluster.
Simultaneous operation could occur when network problems prevent one set of nodes from
communicating with another set of nodes. Without a quorum mechanism, each set of nodes could
continue to operate as a failover cluster, causing a partition within the cluster.
To prevent problems caused by a split in the cluster, failover clusters use a voting algorithm to
determine whether the cluster has enough votes to maintain a quorum. Because a given cluster
has a specific set of nodes and a specific quorum configuration, the cluster determines how many
votes are required. If the number of votes drops below the majority, the cluster cannot start.
Nodes will continue to listen for the presence of other nodes, in case another node appears again
on the network. However, the nodes will not function as a cluster until a consensus is reached.
For example, if there are five votes in the cluster, the cluster continues to function as long as
there are at least three available votes. The source of the votes in Exchange Server 2013 can be a
node or a witness file share. When a majority of the votes is not available, or when only half of
the votes are available, the cluster will not start. In addition, when the majority drops below half
of the available votes, Exchange Server 2013 will dismount the databases.
Note: Exchange Server 2013 also supports placing the witness server in another site.

11

Windows Server 2012 Quorum Configurations

Windows Server 2012 provides the four quorum configurations: node majority, node and file
share majority, node and disk majority, and no majority: disk only. However, Exchange Server
2013 only supports node and file share majority. In the node and file share majority
configuration, each cluster node plus a designated file share (also referred to as a witness server
in Exchange Server 2013) can vote.
The cluster only functions with a majority of the votes, meaning that more than half of the votes
are available. If an active cluster loses communication with more than half of its votes, it will
stop functioning.
Configuring Non-Voting Cluster Nodes
In Windows Server 2012, you can configure nodes that do not have a vote in the cluster to
maintain a quorum. You can configure Failover Cluster Manager using the Configure Cluster
Quorum Wizard.
Exchange Server 2013 supports this configuration; however, you should carefully consider
whether you should use it.
For example, consider the site-resiliency scenario that provides additional local failures if the
quorum is lost. In this scenario, there are five DAG members, three in the primary site, and two
in the failover site. If needed, you can remove the votes of the two members in the failover site.
This is possible because if the secondary site fails, you still have one additional failure in your
local site before the cluster will shut down if the quorum is lost.

Planning Software and Hardware Components for Database

Availability Groups
When you implement a DAG, you must ensure that you meet several very specific
requirements. You need to consider the requirements related to general configuration, operating
system version, network configuration, and DAG configuration.
General Configuration
The general requirements for implementing a DAG are:
DNS must be implemented with a host record for each Exchange server. Dynamic updates
for DNS are preferred.
Each Mailbox server must be a member of the same domain. It is not possible to have Mailbox
servers in different Active Directory domains as members of the same DAG.
The Mailbox servers that are members of a DAG cannot also be domain controllers. This
configuration is not supported.
The computer name for the Mailbox server must be unique, and must be 15 characters or fewer.
All members of a DAG must run the same operating system version. All DAG members must be
running either Windows Server 2008 R2 or Windows Server 2012. You cannot combine the two
operating system versions within the same DAG. The join to the DAG will fail if you try to join
two different versions of the operating system.
A DAG is based on the use of failover clustering in Windows Server. Only the Enterprise or

12

Datacenter versions of Microsoft Windows Server 2008 R2 or the Standard and Datacenter
versions of Windows Server 2012 include failover clustering. Therefore, you can use only these
operating system versions for DAG members.
Network Configuration
The network configuration requirements include the following:
One network adapter is supported; however, we recommend two network adapters. This allows
you to configure a messaging application programming interface (MAPI) network and a
separate replication network.
Latency between DAG members must be less than 500 milliseconds. This is important when
you configure a DAG with members in multiple physical locations.
You can use Internet Protocol version 6 (IPv6) only if Internet Protocol version 4 (IPv4) also is
configured. You cannot disable IPv4.
Automatic Private Internet Protocol Addressing (APIPA) is not supported for DAG members.
DAG Configuration
In addition to the physical network and IP addressing requirements for the DAG member servers,
the DAG itself has the following requirements:
The DAG must have at least one IP address on the MAPI network. This address can be static or
dynamic, although a static IP address is used in most environments.
If the DAG is expanded across multiple subnets, then the DAG must have an IP address on
each subnet.
The name of the DAG and the name of each DAG member must be 15 characters or less, and
must be unique.
Witness Server
Failover clustering in Windows Server 2012 uses the concept of a quorum for decision making in
the cluster. In clusters with a shared disk, connectivity to the shared disk can be used to define
which nodes potentially should be active in the cluster. In a DAG, there is no central disk.
A DAG requires the use of a witness server for a node and a file-share majority quorum. The
witness server functions as an additional DAG member for determining the quorum; however, it
is only used when there is an even number of members in the DAG. The witness server is a file
share located on a server that is not a DAG member.
The quorum for a DAG determines which members participate in replications, and which can
mount databases. For example, if one computer in a DAG loses network communication, that
computer is not part of the quorum and cannot mount databases.
We recommend that you configure the witness server on a Client Access server in the Exchange
Server organization. The additional load on the server is minimal, and it is already under the
control of the Exchange Server management group. The witness server does not need to run the
same version of Windows Server as the members of the DAG.
If the DAG witness server is not an Exchange server, then you need to add the Exchange
Trusted Subsystem group as a member of the local Administrators group on the witness server.

11

What Is Active Manager?

To manage mailbox database replication and activation, Exchange Server 2013 includes a
component called Active Manager, which runs as a function of the Microsoft Exchange
Replication service (MSExchangeRepl.exe). Active Manager replaces the resource model and
failover management features integrated into Windows failover clustering that Microsoft
Exchange Server 2003 and Exchange Server 2007 used. To simplify the architecture, Active
Manager runs on all Mailbox servers, even if the server is not part of a DAG.
Active Manager runs on all of the DAG members either as the Primary Active Manager or a
Standby Active Manager. The Primary Active Manager is the Active Manager in a DAG that
controls which copies will be active and which will be passive. It is responsible for processing
topology change notifications, and for reacting to server failures. The DAG member that acts as
the Primary Active Manager is always the member that currently owns the default cluster group.
To identify the Primary Active Manager, we recommend that you use the GetDatabaseAvailabilityGroup <DAG Name> -Status | Format-List
Name, PrimaryActiveManager cmdlet, rather than using the Windows Failover Clustering tools.
If the server that owns the default cluster group fails, the PAM function automatically moves to
the server that takes ownership of the default cluster group.
Th Standby Active Manager function has an active, not passive role. It provides information
about which server hosts the active copy of a mailbox database. The Standby Active Manager
detects local database and Microsoft Exchange Information Store failures, and reacts to them by
requesting that the Primary Active Manager initiate a failover when a copy is available. A
Standby Active Manager does not determine a failover target; nor does it update a databases
location state for the Primary Active Manager. Each Standby Active Manager accesses the state
of the active database copy so that it can redirect Client Access server requests. The Primary
Active Manager also performs the functions of the Standby Active Manager role on the local
system.

What Is Continuous Replication?

Continuous replication was introduced for Mailbox servers in Exchange Server 2007,
and Exchange Server 2010 continued to use continuous replication. Since the release
of Exchange Server 2010 Service Pack 1 (SP1), there are two more available options for

12

continuous
replication: file mode and continuous replicationblock mode.
Continuous Replication File Mode
Continuous replication creates a passive database copy on another Exchange Server computer in
the DAG, and then uses asynchronous log shipping to maintain the copies. The continuous
replication file mode process includes the following steps:
1. The Mailbox server role with the active database writes the active log, and then closes it.
2. The Replication Service replicates the closed log to the servers that host the passive databases.
3. Because each copy of the database is identical, the transaction logs are inspected and then
replayed or applied to the database copies. The databases remain synchronized.
In Exchange Server 2013 seeding, you are no longer required to use the active copy as the source
for the seed. In addition, in Exchange Server 2013, you can perform seeding from passive
databases. If a healthy copy of the database is available on any server, the Exchange Server can
replay the transaction logs against a common, valid data set. You can seed the data in the
following ways:
Automatically.
Manually, from the active or passive copies using the Update-MailboxDatabaseCopy cmdlet.
Manually, by copying the database files.
Continuous replication occurs over TCP sockets. Continuous replication occurs as follows:
1. The target, or passive node notifies the active instance which transaction logs it expects.
2. The source responds with the required transaction log files.
3. After Exchange Server 2013 copies the log files, it places them in the target inspector directory
for processing.
4. Log inspection verifies that the data is physically sound, and inspects the header. If the log
passes inspection, Exchange Server 2013 places the log in the target log directory. If the log does
not passpass inspection, Exchange Server 2013 requests it from the source up to three times
before failing.
5. After Exchange Server 2013 saves the transaction log to the target log directory, the
information store validates the logs to ensure that they are valid, that none are missing, and that
the database requires hem.
Continuous Replication Block Mode
Continuous replication block mode was introduced in Exchange Server 2010 SP1. Block mode
reduces the exposure of data loss on failover by replicating the Extensible Storage Engine (ESE)
log buffer, which writes to the passive database copies in parallel to writing them locally. Block
mode automatically becomes active when continuous replication file mode is up to date with the
database copies. The continuous replication block mode process is as follows:
1. Once in block mode, any block of data written to the ESE log buffer on the Exchange Server
that hosts the active database is copied automatically to the replication log buffer, and then to all
of theservers that host passive copies of the active database.
2. When the ESE log buffer is full, the final block is sent to the passive databases, and a
transactional log file is written to the Exchange Server that hosts the active database. Then the

11

ESE log buffer is emptied.

3. When the Exchange Servers hosting the passive databases receive the final block that fills up
their replication log buffer, they also save the buffer to a transaction log file with the same log
generation sequence number. After that, the buffer is emptied and the process starts again.
4. When the Exchange server with the active database fails, but the replication log buffer is not
yet full, the buffer on the server hosting the passive copy of the database is saved to a new
transactional log file. Replication transport is identical when file mode is enabled or disabled.
The benefit of block mode is that it can reduce the differences between the active copy and the
passive copy, while also reducing both the possibility of data loss during a failover and the time
it takes to perform a switchover.