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.
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.
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.
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 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-Schema-Version-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.
******
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.
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.
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.
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 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.
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