On-premises implementations of Exchange Server have three layers in their architecture: a network layer, directory layer, and messaging layer. The messaging layer is where you define and deploy the Exchange Server roles. The Exchange servers at the core of the messaging layer can operate in the following roles:

At the time of this writing, Exchange 2013 supports the Mailbox Server and Client Access Server roles. If you want to use Edge Transports, you must deploy these transports on servers running either Exchange 2007 or Exchange 2010. Two other server roles available for Exchange 2010, Unified Messaging and Hub Transport, are now implemented as services running on Exchange 2013 Mailbox servers:

The Mailbox and Client Access roles are the building blocks of on-premises Exchange organizations. Table 2-1 provides an overview of the basic processor configurations I recommend for these roles. Processors can have multiple cores. Following the configurations shown in the table, I recommend that you build Client Access servers for scaling out and Mailbox servers for scaling up. If you deploy legacy Edge Transport servers, they should be built for scaling out as well.

Because you can combine the Mailbox and Client Access roles on a single server, one of the most basic Exchange organizations you can create is one that includes a single Exchange server that provides the Mailbox Server and Client Access Server roles. These roles are the minimum required for routing and delivering messages to both local and remote messaging clients. For added security and protection, you can deploy the legacy Edge Transport server role in a perimeter network on one or more separate servers. As part of site planning, keep in mind every Active Directory site that has a Mailbox server must also have a Client Access server.

Although a basic implementation of Exchange Server might include only one server, you’ll likely find investing in multiple servers is more effective in terms of time, money, and resources. Why? High availability is integrated into the core architecture of Exchange Server 2013 and can be easily enabled.

With the Mailbox Server role, you can configure automatic failover by making the Mailbox servers members of the same database availability group. Each Mailbox server in the group can then have a copy of the mailbox databases from the other Mailbox servers in the group. Each mailbox database can have up to 16 copies, and this means you can have up to 16 Mailbox servers in a database availability group as well.

Client Access servers in Exchange 2013 are lightweight, stateless proxy servers. They provide the proxy and redirection logic for client protocols. For load balancing and failover redundancy, you previously needed to configure Client Access arrays and there typically was a specific affinity between the client and the Client Access server. Because of the client-server affinity, Microsoft recommended using application layer–based load balancing solutions, which ensured that requests from a connected client went through the same Client Access server endpoint.

With Exchange 2013, no configuration of Client Access arrays is needed. Client Access servers that are in the same Active Directory site are automatically added to an array for that site. Further, no specific affinity is required between the client and the Client Access server. This allows any available Client Access server to proxy a client’s request. If a server proxying a connection fails, the client connection is simply proxied by the next available Client Access server. This is possible because proxy and redirection logic for client protocols is built in.

Client Access servers running on Exchange 2013 also support layer 4 load balancing which distributes requests at the transport layer. In this case, the client connects to Exchange using a single virtual IP address, and a load balancer selects a server to receive the request. Because there is no affinity required, the load balancer doesn’t have to ensure that all requests from a client go to the same server. Not only does this simplify the load balancer’s job and greatly reduce the processing overhead, it allows administrators to add or remove servers at any time. It also means very basic load balancing techniques, such as round robin and least connection, can be used. Although load balancing round robin can be configured in DNS, you also can configure this and other load balancing options using Windows Network Load Balancing. However, because servers in database availability groups are already using clustering technology, they can’t also use Windows Network Load Balancing. Thus, when you deploy Mailbox servers in availability groups and want to use Windows Network Load Balancing to load balance client access, the Mailbox Server and Client Access Server roles must be running on separate servers.

For site resilience, you can deploy two Active Directory sites in separate geographic locations and then synchronize data between the two sites. With Exchange 2010, you had to perform a switchover from one site to the other if you lost all of your Client Access servers, the virtual IP for the array, or multiple servers in a database availability group. This is not required for Exchange 2013. If you lose a Client Access server array in one site, failover to the other site can happen at the client level automatically. Clients can be automatically redirected to a second site that has operating Client Access servers, and those servers act as proxies to the user’s Mailbox server in the original site.

The underlying functionality of a Mailbox server is similar to that of a database server. Every mailbox-enabled recipient defined in the organization has a mailbox that is used to store messaging data. Groups of related mailboxes are organized using databases, and each database can have one or more database copies associated with it.

With Exchange Server 2007, you needed dedicated hardware for clustered Mailbox servers, those servers could not run other roles, and failover occurred at the server level. Microsoft re-engineered Exchange 2010 and Exchange 2013 to provide continuous availability while eliminating these restrictions. For Exchange 2013 specifically, this means:

The underlying technology built into database availability groups is the key ingredient that makes high availability possible. The related framework ensures failover clustering occurs in the background and doesn’t normally require administrator intervention. As a result, Exchange Server 2013 doesn’t need or use a cluster resource dynamic-link library (DLL) and uses only a small portion of the Windows clustering components, including heartbeat capabilities and the cluster database.

Database availability groups use continuous replication to achieve high availability. With continuous replication, Exchange Server 2013 uses its built-in asynchronous replication technology to create copies of mailbox databases and then keeps the copies up to date using transaction log shipping and replay. Lagged copies can automatically play down log files to automatically recovery from certain types of issues. For example, if Exchange detects that a low disk space threshold has been reached, Exchange automatically replays the logs into the lagged copy to play down the log files. If Exchange detects that page patching is required, Exchange automatically replays the logs into the lagged copy to perform page patching. If Exchange detects that there are fewer than three available healthy copies (whether active or passive) for more than 24 hours, Exchange automatically replays the logs into the lagged copy to play down the log files.

