When you install Exchange Server 2013, you install your Exchange servers within the organizational context of the domain in which the server is a member. The physical site boundaries and subnets defined for Active Directory Domain Services are the same as those used by Exchange Server 2013, and the site details are determined by the IP address assigned to the server. If you are installing the first Exchange server in a domain, you set the name of the Exchange organization for that domain. The next Exchange server you install in the domain joins the existing Exchange organization automatically.

Exchange 2013 organizations natively have only two server types: Client Access servers and Mailbox servers. In this new architecture, Client Access servers act as the front end for Exchange services, and Mailbox servers act as the back end, as shown in Figure 1-1. Exchange 2013 does not have separate server roles for Hub Transport servers or Unified Messaging servers; instead, the related components are now part of the Mailbox server role.

Figure 1-1. Client-server architecture in Exchange 2013

As part of the major architecture changes for Exchange 2013, Client Access servers now act only as lightweight, stateless proxy servers. They provide a unified namespace, authentication, and network security for the Exchange organization. Although they also provide the proxy and redirection logic for client protocols, Client Access servers no longer handle all of the client-related messaging tasks in an Exchange implementation, nor do they perform content conversion. In addition, all other components that were previously associated with Client Access servers are now moved to Mailbox servers.

Client Access servers are designed to work with TCP affinity; therefore, load balancing is easier because application session affinity is not required. RPC over TCP has been removed in Exchange 2013 as well, and all Outlook connections now take place using Outlook Anywhere (RPC over HTTP). These changes have simplified the protocol stack, eliminated the need for RPC Client Access arrays and the related namespace, and moved the maintenance of the RPC sessions to the Mailbox servers.

Mail transport is provided by the Front End Transport service, which provides mailbox locator services and proxy services for incoming and outgoing SMTP messages, as shown in Figure 1-2. The Front End Transport service loads routing tables based on information from Active Directory and uses this information to route messages to the Transport service on Mailbox servers. The Mailbox server is selected based on the location of mailbox databases associated with the recipients.

Figure 1-2. Front End Transport architecture

A recipient is an entity that can receive Exchange mail and includes users, contacts, distribution groups, public folders, and resources (such as rooms and equipment used for scheduling).

You refer to recipients as either mailbox-enabled or mail-enabled. Mailbox-enabled recipients (users and resources) have mailboxes for sending and receiving email messages. Mail-enabled recipients (contacts, distribution groups, and public folders) have email addresses but no mailboxes, which allow users in your organization to send messages to mail-enabled recipients. Keep in mind that when you mail-enable a public folder and grant a user Send As permission on the public folder, the user can send mail on behalf of the public folder.

In addition to users, contacts, groups, resources, and public folders, Exchange Server 2013 has two unique types of recipients: linked mailboxes and dynamic distribution groups. Basically, a linked mailbox represents a mailbox that is accessed by a user in a separate, trusted forest. A dynamic distribution group is a type of distribution group that you can use to build a list of recipients whenever mail addressed to the group is received, rather than having a fixed member list.

To manage recipients in your organization, you need to know these key concepts:

The Routing tables used by the Front End Transport service contain a special list of Mailbox servers in the local Active Directory site. This list is based on the mailbox databases of message recipients. Routing in the front-end revolves around resolving message recipients to mailbox databases. For each mailbox database, the Front End Transport services looks up the routing destination.

Each routing destination has a delivery group, which is generally a routable Database Availability Group (DAG), a Mailbox delivery group, or an Active Directory site, but can also be a group of connector source servers or a list of expansion servers for dynamic distribution groups. A Mailbox delivery group is a collection of one or more transport servers that are responsible for delivering messages to a routing destination. When the routing destination is a Mailbox delivery group, the delivery group may contain Exchange 2013 Mailbox servers, Exchange 2010 Hub Transport servers, or Exchange 2007 Hub Transport servers.

The process by which the message is routed depends on the relationship between the source transport server and the destination delivery group. If the source transport server is in the destination delivery group, the routing destination itself is the next hop for the message. The message is delivered by the source transport server to the mailbox database or connector on a transport server in the delivery group.

On the other hand, if the source transport server is outside the destination delivery group, the message is relayed along the least-cost routing path to the destination delivery group. In a complex Exchange organization, a message may be relayed either to other transport servers along the least-cost routing path, or directly to a transport server in the destination delivery group.

