Module 1: Deploying and Managing Microsoft Exchange Server 2013

Deploying and Managing Microsoft Exchange Server 2013

Exchange Server 2013 is the current  version of Microsoft’s 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.

Figure 1: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.
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 mail-
enabled have preconfigured attributes, such as email addresses.

Global Catalog

When you install Exchange Server 2013, the email attributes for mail-enabled and mailbox-
enabled 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 forest’s 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.

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 organization’s email.
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.

Figure 2: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.
 Figure 3

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
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 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-Schema-Version-Pt is set to 15132.
  In the Configuration naming context, verify that the objectVersion property in the
CN=<yourorganization>,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.

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.
 Figure 4

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.
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 load-balancing 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 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
user’s 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.

Figure 5
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 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.

Figure 6

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 on-premises 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 by installing Exchange Server 2013 over a previous
version. This procedure, which is known as an in place 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.

Figure 7

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