Any server in a group can host a copy of a mailbox database from any other server in the group. When a server is added to a group, it works with other servers in the group to provide automatic recovery from failures that affect mailbox databases, including server failure, database corruption, disk failure, and network connectivity failure. Although Exchange 2010 used a scheduled script to alert you that only a single copy of a database was available, this functionality is now integrated into Exchange along with other managed availability features for internal monitoring and recovery.

When you create a database availability group, Exchange adds an object to Active Directory representing the group. This object stores information about the group, including details about servers that are members of the group. When you add the first server to the group, a failover cluster is created automatically and the heartbeat is initiated. As you add member servers to the group, the heartbeat components and the cluster database are used to track and manage information about the group and its member servers, including server status, database mount status, replication status, and mount location.

Because Exchange Server 2013 databases are represented at the organization level, they are effectively disconnected from the servers on which they are stored, which makes it easier to move databases from one server to another. However, it also means you can work with databases in many different ways and that there are also several requirements when working with databases. Keep the following in mind when working with databases in Exchange Server 2013:

For a successful deployment of a Mailbox server, the storage subsystem must meet the storage capacity requirements and must be able to perform the expected number of input/output (I/O) operations per second. Storage capacity requirements are determined by the number of mailboxes hosted on a server and the total storage size allowed per mailbox. For example, if a server hosts 2,500 mailboxes that you allow to store up to 2 gigabytes (GB) each, you need to ensure there are at least 5 terabytes of storage capacity above and beyond the storage needs of the operating system and Exchange itself.

I/O performance of the storage subsystem is measured in relation to the latency (delay) for each read/write operation to be performed. The more mailboxes you store on a specific drive or drive array, the more read/write operations there are performed and the greater the potential delay. To improve performance, you can use multiple mailbox databases on separate disks. You might also want to store databases with their transaction log files on separate disk drives, such that database A and related logs are on disk 1, database B and related logs are on disk 2, and so on. In some scenarios, you might want the databases and logs to be on separate disks.

I/O performance in Exchange Server 2013 running on 64-bit architecture is improved substantially over 32-bit architecture. On Mailbox servers, a 64-bit architecture enables a database cache size of up to approximately 90 percent of total random access memory (RAM). A larger cache increases the probability that data requested by a client will be serviced out of memory instead of by the storage subsystem.

Unlike Exchange 2010 which required separate volumes for each database copy whether passive or active, Exchange 2013 allows a server to host multiple databases on the same volume. This allows you to have a mix of active and passive copies on the same volume. As part of your planning, look closely at the input/output per second (IOPS) capabilities of your storage architecture and place database copies appropriately. Because active copies will use more IOPS than passive copies, you’ll typically want no more than one active database copy on a volume while allowing multiple passive copies. For example, if you’re configuring a four-server database availability group, you might want to configure storage so that each server has a large volume with its active database copy and passive copies of the databases on the other servers.

Like Exchange 2010, Exchange 2013 is optimized so that servers can use large disks with 2 to 8 terabytes of storage efficiently. However, as part of your planning, you need to understand how Exchange 2013 uses automatic reseed to recover from disk failure, database corruption events, and other issues that require a reseed of a database copy. With automatic reseed, Exchange can automatically restore database redundancy using spare disks that have been pre-provisioned.

The larger the database, the longer it takes Exchange to reseed it. If a database is too large, it can’t be reseeded in a reasonable amount of time. With a typical reseed rate of 20 MB per second, it would take Exchange:

Because of this, the total reseed time may be the most important limiting factor for sizing databases.

With Exchange 2010, the underlying functionality of a Client Access server was similar to that of an application server that made extensive use of Web services. These servers needed to be built to handle increased I/O operations, which meant processors, memory, network, and disk I/O were all potential sources of bottlenecks. Because they also performed content conversion, you could improve performance by optimizing disk storage.

As part of the major architecture changes for Exchange 2013, Client Access servers no longer handle all of the client-related messaging tasks in an Exchange implementation, nor do they perform content conversion. Instead, all processing and content conversion is performed on Mailbox servers, and Client Access servers are used only for authentication, proxy services, and limited redirection.

Client Access servers provide access through the Outlook MAPI, Internet Message Access Protocol version 4 revision 1 (IMAP4), Post Office Protocol version 3 (POP3), and Hypertext Transfer Protocol (HTTP) Internet protocols. By default, when you install a Client Access server, these services are available to both internal and external clients. You can modify the default configuration at any time and specify whether the Client Access server will be accessible to clients outside the organization. You also can configure the external URLs for each Client Access Server-related service.

Exchange Server 2013 allows access using Microsoft Outlook with Simple Mail Transfer Protocol (SMTP), Outlook Anywhere (RPC over HTTP), Outlook Web App, and Exchange ActiveSync. Internet Message Access Protocol 4 (IMAP4) and Post Office Protocol 3 (POP3) are available as alternatives to standard protocols. IMAP4 is a protocol for reading mail and accessing public and private folders on remote servers. POP3 is a protocol for retrieving mail from remote servers. Client Access servers provide access to free/busy data by using the Availability service, and they enable clients to download automatic configuration settings from the Autodiscover service.

Exchange 2013 uses the Active Directory infrastructure to determine its site membership and the site membership of other servers. The Microsoft Exchange Active Directory Topology service running on an Exchange server is responsible for updating the site attribute of an Exchange server in the directory.

Once a server determines its site membership, the server identifies which domain controllers and global catalogs to use for processing Active Directory queries. Because this information is available in the directory, Exchange servers don’t need to use DNS to resolve a server address to a subnet associated with an Active Directory site.

Exchange 2013 Mailbox servers interact directly with Outlook clients, Client Access servers, and Active Directory. Mailbox servers use Lightweight Directory Access Protocol (LDAP) to obtain recipient, server, and organization configuration information from Active Directory. Client Access servers accept connections to Mailbox servers over the local network and over the Internet. Client Access servers send requests from clients to the appropriate Mailbox server and return data from Mailbox servers to clients, including online address book files, free/busy data, calendar schedules, and client profile settings.