For an incoming message, the Front End Transport service selects a single Mailbox server to receive the message regardless of the number or type of recipients. If the message has a single recipient, a Mailbox server in the target delivery group is selected, with a preference based on the proximity of the Active Directory site. If the message has multiple recipients, the Front End Transport service uses the first 20 recipients to select a Mailbox server in the closest delivery group. If the message has no mailbox recipients, such as when the message is addressed to a distribution group, a Mailbox server in the local Active Directory site is randomly selected.

The Transport service runs on all Mailbox servers and is responsible for all mail flow within an Exchange organization, as shown in Figure 1-3. The Transport service relies on the Mailbox Transport service, which consists of two separate helper services: the Mailbox Transport Delivery service used with incoming messages and the Mailbox Transport Submission service used with outgoing messages. The Transport service receives SMTP messages from the Transport service and establishes an RPC MAPI connection with the local mailbox database to deliver a message. The delivery service connects to the local mailbox database by using RPC MAPI to retrieve messages and submits messages over SMTP to the Transport service.

Figure 1-3. Back End Transport architecture

The Mailbox Transport service only communicates with the Transport service and local mailbox databases. When the Mailbox Transport service receives a message for delivery it accepts the message if the recipient resides in an active copy of a local mailbox database. Otherwise, the service rejects the message and returns a non-delivery response to the Transport service for retrying delivery, generating a non-delivery report or rerouting the message.

When the Mailbox Transport service receives a message for submission, the service resolves the message recipients to mailbox databases. For each mailbox database, the service looks up the routing destination. Each routing destination has a delivery group, which is either a routable DAG, a Mailbox delivery group, or an Active Directory site—and the rest of the process continues as with incoming messages for the Front End Transport service.

Exchange 2013 uses directory-based recipient resolution for all messages that are sent from and received by users throughout an Exchange organization. The Exchange component responsible for recipient resolution is the Categorizer. The Categorizer processes all email messages and uses the final recipient to determine what journaling policies, Information Rights Management policies, data loss prevention rules, and transport rules should be applied.

The Categorizer must be able to associate every recipient in every message with a corresponding recipient object in Active Directory. All senders and recipients must have a primary SMTP address. If the Categorizer discovers a recipient without a primary SMTP address, it will determine what the primary SMTP address should be or replace a non-SMTP address. Replacing a non-SMTP address involves encapsulating the address in a primary SMTP address that will be used while transporting the message.

Active Directory sites and DAGs are delivery group boundaries. When Mailbox servers aren’t part of a DAG, they use site membership information to determine whether other Mailbox servers are located in the same site, which allows the Mailbox server to submit messages for routing and transport to another Mailbox server that has the same site membership. Site-based routing is also used for interoperability with Exchange 2010 and Exchange 2007.

When the destination delivery group is a collection of Mailbox servers in a single Active Directory site, the mailbox databases on those servers are the routing destinations. After a message is routed to the Transport service on a Mailbox server in a particular site, the Transport service in turn routes the message to the Mailbox Transport service on the Mailbox server in the site that has the active copy of the destination mailbox database. The Mailbox Transport service on this server then delivers the message to the local mailbox database.

As routing destinations and delivery groups are separated by the major release version of Exchange, the Active Directory site may contain multiple Mailbox delivery groups. Specifically, each major release version of Exchange deployed in a particular site will have one delivery group. Regarding routing and delivery, keep the following in mind:

When the destination delivery group is a routable DAG, the mailbox databases in the DAG are the routing destinations. After a message is routed to the Transport service on a Mailbox server in the DAG, the Transport service routes the message to the Mailbox Transport service on the Mailbox server in the DAG that has the active copy of the destination mailbox database. The Mailbox Transport service in this server then delivers the message to the local mailbox database. Because the DAG itself is the delivery group boundary rather than the Active Directory site associated with a particular Mailbox server, Mailbox servers may be physically located in more than one site even though they are members of the same delivery group.

Exchange servers determine site membership by matching their assigned IP address to a subnet that is defined in Active Directory Sites and Services and associated with an Active Directory site. The Exchange server then uses this information to determine which domain controllers, Global Catalog servers, and other Exchange servers exist in that site, and it communicates with those directory servers for authentication, authorization, and messaging purposes. Exchange 2013 always tries to retrieve information about recipients from directory servers that are in the same site as the Exchange 2013 server.

As Figure 1-4 shows, Active Directory sites are connected through IP site links, which can connect two or more sites. Each site link has a specific schedule, interval, and cost. The schedule and interval determine the frequency of Active Directory replication, and the cost value determines the cost of using the link relative to other links that might be available. Active Directory replication uses the link with the lowest cost when multiple paths to a destination exist. The cost of a route is determined by adding together the cost of all site links in a transmission path. In Active Directory Domain Services, Administrators assign the cost value to a link based on relative network speed, available bandwidth, and reliability compared to other available connections. By default, IP site links always allow traffic to flow into or out of a site.

Figure 1-4. Message traffic between sites is routed over IP site links.

In large enterprises, message traffic might have to travel through multiple sites to get from the source site to a destination site. When transferring messages from one site to another through other sites, a transport server always tries to connect directly to a transport server in the destination site; therefore, messages are not relayed through each transport server in each site in the link path. Instead, the messages go directly from the transport server in the originating site across the link to the transport server in the destination site.

If the originating server cannot connect directly to a transport server in the destination site, the originating transport server uses the link cost to determine the closest site at which to queue the message. Messages queue until they are processed by the transport server and relayed to their destination. When legacy Edge Transport servers are subscribed to an Active Directory site, the subscribed Edge Transport servers aren’t accessible from other Active Directory sites.

The transport server can also use the site link information to optimize the routing of messages that users send to multiple recipients. The transport server expands a distribution list and creates multiple copies of a message only when multiple paths are in the routing topology. This feature is called delayed fan-out.

Delayed fan-out is used only when the delivery group is an Active Directory site. When multiple recipients share part of the routing path, delayed fan-out tries to reduce the number of message copies, thereby reducing the number of message transmissions.

Microsoft introduced Exchange Online with Exchange Server 2007. Exchange Online is referred to as a cloud service, meaning the service is provided via the Internet, and it allows you to outsource all or part of your Exchange services. Exchange Online differs from Exchange on-premises (the standard implementation) in several fundamental ways. The Exchange Online hardware resides elsewhere and users access their mailboxes over the Internet; however, administrators still retain control and management over the outsourced mailboxes.

In Exchange Server 2007, the on-premises and online Exchange configurations weren’t tightly integrated but starting with Exchange Server 2010 and improving with Exchange Server 2013, Microsoft made it possible to manage both online and on-premises Exchange configurations using the same set of management tools. You can simultaneously connect to and manage both online and on-premises configurations in the Exchange Admin Center.

Although Exchange Online has some advantages over an Exchange on-premises implementation, it has disadvantages as well. For users, Exchange Online provides:

For administrators, Exchange Online provides:

What Exchange Online doesn’t provide is immediacy of access. Users must always be connected to the Internet to get their mail. Messages typically are routed and transferred across the Internet, which can cause delays. Exchange Online also does not offer some popular Exchange features.

When you configure your Exchange organization, it’s important to keep in mind that Exchange Online is not an all-or-nothing implementation. You can host some mailboxes online and others on-premises. Exchange Server 2013 makes it easy to manage mailboxes regardless of where they are located. Before you transition mailboxes off-site, however, you’ll probably want to perform a trial with a limited subset of users while keeping mailboxes for executives and most managers in house. In fact, you might want to plan to always keep highly sensitive mailboxes, such as those for executives and other high-level managers, in house.

Exchange Server 2013 uses cross-premises routing to transfer messages between on-premises and hosted mailboxes. If you send a message to a user with a hosted mailbox, your organization’s transport servers will route the message across the Internet to the hosted Exchange server. If you send a message to a user with an on-premises mailbox, your organization’s transport servers will route the message across your organization to the appropriate Exchange server.

Exchange provides features for migrating mailboxes from online to on-premises environments and vice versa. During the migration, a mailbox might temporarily exist in both locations but when Exchange completes the migration, the mailbox exists only in the destination environment. Outlook 2007 and later include an Autodiscover feature that automatically connects messaging clients to the correct Exchange server. This feature uses the user’s SMTP email address during automatic discovery to determine where the mailbox is currently located.

Normally, Autodiscover works very well; however, a conflict could occur if a user has a mailbox both in Exchange Online and in Exchange on-premises or if a user has the same primary SMTP email address in Exchange Online and Exchange on-premises. In these scenarios, the Autodiscover feature normally does not configure Outlook for the Exchange Online environment and instead uses Exchange on-premises, which has priority over Exchange Online when there is a conflict and the user’s computer is connected to the Active Directory domain. To resolve the problem, delete the original mailbox from its location as soon as possible after a mailbox migration. If a user needs both an online and on-premises mailbox, do not use the same primary SMTP email address for both Exchange Online and Exchange on-premises.