Some clients use POP3 or IMAP4 connections to communicate with the Exchange server. Other clients use SMTP, POP3, or IMAP4 to communicate with the Exchange server. Client Access servers proxy POP3, IMAP4, and SMTP communications between clients and Mailbox servers using POP3, IMAP4, and SMTP redirection respectively.

Outlook Web App, Exchange Active Sync, Exchange Admin Center, and PowerShell communications are handled in much the same way as communications for standard Outlook clients.

Outlook clients on the corporate network access the Client Access server to send and retrieve messages using either SMTP or Outlook Anywhere (RPC over HTTP), as do clients outside the corporate network. Regardless of whether they are on or outside the corporate network, Outlook clients access public folder data using Outlook Anywhere. To retrieve a user’s Active Directory information, Client Access servers use LDAP or Name Service Provider Interface (NSPI). By default, communications between Client Access servers and Mailbox servers is encrypted, as are communications with domain controllers and global catalogs.

Each Active Directory site with Mailbox servers should have at least one Client Access server. When there are multiple Client Access servers in a site, these servers are automatically configured in an array. Client Access arrays provide load balancing and failover support for all client access features. Each array has an external domain name, and client requests are directed to this external domain name, allowing for transparent load balancing as well as failover and failback. When a load-balanced resource fails on one server, the remaining servers in the array take over the workload of the failed server. When the failed server comes back online, the server can automatically rejoin the array, and the load-balancing feature starts to distribute the load to the server automatically. Failover takes only a few seconds in most cases.

The external URLs for CAS-related services should point to the array rather than to individual servers, and the internal URLs should point to individual servers. Because of this, you should set the external URLs for Exchange ActiveSync, Outlook Web applications, Exchange Admin Center, and the Offline Address Book relative to the external domain name for the array. For example, Exchange ActiveSync runs as a web application named Microsoft-Server-ActiveSync. When setting up Exchange ActiveSync URLs on each individual Mailbox server, you should configure the internal URL to point to a specific CAS server, such as https://casserver48.pocket-consultant.com/Microsoft-Server-ActiveSync, and the external URL to point to a location relative to the array, such as https://array1.pocket-consultant.com/Microsoft-Server-ActiveSync.

In Exchange 2010, Exchange Management Shell had several cmdlets you used to register and manage arrays in Active Directory. Because arrays are now created automatically, Exchange 2013 has only the Get-ClientAccessArray cmdlet for working with arrays. This cmdlet lists information about available or specified Client Access arrays. Its basic syntax is as follows:

Get-ClientAccessArray [-Identity ArrayIdentity]
[-DomainController FullyQualifiedName] [-Site SiteId]

Load balancing can be implemented using hardware or software. Windows Server includes the Windows Network Load Balancing service. Network Load Balancing doesn’t use shared resources or clustered storage devices. Instead, each server has a copy of the Client Access services and features that are being load balanced, and local storage typically is used. Generally, users usually don’t know that they’re accessing a group of servers rather than a single server. The reason for this is that the array appears to be a single server. Clients connect to the array using the array’s external domain name, and this virtual address is mapped automatically to a specific server based on availability. It is important to note that you cannot use Windows Network Load Balancing for establishing a Client Access array if the Client Access servers are co-located on a Mailbox server in a database availability group.

The Transport service on Mailbox servers and the Edge Transport role perform similar tasks. You use both for messaging routing, and both have a similar set of filters to protect an organization from spam and viruses. The key difference is in where you place servers with these roles. You place a Mailbox server in the internal network and configure it as a member of the organizational domain. If you use a server with the legacy Edge Transport role, you place it in the organization’s perimeter network, and you do not configure it as a member of the organizational domain.

For computers with the Mailbox server or legacy Edge Transport role, the server cannot have the SMTP or Network News Transfer Protocol (NNTP) service installed separately. Although you install legacy Edge Transport servers outside the Active Directory forest, you must have a DNS suffix configured, and you must be able to perform name resolution from the legacy Edge Transport server to any Mailbox servers.

Both Mailbox servers and legacy Edge Transport servers can perform protocol logging and message tracking. Only Mailbox servers perform content conversion to format messages for recipients. Protocol logging allows you to verify whether a protocol is performing as expected and whether any issues need attention. Because this feature is designed for troubleshooting, it is disabled by default. Message tracking creates logs that track messages sent and received. Incoming mail from the Internet is converted to Summary Transport Neutral Encoding Format (STNEF) prior to being delivered. STNEF messages are always MIME-encoded and always have a Content-Transfer-Encoding value of Binary. Because content conversion is performed in the temp folder, you can improve performance by ensuring that the temp folder is not on the same physical disk as the paging file and operating system.

The transport pipeline used by Exchange 2013 is different from the transport pipeline for Exchange 2010 and has the following key components:

The Front End Transport service running on Client Access servers proxies all inbound and outbound SMTP traffic for Exchange 2013. Although the Transport service running on Mailbox servers performs nearly the same tasks as the Hub Transport role, it’s important to point out the differences. As with Exchange 2010, the Transport service handles all SMTP mail flow. The service also performs message categorization and message content inspection. Unlike Exchange 2010, however, the Transport service doesn’t communicate directly with mailbox databases. Instead, the Mailbox Transport Submission and Mailbox Transport Delivery services are used to provide separate mail submission and delivery processes.

The basic submission process works like this:

The basic delivery process works like this:

Messages from inside the organization enter the transport pipeline through a Receive connector, from the Mailbox Transport Delivery service, from the Pickup or Replay directories, or from agent submission. Messages from outside the organization enter the transport pipeline through a Receive connector in the Front End Transport service on a Client Access server and are then routed to the Transport service on a Mailbox server.