The Active Directory data store contains most directory information for Exchange Server 2013 configurations and recipients in addition to other important directory resources. Domain controllers maintain the data store in a file called Ntds.dit. The location of this file is set when Active Directory is installed and should be on an NTFS file system drive formatted for use with Windows Server. Domain controllers save some directory data separately from the main data store.

Two key concepts on which to focus when looking at Active Directory are multimaster replication and Global Catalog servers.

The Exchange store is the core storage repository for managing Exchange databases. Unlike previous releases of Exchange, Exchange 2013 has only one type of database: the mailbox database. Mailbox databases contain the data, data definitions, indexes, flags, checksums, and other information that comprise mailboxes in your Exchange organization.

How are Exchange Server data files used?

With Exchange Server 2013, Mailbox servers have a single database file for each mailbox database. Exchange 2013 stores all messages and attachments in the primary data file. Because attachments are encapsulated and written in binary format, you don’t need to convert them to Exchange format. Exchange Server uses a link table within the database to reference the storage location of attachments within it.

As Figure 1-5 shows, each database has a primary data file and several other types of shared working files and transaction logs.

Figure 1-5. The Exchange data store has primary data files for each database in addition to working files.

The file types are used as follows:

• Primary data file (Database.edb). A physical database file that holds the contents of the data store. By default, the name of the data file is the same as the name of the associated data store with the .edb file extension added; however, you can rename a database without renaming the database file.