Unified messaging allows you to integrate voice mail, fax, and email functionality so that the related data can be stored in a user’s Exchange mailbox. To implement unified messaging, your organization must have a PBX that is connected to the LAN, and you must deploy Mailbox servers running Exchange Server 2013. After it is deployed, the Unified Messaging service running on a Mailbox server has the job of providing call answering, fax receiving, subscriber access, and auto-attendant features that allow access to content over the telephone and storage of content received from the PBX. However, it is the job of the Unified Messaging Call Router service running on Client Access servers to provide call routing and proxy services that allow calls to be connected.

Although some current PBXs, referred to as IP-PBXs, are Internet Protocol–capable, all other PBXs require a separate Internet Protocol/Voice over Internet Protocol (IP/VoIP) gateway to connect to the LAN. After you connect a PBX to the LAN, you can link it to Exchange by deploying and appropriately configuring the Unified Messaging service. The Desktop Experience feature, which is required to install Exchange server, provides the Microsoft Speech service, Microsoft Windows Media Encoder, and Microsoft Windows Media Audio Voice Code components used by the Unified Messaging service.

The Unified Messaging service doesn’t perform a great deal of I/O operations, and the primary potential bottlenecks for this service are the processors, memory, and network. Disk I/O operations for this service are primarily limited to accessing routing details and dial plans, which include auto-attendant and mail policy settings.

If you are planning to use Unified Messaging in a hybrid Exchange implementation, you’ll also need to configure session board controllers (SBCs). SBCs have two IP interfaces: one for your network and another that connects over the Internet. Your VoIP, IP-PBX, and SBC components must be configured to communicate with your Mailbox and Client Access servers. You also must create and configure a Unified Messaging IP gateway to represent each deployed device.

Mailbox servers are service locations for email messages, voice-mail messages, and faxes. For outgoing mail, Mailbox servers can access Active Directory to retrieve information about the location of Mailbox servers in their site. Then they can use this information to forward messages for routing.

The Transport service running on Mailbox servers contacts Active Directory for message categorization. The Categorizer queries Active Directory to perform recipient lookup, retrieves the information needed to locate a recipient’s mailbox (according to the mailbox store in which it is created), and determines any restrictions or permissions that might apply to the recipient. The Categorizer also queries Active Directory to expand the membership of distribution lists and to perform the LDAP query processing when mail is sent to a dynamic distribution list.

After the Categorizer determines the location of a mailbox, the Transport service uses Active Directory site configuration information to determine the routing topology and locate the site of the mailbox. If the mailbox is in the same Active Directory site as the Mailbox server, the Transport service delivers the message directly to the user’s mailbox. If the mailbox is in a different Active Directory site than the Mailbox server, the Transport service delivers the message to a Mailbox server in the remote Active Directory site.

Mailbox servers store all configuration information in Active Directory. This configuration information includes the details of any transport or journaling rules and connectors. When this information is needed, a Mailbox server accesses it in Active Directory.

Mailbox servers also store configuration information about mailbox users, mailbox stores, agents, address lists, and policies in Active Directory. Mailbox servers retrieve this information to enforce recipient policies, mailbox policies, system policies, and global settings.

Client Access servers receive connections from local and remote clients. At a high level, when a user connection is received, the Client Access server contacts Active Directory to authenticate the user and to determine the location of the user’s mailbox. If the user’s mailbox is in the same Active Directory site as the Client Access server, the user is connected to the mailbox. If the user’s mailbox is in an Active Directory site other than the one the Client Access server is located in, the connection is redirected to a Client Access server in the same Active Directory site as the user’s mailbox.

When you use load balancing on your Client Access servers, Exchange 2013 creates arrays in Active Directory and associates each array with a specific Active Directory site. Each CAS array can be associated with only one Active Directory site. As with stand-alone CAS servers, the site information determines how connections are directed. If the user’s mailbox is in the same Active Directory site as the array, the user is connected to a CAS server and via the CAS server to the mailbox. If the user’s mailbox is in an Active Directory site other than the one in which the Client Access array is located, the connection is redirected.

You must have one Client Access server in each Active Directory site that contains a Mailbox server. At least one of your Client Access servers must be designated as Internet-facing. The Internet-facing CAS server proxies requests from Outlook Web App, Exchange ActiveSync, and Exchange Web Services to the Client Access server closest to the user’s mailbox.

With Exchange 2010, proxying was not used for POP3 or IMAP4, and you needed to manually configure cross-site connectivity so clients connecting on one site could access their mailboxes at another site. Exchange 2013 automatically proxies from a Client Access server in one site to the correct server in another site.

The Unified Messaging service accesses Active Directory to retrieve global configuration information, such as dial plans and IP gateway details. When a message is received by the Unified Messaging service, the service searches for Active Directory recipients to match the telephone number to a recipient address. When the service has resolved this information, it can determine the location of the recipient’s mailbox and then submit the message to the appropriate Mailbox server for submission to the mailbox.

You deploy legacy Edge Transport servers in perimeter networks to isolate them from the internal network. As such, they are not members of the internal domain and do not have direct access to the organization’s internal Active Directory servers for the purposes of recipient lookup or categorization. Thus, unlike the Transport service on Mailbox servers, legacy Edge Transport servers cannot contact an Active Directory server to help route messages.

To route messages into the organization, an administrator can configure a subscription from the legacy Edge Transport server to the Active Directory site that allows it to store recipient and configuration information about the Exchange organization in its AD LDS data store. After a legacy Edge Transport server is subscribed to an Active Directory site, it is associated with the Mailbox servers in that site for the purpose of message routing. Thereafter, Mailbox servers in the organization route messages being delivered to the Internet to the site associated with the legacy Edge Transport server, and Mailbox servers in this site relay the messages to the legacy Edge Transport server. The legacy Edge Transport server, in turn, routes the messages to the Internet.

The EdgeSync service running on Mailbox servers is a one-way synchronization process that pushes information from Active Directory to the legacy Edge Transport server. Periodically, the EdgeSync service synchronizes the data to keep the Edge Transport server’s data store up to date. The EdgeSync service also establishes the connectors needed to send and receive information that is being moved between the organization and the Edge Transport server and between the Edge Transport server and the Internet. The key data pushed to the Edge Transport server includes:

After the initial replication is performed, the EdgeSync service synchronizes the data periodically. Configuration information is synced once every hour, and it can take up to one hour for configuration changes to be replicated. Recipient information is synced once every four hours, and it can take up to four hours for changes to be replicated. If necessary, administrators can initiate an immediate synchronization using the Start-EdgeSynchronization cmdlet in Exchange Management Shell.

For coexistence with legacy Exchange Server versions, Exchange Server 2013 Cumulative Update 1 (CU1) is the minimum version. Exchange Server 2013 (Release to Manufacturer) RTM doesn’t support legacy Exchange organizations. Keep the following in mind:

Before you install any build of Exchange Server 2013 in a legacy Exchange Server organization, ensure that Exchange Server 2010 is fully deployed. The reason for this is that you can install additional Exchange Server 2010 servers running a particular server role only if you’ve deployed a server with one of these roles prior to installing Exchange Server 2013. Therefore, if you haven’t previously deployed all four Exchange Server 2010 server roles in your legacy Exchange Server organization, you may want to do so prior to installing any build of Exchange Server 2013.

Exchange Server 2013 contains extensive Active Directory schema changes and other Active Directory updates, so you might want to prepare Active Directory and the domain for these changes prior to installing Exchange Server 2013 for the first time, especially in a large enterprise.

To do this, follow these steps:

Although Exchange Server 2013 Setup can perform these processes for you during the upgrade, the changes can take some time to replicate throughout a large organization. By performing these tasks manually, you can streamline the upgrade process. You also can ensure the tasks are run with accounts that have appropriate permissions.

As a prerequisite for installing Exchange Server 2013, Active Directory must be at Windows Server 2003 forest functionality mode or higher. Additionally, the schema master for the Active Directory forest along with at least one global catalog server and at least one domain controller in each Active Directory site must be running one of the following operating systems:

When you deploy IPv6, Exchange 2013 servers can send data to and receive data from devices, servers, and clients that use IPv6 addresses. However, Exchange 2013 supports IPv6 only when IPv4 is also installed. Further, although you can disable IPv4 so that only IPv6 is enabled, Exchange still requires that IPv4 be installed.

When managing Exchange servers, you should use the administrative tools for that Exchange Server version. Exchange Admin Center and Exchange Management Shell are the primary management tools for Exchange Server 2013. Mailboxes located on Exchange Server 2007 and Exchange Server 2010 servers are also displayed in Exchange Admin Center.

You can manage the Exchange 2007 or 2010 mailbox properties using Exchange Admin Center or Exchange Management Shell. You can use either tool to move mailbox recipients from Exchange 2007 or Exchange 2010 to Exchange 2013.

When deploying Exchange 2013 in an Exchange 2007 or Exchange 2010 organization, keep the following in mind:

A new Offline Address Book (OAB) will be created when you deploy the first Exchange 2013 Mailbox server in an existing Exchange organization. All existing clients that use OAB will see this new OAB by default the next time they perform an OAB update, and they also will perform a full OAB download. If you don’t want this to happen, you must configure existing mailbox databases to explicitly point to the current default OAB before you deploy the first Exchange 2013 server.

You can do this by following these steps:

You also can use Exchange Management Shell to view all mailbox databases without a default OAB explicitly set on them and then explicitly set a default OAB. Start by entering the following command:

Get-MailboxDatabase | Where {$_.OfflineAddressBook -eq $Null} |
FT Name,OfflineAddressBook -AutoSize

If no values are returned, a default OAB is already explicitly set throughout the organization. If values are returned, you need to configure some databases with an explicitly defined default OAB. The following commands locate all mailbox databases in an Exchange 2007 or Exchange 2010 environment with no default OAB defined at the database level and then set these mailbox databases to the current default OAB in the organization:

Get-MailboxDatabase | Where {$_.OfflineAddressBook -eq $Null} |
Set-MailboxDatabase -OfflineAddressBook (Get-OfflineAddressBook |
Where {$_.IsDefault -eq $True})

If you have both Exchange 2007 and Exchange 2010 deployed on premises, you must run the command twice (using the respective Exchange Management Shell for each version).

Finally, you can confirm that all mailbox databases now have an explicitly defined default OAB, by re-running the first command. The command should return no values.

Most organizations have existing Exchange installations. When moving Exchange 2007 or Exchange 2010 installations to Exchange Server 2013, you cannot perform an in-place upgrade. Instead, you must install new Exchange Server 2013 servers into the existing organization and then migrate to Exchange Server 2013.

Migration from Exchange 2007 or Exchange 2010 to Exchange 2013 involves installing Exchange Server 2013 on new servers and then moving the mailboxes and public folders from your existing installations to the new installation. In a migration, only mailbox and public folder data is moved, and any Exchange configuration data is not maintained.

The steps you perform to migrate from Exchange 2007 or Exchange 2010 to Exchange 2013 are as follows:

For servers deployed within the organization, you can install the Mailbox and Client Access roles on a single computer. As the size and needs of the organization increase, however, it becomes more and more beneficial to host these roles on separate servers. Keep the following in mind:

When you use multiple Exchange servers, you should deploy the roles in this order:

For client access to work correctly, install at least one Client Access server in each Active Directory site that has a Mailbox server. For message transport, install at least one Mailbox server for each group of Active Directory sites that are well connected on a common LAN. For example, if the organization consists of sites A and B, which are well connected on a common LAN, and sites C and D, which are well connected on a common LAN, with wide area network (WAN) links connecting sites A and B to sites C and D, a minimal implementation would be to have Mailbox servers only in site A and site C. However, Microsoft recommends that you have the Client Access and Mailbox Server roles in each Active Directory site with mail-enabled clients.

Because you install legacy Edge Transport servers outside the Active Directory forest, you can deploy additional Edge Transports at any time. By configuring multiple Edge Transport servers, you can ensure that if one server fails, Edge Transport services continue. If you also configure your Edge Transport servers with round-robin DNS, you can load balance between them.

Before you run Exchange Server 2013 Setup make sure that the server meets the system requirements and prerequisites as discussed in the Chapter 1 section “Exchange Server 2013 editions.” You can run Exchange Server 2013 only on full installations of Windows Server 2008 R2 and Windows Server 2012. You cannot install Exchange Server 2013 on a server running in Windows Server Core mode. Instead, you must convert the Core mode to a full installation. The supported editions are as follows:

You can run Exchange Server 2013 Setup in one of several modes, including:

Generally, you should install Exchange Server 2013 on member servers rather than on domain controllers. This will ensure Exchange operates with strictest security allowed and has optimal performance. If you do install Exchange Server 2013 on a domain controller, you won’t be able to demote the server. Once Exchange 2013 is installed, changing a server’s role from a member server to a directory server, or vice versa, isn’t supported.

If something goes wrong with the installation and re-running Setup and following the prompts doesn’t help you resolve the problem, you have several options. You can restore the server from backup or you can run Exchange Server 2013 Setup in recovery mode by running setup /m:RecoverServer at a command prompt. If you are recovering to a different server, the server must use the same fully qualified domain name (FQDN) as the failed server.

When you recover a server, you don’t specify the roles to restore. Setup detects the Exchange Server object in Active Directory and installs the corresponding files and configuration automatically. After you recover the server, you can restore databases and reconfigure any additional settings.

When you are ready to run Setup, you can begin the installation and install server roles by completing the following steps:

By default, Exchange 2013 runs in trial mode. To get out of trial mode, you must validate the installation. In the left pane of Exchange Admin Center, tap or click Servers. As shown in Figure 2-8, a link is provided for entering a product key. Tapping or clicking this link opens the properties dialog box for the mail server with the general page displayed. Enter a valid product key in the boxes provided and then tap or click Save.

Figure 2-8. Opening Exchange Admin Center.

You can change the product key at any time on the general page. Select Change Product Key, enter a valid product key, and then tap or click Save.

You can upgrade a Standard edition to an Enterprise edition using the options on the general page as well. Select Change Product Key, enter a valid product key for Enterprise edition, and then tap or click Save.

You can verify that Exchange Server 2013 installed successfully by running the Get-ExchangeServer cmdlet in Exchange Management Shell. This command displays a list of all Exchange 2013 server roles that are installed on a specified server.

During installation, Exchange Setup logs events in the Application log of Event Viewer. You can review the Application log to make sure there are no warning or error messages related to Exchange setup. Typically, these events have event IDs 1003 and 1004, with the source as MSExchangeSetup.

You also can learn more about the installation by reviewing the setup log file created during the setup process. This log file is stored in the %SystemDrive%ExchangeSetupLogs folder with the name ExchangeSetup.log. The %SystemDrive% variable represents the root directory of the drive where the operating system is installed. Because these logs contain standard text, you can perform a search using the keyword error to find any setup errors that occurred.

As discussed previously, Setup must be able to contact Active Directory. If Setup is unable do this, errors will be logged and the Exchange organization will not be prepared properly. In the following example, Setup couldn’t validate the state of Active Directory and couldn’t locate a domain controller:

[06/02/2013 20:18:31.0253] [0] Setup is choosing the domain controller
to use
[06/02/2013 20:18:42.0630] [0] Setup is choosing a local domain
controller…
[06/02/2013 20:18:45.0033] [0] [ERROR] Setup encountered a problem while
validating the state of Active Directory: Could not find any Domain
Controller in domain pocket-consultant.com.
[06/02/2013 20:18:45.0158] [0] [ERROR] Could not find any Domain Controller
in domain pocket-consultant.com.
[06/02/2013 20:18:45.0205] [0] [ERROR] Domain controller not found in the
domain "pocket-consultant.com".
[06/02/2013 20:18:45.0205] [0] Setup will use the domain controller ''.
[06/02/2013 20:18:45.0205] [0] Setup will use the global catalog ''.
[06/02/2013 20:18:45.0955] [0] No Exchange configuration container was
found for the organization. Message: 'Could not find any Domain Controller
in domain pocket-consultant.com.'.

Because of this problem, Setup didn’t fully prepare the organization and had problems configuring the Mailbox role: Transport service and the other services as well. With Exchange 2013 RTM, the scripts for setup waited for up to 40 minutes during the Mailbox role: Transport service configuration, while continuously checking and eventually timing out. Setup took much longer than usual, but did continue all the way to completion. Although this long wait was an indicator of a problem, later updates to Setup for Cumulative Update 1 and beyond removed the waits, so there are no longer long lags that may indicate a problem.

When Setup is able to validate the state of Active Directory, the log records a very different set of events as shown in the following example:

[06/02/2013 20:40:07.0115] [0] Setup is choosing the domain controller
to use
[06/02/2013 20:40:14.0135] [0] Setup is choosing a local domain
controller…
[06/02/2013 20:40:24.0729] [0] Setup has chosen the local domain controller
CorpServer24.pocket-consultant.com for initial queries
[06/02/2013 20:40:24.0885] [0] PrepareAD has either not been run or has not
replicated to the domain controller used by Setup. Setup will attempt to
use the Schema Master domain controller CorpServer24.pocket-consultant.com
[06/02/2013 20:40:24.0885] [0] The schema master domain controller is
available
[06/02/2013 20:40:24.0901] [0] The schema master domain controller is in
the local domain; setup will use CorpServer24.pocket-consultant.com
[06/02/2013 20:40:24.0901] [0] Setup is choosing a global catalog…
[06/02/2013 20:40:24.0917] [0] Setup has chosen the global catalog server
CorpServer24.pocket-consultant.com.
[06/02/2013 20:40:24.0932] [0] Setup will use the domain controller
'CorpServer24.pocket-consultant.com'.
[06/02/2013 20:40:24.0932] [0] Setup will use the global catalog
'CorpServer24.pocket-consultant.com'.
[06/02/2013 20:40:24.0948] [0] No Exchange configuration container was
found for the organization. Message: 'Could not find the Exchange
Configuration Container'.

Here, Setup was able to select a domain controller to work with, locate the schema master, and choose a global catalog server. Note that Setup reports that PrepareAD was not run or replicated and that no Exchange configuration container was found. This is normal for a new installation of Exchange 2013. Shortly after validating the state of Active Directory, Setup will determine the organization-level operations to perform. For a new installation of Exchange 2013, related entries should look similar to the following:

[06/02/2013 20:40:26.0339] [0] Setup is determining what organization-level
operations to perform.
[06/02/2013 20:40:26.0339] [0] Setup has detected a missing value. Setup is
adding the value PrepareSchema.
[06/02/2013 20:40:26.0339] [0] Setup has detected a missing value. Setup is
adding the value PrepareOrganization.
[06/02/2013 20:40:26.0339] [0] Setup has detected a missing value. Setup is
adding the value PrepareDomain.

Here, Setup reports that it will prepare the Active Directory schema, the Exchange organization, and the domain. You can confirm each by looking for the elements that should have been created or configured as discussed in the section titled Coexistence and Active Directory earlier in the chapter.

To complete the installation for an initial deployment of Exchange into an organization, you need to perform the following tasks:

The Exchange Server 2013 installation process uses Windows Installer. Using Windows Installer helps to streamline and stabilize the installation process, and it makes modification of installation components fairly easy. Thanks to Windows Installer, you can install additional roles by re-running Setup from media or the download folder and resume a failed installation or modification simply by re-running Exchange Setup.

Although Exchange Setup doesn’t allow you to remove individual roles from a server, you can use the options on the Programs And Features page under Control Panel, Programs to uninstall Exchange Server. To do this, follow these steps:

Before you can remove the Mailbox role from a server, you must move or delete all mailboxes hosted in mailbox databases on the server and all offline address books hosted in public folders.

With Exchange Server 2013, Microsoft decided to deliver routine product updates and security updates separately. Under this servicing model, routine product updates are delivered periodically as a single, cumulative update, and security updates are delivered separately. While this allows you to install security updates as they are released without having to install a cumulative update, cumulative updates themselves will contain security updates. As with earlier releases of service packs in Exchange Server, cumulative updates are delivered as full product updates and installed as upgrades.

To better align on-premises Exchange and Exchange Online, Microsoft tries to release cumulative updates on a fixed schedule and applies cumulative updates to their hosted Exchange servers prior to official release. Thus, when an update is released you know it has been applied to all Exchange Online servers and all of the mailboxes stored in the cloud.

Cumulative updates more closely resemble service packs than rollup updates. Not only may cumulative updates contain hotfixes and security updates, they may also contain new features, product enhancements, and other changes that affect the way the product works. While language modifications were previously limited to Service Pack releases, cumulative updates may contain updates to language resources. A cumulative update also may contain Active Directory schema updates. If so, the schema changes will be additive and backward compatible with previous release and product versions.

Every cumulative update and service pack is a full release of the product. This means, you install cumulative updates and service packs as product upgrades and that each update package will be larger than the previous product or update package. Because you install cumulative updates and service packs as upgrades, any customizations you’ve made to Exchange Server (using web.config files on Client Access servers, EdgeTransport.exe.config files on Mailbox servers, registry changes, or other custom configuration options on servers) are not preserved. This means you will lose any customizations. To prevent this, you must save your customizations and then re-apply them after applying a cumulative update or service pack.

In the unlikely event that the upgrade fails and is unrecoverable, you will need to re-install Exchange Server. This re-installation process will create a new server object and should not result in the loss of mailbox or queue data. However, you will need to re-seed or re-attach existing databases after the re-installation process.

You apply cumulative updates and service packs using Exchange Server Setup. Because each cumulative update and service pack is a new build of Exchange Server 2013, you don’t need to apply cumulative updates or service packs in sequence. You can apply the latest cumulative update or service pack at any time. For example, if you deployed Exchange Server 2013 RTM but didn’t upgrade to Exchange Server Cumulative Update 1, you could upgrade the original installation directly to Exchange Server Cumulative Update 2.

In a Database Availability Group configuration, all servers should be running the same cumulative update or service pack of Exchange Server 2013—except during an upgrade. During an upgrade, individual servers within a Database Availability Group can have different cumulative update or service pack versions. This mixed state is expected to be only temporary. Database Availability Group should not operate in a mixed state for long periods of time.

Similarly, all servers in a Client Access array should be running the same cumulative update or service pack of Exchange Server 2013—except during an upgrade. During an upgrade, individual servers within a Client Access array can have different cumulative update or service pack versions. Again, this mixed state is expected to be temporary.

Cumulative updates and service packs are published at the Microsoft Download Center. Because staying current with cumulative updates and service packs may present a special challenge for some Exchange installations, it is important to note that cumulative updates are supported only for three months after the release of the subsequent cumulative update. With Microsoft’s goal of delivering cumulative updates quarterly, this typically means that a prior cumulative update is supported for about six months.