• Checkpoint file (E##.chk). A file that tracks the point up to which the transactions in the log file have been committed to databases in the storage group. Generally, the name of the checkpoint file is derived from the database prefix.

• Temporary data (Tmp.edb). A temporary workspace for processing transactions.

• Current log file (E##.log). A file that contains a record of all changes that have yet to be committed to the database. Generally, the name of the log file is derived from the database prefix.

• Preprovisioned log file (E##tmp.log). The next preprovisioned log, which is created in advance.

• Secondary log files (E##00000001.log, E##00000002.log, …). Additional log files that are used as needed. Up to 4 billion unique log files can be created for each database.

• Reserve log files (E##Res00001.jrs, E##Res00002.jrs, …). Files that are used to reserve space for additional log files if the current log file becomes full.

• Temporary log (E##tmp.log). A temporary workspace for logging.

By default, the primary data file, working files, and transaction logs are all stored in the same location. On a Mailbox server, you’ll find these files in a per-database sub-folder of the %SystemRoot%Program FilesMicrosoftExchange ServerV15Mailbox folder. Although these are the main files used for the data store, Exchange Server uses other files, depending on the roles for which you have configured the server.

Working with Exchange Server message queues

Exchange Server message queues are temporary holding locations for messages that are waiting to be processed. Two general types of queues are used:

• Persistent. Persistent queues are always available even if no messages are waiting to be processed.

• Nonpersistent. Nonpersistent queues are available only when messages are waiting to be processed.

With Exchange Server 2013, both Mailbox servers and legacy Edge Transport servers store messages waiting to be processed in persistent and nonpersistent queues. Table 1-1 provides an overview of the queues used. In the Exchange Toolbox, you can view top-level queues by selecting Toolbox in the left pane and then tapping or clicking Queue Viewer. You’ll learn more about queues in Chapter 8.

Table 1-1. Queues used with transport servers

QUEUE	SERVER ROLE	NUMBER OF QUEUES	QUEUE TYPE
Delivery/Relay	Mailbox	One delivery or relay queue for each unique destination Mailbox server, connector, designated expansion server, non-SMTP gateway, and so on	Nonpersistent
Poison message	Mailbox, Edge Transport	One	Persistent
Remote delivery	Edge Transport	One for each unique destination SMTP domain and smart host	Nonpersistent
Shadow redundancy	Mailbox, Edge Transport	One for each hop to which the server delivered the primary message	Nonpersistent
Submission	Mailbox, Edge Transport	One	Persistent
Safety Net / Transport dumpster	Mailbox, Edge Transport	Primary and shadow / One for each Active Directory site	Nonpersistent
Unreachable	Mailbox, Edge Transport	One	Persistent

Shadow redundancy and Safety Net are two important concepts that you need to understand when working with queues. While shadow redundancy keeps a redundant copy of messages in transit, Safety Net keeps a redundant copy of a message after the message is successfully processed. Thus, in effect, Safety Net takes over where shadow redundancy finishes.

Exchange Server 2013 implements shadow redundancy for queued messages. In the event of an outage or server failure, this feature works to prevent the loss of messages that are in transit by storing queued messages until the next transport server along the route reports a successful delivery of the message. If the next transport server doesn’t report successful delivery, the message is resubmitted for delivery.

Shadow redundancy eliminates the reliance on the state of any specific Mailbox or Edge Transport server and eliminates the need for storage hardware redundancy for transport components. As long as redundant message paths exist in your routing topology, any transport component is replaceable and you don’t have to worry about emptying a server’s queues or losing messages due to transport failure.

In Exchange 2013, the Transport service now makes a redundant copy of a message as soon as it receives it and then acknowledges receipt. Previously, the Transport service would acknowledge receipt and then make a redundant copy of a message. Finally, it’s important to note that it doesn’t matter whether the sending server supports shadow redundancy. If Exchange 2013 determines that a message was lost in transit, Exchange delivers the messages using the redundant copy.

Tip

Shadow redundancy uses less bandwidth than creating duplicate copies of messages on multiple servers. The only additional network traffic is the exchange of discard status between transport servers. Discard status indicates when a message is ready to be discarded from the transport database.

Exchange Server 2013 also implements Safety Net for queued messages. Safety Net replaces and enhances the transport dumpster available in Exchange 2010. By default, Safety Net stores copies of messages that were successfully processed by a Mailbox server for two days. For Mailbox servers that aren’t part of DAGs, Safety Net stores copies of messages delivered to other Mailbox servers in the local Active Directory site. For Mailbox servers that are part of DAGs, Safety Net stores copies of messages delivered to other Mailbox servers in the DAG.

Because Safety Net uses shadow redundancy, it is always fully redundant with a primary and a shadow queue. The Primary Safety Net queue stores the primary copy of a delivered message. The Shadow Safety Net queue stores a shadow copy of a delivery message. If the Primary Safety Net queue is unavailable for more than 12 hours, any messages that need to be redelivered are redelivered from the Shadow Safety Net queue.

When Mailbox servers are part of a DAG, Safety Net is used for some shadow redundancy functions. Previously, in a DAG, shadow redundancy would keep a copy of messages in the shadow queue until they were replicated to passive copies of the database. As Safety Net already has a copy of delivered messages, shadow redundancy doesn’t need to keep another copy of these messages and messages can be resubmitted from Safety Net if necessary.

As Figure 1-6 shows, the various message queues are all stored in a single database. Like the Exchange store, the message queues database uses the ESE for message storage as well as for data pages.

Figure 1-6. The Exchange message queues are all stored in a single database.

The database has a single data file associated with it and several other types of working files and transaction logs. These files are used as follows:

• Primary data file (Mail.que). A physical database file that holds the contents of all message queues

• Checkpoint file (Trn.chk). A file that tracks the point up to which the transactions in the log file have been committed to the database

• Temporary data (Tmp.edb). A temporary workspace for processing transactions

• Current log file (Trn.log). A log file that contains a record of all changes that have yet to be committed to the database

• Preprovisioned log file (Trntmp.log). The next preprovisioned log, which is created in advance

• Secondary log files (TRN00000001.log, TRN00000002.log, …). Additional log files that are used as needed

• Reserve log files (TRNRes00001.jrs, TRNRes00002.jrs, …). Files that are used to reserve space for additional log files if the current log file becomes full

The facility that manages queuing transactions is the Microsoft Exchange Transport service (MSExchangeTransport.exe). Because logs used with message queues are not continuously replicated, these log files have a fixed size of 5 MB. Changes to the queue database are written first to the transaction log and then committed to the database. When the current active log (trn.log) file fills up, Exchange closes the file and renames it as TRNNNNNNNNN.log. Trntmp.log is then renamed Trn.log and becomes the current active log file.

Exchange uses the reserve log files to reserve disk space for log files that might need to be created. Because several reserve files are already created, this speeds up the transactional logging process when additional logs are needed.

By default, the data file, working files, and transaction logs are all stored in the same location. On a Mailbox server or Edge Transport server, you’ll find these files in the %SystemRoot%Program FilesMicrosoftExchange ServerV15TransportRolesdataQueue folder.