Versioning with Exchange Server 2013 gets a little tricky. This is because Exchange Server can have both service packs and cumulative updates for those service packs. To differentiate between versions, Microsoft references both the Exchange Server version and the cumulative update.

The official release of Exchange Server 2013 is referred to as Exchange Server 2013 RTM. Cumulative updates for this release are referred to using the full release name plus the cumulative update number. Thus, Exchange Server 2013 RTM with Cumulative Update 1 is referred to as Exchange Server 2013 RTM CU1.

As Microsoft releases service packs for Exchange Server 2013, those service packs will be full product rollups that include prior cumulative updates of the product. Cumulative updates for Exchange Server 2013 with specific service packs will be released as well. In this instance, cumulative updates are referred to using the full release name, the service pack name, and the cumulative update number. Thus, Exchange Server 2013 SP1 with Cumulative Update 1 is referred to as Exchange Server 2013 SP1 CU1.

Keep in mind the version of Exchange Server is updated when you install a cumulative update, a service pack, or both. This means that one way to determine what cumulative update, service pack, or both is applied is to check the version number of an Exchange server. The build number for Exchange 2013 RTM is 516.32; the build number for Exchange 2013 RTM Cumulative Update 1 is 620.29; the build number for Exchange 2013 RTM Cumulative Update 2 is 712.22, and so on.

Get-ExchangeServer | select name, serverrole, admin*

The servicing model changes the way security updates are released as well. For Exchange Server 2013, security updates are designated for a specific cumulative update and contain all of the fixes available at the time of release in a single update package. Thus, to ensure a server has the most recent security fixes, you need to apply only the most recently released security update for a specific cumulative update. For example, if you are using Exchange Server 2013 with CU2, you ensure a server has the most recent security fixes by applying the most recent security update for CU2.

As cumulative updates themselves contain security updates, you need to apply only security updates that have been released after a specified cumulative update. Thus, if for some reason you didn’t apply security updates for Exchange Server 2013 CU1 and have now upgraded to Exchange Server 2013 CU2, you don’t need to apply any of the security updates that are specific to Exchange Server 2013 CU1 (or Exchange Server 2013 RTM).

Security updates for Exchange Server 2013 are available via Microsoft Update and are published at the Microsoft Download Center. Finally, it is important to point out that security updates released for a particular cumulative update will not need to be uninstalled before moving to the next cumulative update.

New service packs for Exchange 2013 will include all the prior cumulative updates and security updates. Thus, when you install Exchange 2013 Service Pack 1, you don’t also need to install any prior cumulative updates and security updates.

Before you run Exchange Setup make sure you read the release notes for the cumulative update or service pack. Also make sure that any server on which you plan to install the cumulative update or service pack meets the system requirements and prerequisites for Exchange Server 2013.

You can run Exchange Server 2013 only on full installations of Windows Server 2008 R2 and Windows Server 2012 RTM or R2. Exchange Server 2013 doesn’t support in-place upgrades from any previous version of Exchange. After you install a cumulative update or service pack, you cannot uninstall the cumulative update or service pack to revert to an earlier version of Exchange Server 2013. If you uninstall a cumulative update or service pack, Exchange Server 2013 is removed from the server.

As cumulative updates and service packs may contain Active Directory schema changes and other Active Directory updates, you may want to update Active Directory prior to deploying a cumulative update or service pack on any server in your organization, especially in a large enterprise. Here, keep the following in mind:

Although Exchange Server 2013 Setup can perform these processes for you during the upgrade, the changes can take some time to replicate throughout a large organization. By performing these tasks manually, you can streamline the upgrade process. You also can ensure the tasks are run with accounts that have appropriate permissions. Keep the following in mind:

You must apply a cumulative update or service pack by upgrading your Exchange 2013 servers in the required order. First, you upgrade Mailbox servers and then you upgrade Client Access servers. After you install a cumulative update or service pack, you must restart the server so that changes can be made to the registry and operating system.

If something goes wrong with the installation and re-running Setup and following the prompts doesn’t help you resolve the problem, you have several options. You can restore the server from backup or you can run Exchange Server 2013 Setup in recovery mode by running setup /m:RecoverServer at a command prompt. If you are recovering to a different server, the server must use the same FQDN as the failed server.

When you recover a server, you don’t specify the roles to restore. Setup detects the Exchange Server object in Active Directory and installs the corresponding files and configuration automatically. After you recover the server, you can restore databases and reconfigure any additional settings.

As discussed previously, a current list of cumulative updates and service packs for Exchange Server 2013 can be found at http://technet.microsoft.com/en-us/library/jj907309(v=exchg.150).aspx.

When you are ready to run Setup and install an update, you can begin the installation. If you are installing a new server using a current cumulative update or service pack, follow the procedure as discussed previously under “Installing Exchange Server.” Otherwise, to update an existing installation of Exchange 2013, complete the following steps:

The Setup Progress page, shown in Figure 2-13, tracks the progress of the installation. The installation is performed in a series of steps, with the progress for the current step tracked with a progress bar and as a percentage of completion. The number of steps varies, depending on the tasks Setup must perform to prepare the environment, as well as the options you selected.

Figure 2-13. Tracking the progress of the installation.

As part of the update, Setup removes existing Exchange files from the installation and then copies new files into the appropriate directories. Finally, you’ll see the Setup Completed page, shown in Figure 2-14, when Setup completes the installation.

Figure 2-14. The setup is complete.

You must restart the server to finalize the installation. After you restart the server, you can verify the update using the techniques discussed previously under “Verifying and completing the installation.” Because any customized per-server settings in Exchange configuration files are overwritten, you’ll need to restore the related files or re-create the customized settings.